[Resolved] Is WPML incompatible with kinsta cache?
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is trying to publish content on a WPML-powered site with a language directory prefix and is hosted on Kinsta. They want to add a set of paths to Kinsta's cache settings to be purged every time they publish or change a post. However, when using the language directory prefix, new posts do not appear in grids for public visitors because the cache is not being cleared correctly.
Solution: We recommend that the client suggests a feature request to Kinsta support to allow setting up paths including the language prefix in their cache plugin settings. This is because the current behavior is expected when WPML is set to use language per directory, as those URLs become the page URLs. If Kinsta's cache plugin is not clearing the cache as expected, the client should contact Kinsta support for further assistance. Our developers are open to collaborating with Kinsta if necessary to resolve any compatibility issues.
Please note that this solution might be irrelevant if it's outdated or not applicable to your case. If you're still experiencing issues, we highly recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please open a new support ticket with us.
100% of people find this useful.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
I am trying to:
Publish content (pages, posts, CPTs) on our site running WPML, using a language directory prefix, hosted on kinsta. I want to add a set of paths to kinsta's cache settings which should be purged everytime I publish or change a post.
Link to a page where the issue can be seen: hidden link
I expected to see:
When I publish a post, I want it to appear in grids on hub pages. I expect to be able to set a list of custom paths using kinsta's cache plug-in.
Instead, I got:
1. When WPML's URL structure is set to language directory prefix:
New posts don't appear in grids for public visitors. In kinsta's cache plug-in settings, I can set up a list of paths, but the editing view is already prefixed with the language prefix I'm currently using in the admin view. I expect to set up paths including the language prefix.
2. When WPML's URL structure is set to language parameter:
I can use kinsta's cache settings as described in their documentation. I can set up single paths and group paths which then get purged as soon as I publish or change a post.
WPML should work fine with Kinsta cache, the same as with any other cache plugin. What you have shared is kind of expected I would say, as when you set WPML and choose to use language per directory, those URLs are now your page URLs, so 2nd language homepage would be domain.com/de/ or if you have set it to use language directory for default language also.
I expect to set up paths including the language prefix.
What you have described sounds like a feature request, I advise you to suggest this to Kinsta support and contact theme further as I am shure there are some reasons why they have decided to use it like that. Otherwise, they should take the regular WP URL set in WP Settings, which then doesn't include WPML prefixes.
Our devs are glad to help with any kind of collaboration if needed, and I think they are in contact with Dean from our side.
I don't understand why this is a feature request and not a bug, but maybe this was just a misunderstanding. Let me provide some more details to clarify the issue.
In the first attached screenshot, the settings page is the same, the only difference is that one is loaded in English and the other in German. However, the settings are exactly the same. What I add in German, is also there in English, and vice versa. The URL before the "Enter a path" box suggests, however, that I should enter the path that follows _after_ the language directory prefix.
Now this would be fine if it was only a "cosmetic" issue, however it is not. We have tested thoroughly how the cache behaves, and we could break it down to the following behaviour:
----
Scenario 1: WPML's Language URL format is set to "Language name added as parameter"
Let's have a look at a few test pages. Each of the following pages contains a grid with the newest posts on the site. The test pages are all in English, and English is the main language, therefore they work without a language parameter attached.
The test pages are:
/
/insights/
/insights/blog/
If we don't add anything to the kinsta cache settings, i.e. the list "Add A Custom URL" is empty, then newly published posts appear on the frontpage, but on no other page.
If we add /insights/ and /insights/blog/ to the kinsta cache settings, then newly published posts appear immediately on all 3 test pages.
This is the expected behaviour, as it is also documented by kinsta.
----
Scenario 2: WPML's Language URL format is set to "Different languages in directories"
Let's have a look at the same test pages, which now have different URLs than in Scenario 1:
/en/
/en/insights/
/en/insights/blog/
From here we have run the same test again: we emptied the kinsta cache settings, i.e. we removed all entries from the "Add A Custom URL" table.
Result: Newly published posts don't appear on any of the test pages, not even the frontpage /en/.
We have tried to add the same paths in 3 different ways:
1. only without the language directory prefix, i.e.
/insights/
/insights/blog/
2. instead with the language directory prefix, i.e.
/en/insights/
/en/insights/blog/
3. both with and without the language directory prefix, i.e.
/insights/
/en/insights/
/insights/blog/
/en/insights/blog/
(as in the second attached screenshot)
But the result was always the same: newly published posts appeared on none of the test pages.
----
In other words:
In our scenario 1, where we did not use any path prefixes, the cache worked exactly as documented by kinsta.
In our scenario 2, where we used the language directory prefixes, the cache never purged any of the test pages.
thanks for getting back and I appreciate your detailed reply.
I do not want to sound as if I am pushing you away / to other plugin support, but as I have said before I think Kinsta cache would be more helpful here and can share more insight on why cache is cleared or is not and what can you do to solve this issue.
Please correct me if I am wrong, but seems to me the issue is with the cache not being cleared correctly when using language per directory mode, and some settings or hook to clear it needs to be implemented in Kinsta cache.
They are free to contact us and we will be glad to collaborate, or you are also free to come back to this ticket with a Kinsta support reply if there is anything we can do to help with this issue, but as I said I think they will be more helpful on this case and if this needs further compatibility work from both side, we are happy to help 🙂
Thank you for the reply. It seems you were right with your assessment that the issue is on kinsta's end. Their support investigated the issue as well, they plan to publish an update soon.
In case we encounter any further compatibility issues along the way, we will ask kinsta's support to reach out to you directly.
Thank you,
Johannes
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
