Home›Support›English Support›[Resolved] Permalinks not changed to sticky links in widgets and page excerpts
[Resolved] Permalinks not changed to sticky links in widgets and page excerpts
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported issues with WPML Sticky Links 1.5.5 is not converting permalinks in widgets and page excerpts. The site uses the Classic Editor and the Classic Widgets plugin. Solution: In fact, this is not a bug. Sticky Links does not cover those elements for link conversion yet. The support provided a patched version of Sticky Links, which solved those issues, and the issue was escalated to development for further revision.
If these solutions do not resolve your issue or seem outdated, we highly recommend checking related known issues at https://wpml.org/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.
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.
Please, note that the Edin theme does not work correctly with the Gutenberg Editor. You need to use the Classic Editor (plugin) instead. Otherwise you could run into unexpected issues. The Edin theme, according to Automattic, isn't maintained any more and doesn't receive any updates any more. Unfortunately, we cannot move to any different theme for this particular project. So, if WPML and the Edin theme wouldn't be collaborating nicely, I would have to find a custom approach just to resolve any issue manually...
If you could do this implementation on the test site hidden link, this would be great, so I could test it there. If it solves the widget issue, we would get a big step further. Thanks!
My apologies, as there was a misunderstanding about the excerpts on the homepage from my end.
I was expecting that the theme builds the excerpt programmatically by gathering it from the content, but today I see that the pages actually have an excerpt field (something that usually only posts have).
This field is sadly not recognized by Sticky Links, which is why the links are not converted on the page's excerpt fields.
Also, internal linking does not work for those fields.
I can see the same issue on posts, testing only with WPML on the Twenty Twenty-One Theme.
These are two new issues:
1) Intern links not working on excerpts for posts or pages
2) Sticky Links is not recognizing links in excerpts
I will escalate this to the second-tier support.
When it comes to Sidebar and Footer Widgets, I can provide a workaround, as I already created a fix for Sticky Links yesterday.
I can offer to create another fix for the excerpt fields, but when it comes to internal linking in excerpts, I need to consult the second-tier support for a fix.
If you provide me with Super Admin access, I can offer to install the patched version of Sticky Links now on your test site. I am still waiting for our developers to review it.
thanks for the clarifications!
I've already changed your role to a super administrator on the test site yesterday. Same link to access the backend. I also have extended the link's validity by one week.
Looking forward to hearing from you.
Best,
Johannes
Regarding issue 1)
- Internal links are not automatically adjusted on excerpts
Also this issue has been replicated on a sandbox and escalated to the second tier support team for further revision. Once I have feedback from the team I will reach out again.
If would like me to install the patched version for the Sticky Links plugin on your test site, please let me know, but I would need super admin access or at least server access by using for example the File Manager plugin.
Andreas, the credentials I sent you in the privat link at the very beginning of this chat, are still valid. As I told you in my last post, your user role on my test site is set to super admin now. Just click on the access link and you will get super admin rights in the backend. That's what you requested yesterday and I changed this the same day. I also sent you in the private link the ftp credentials in case you need to change things in the wp file system. If you have any questions or need something else, just drop me a note here.
I saw that part of the translated content got lost on the test site. For instance, the translated widget contents. To really verify everything, I'd like to update the test site with the most recent version of our staging site. Please, could you reinstall the patched plugin then?
Could you also send me a new private link here in the chat, please? I'll have to generate a new temporary access link for you.
If everything works well, I already could install the patched plugin on our staging site or do you think we'd better wait for the official release of it?
And do you have any time frame for the feedback of the second-tier-support concerning the page excerpt issue?
I created a new clone for our testing and now I realized that, although all the content got copied and the URLs adjusted in the database, the translated contents in widgets do not show up in the frontend. In the backend, the string translations of widgets are all there. But they do not show up in the frontend. Selecting a different language version than German for the front page or the blog page (where there are some integrated widgets), in the frontend, the widget content remains German and does not change to the the respective language. I do not have any idea where I should adjust this... Otherwise it wouldn't make any sense to verify your patched plugin version.
So far, everything seems to look fine on hidden link.
Exception: Homepage Featured pages sections display wrong links, but this solves itself once I disable the "Custom Permalinks" plugin. The same counts for the links on the actual pages.
The issue persists when testing the site only with Custom Permalinks and WPML without Sticky Links and using the Twenty Twenty-One Theme.
It is still unclear to me what causes this issue once "Custom Permalinks" is enabled. In fact, you are alternating the WordPress permalinks hierarchy by removing parent page slugs, which is not recommended. Anyhow, on my test site, this did not result in an issue.
It might be that one of the network-wide active plugins is linked or this issue, like here BPS Security or Better Search Replace. Would it be possible to disable those plugins network-wide, so that they do not run on hidden link?
---
On your new clone, it might be that an issue occurred while migrating the site.
Would you like me to take a look at the new clone?
Andreas, as I wrote earlier, there is no need for us to use the custom permalink plugin any more on our site. I've already adjusted the page hierarchy and consequently the slugs. So, the site is following the wordpress default configuration now. No parent page slugs removed any more.
Also, if you need for testing purposes, you can deactivate the BPS and Better Search and Replace plugins, of course.
But I have good news:
You might remember about the mess we got because of Matecat's rejecting some translation projects due to an algorithm that blocks users under certain circumstances that are not transparently communicated by Matecat. This resulted in the fact that we had to do several trials, exporting the same content from WPML to Matecat several times. Although, at the end, we got everything done, apparently, this mess affected WPML's handling of widget content.
Yesterday, investigating the issue on the test sites 1 and 2 where the translated content of widgets disappeared, I discovered on our main staging site that, although the correct content was showing up in all the widgets in frontend, also any translated content, somehow, this wasn't the most recent version of translated content. In other words, in the Admin Text menu of WPML there still was widget content that hadn't been registered as strings. As soon as I registered them, moving further to translating them in the string translation, WPML autopropagated the translations to the new strings (since this content had already been translated in older exported/reimported versions of the same widgets in Matecat). And bum, in the frontend showed up the correct translated widget content with all links pointing to the correct respective language target. Finally, WPML/Sticky Links did its job! See here, for instance, on the English front page hidden link (see also the screenshot).
I don't know if this could have been avoided in any case. Perhaps, if WPML and the Sticky Link Plugin would always and only scan the widget's content that really is rendered in the frontend and not, instead of this, is scanning some content that might be registered internally by WPML/Sticky Link, but does not get rendered in frontend and, consequently, does not show up there. I think, WPML/Sticky Link should be restricted in scanning only what really shows up in the frontend. I guess this would have been avoided the issues we run in when the same widget content got exported, translated and reimported several times like in our case.
Now, it also makes sense why one of three widgets on the "Featured Page" section (about the blog) of the front page has always been behaving just fine. As I mentioned at the beginning of our chat, the link in this widget always was pointing to the correct language version of the blog. This widgets content got translated separately in Matecat at the very end of the translation process and, consequently, did not get messed up by Matecat like other content of other widgets at the beginning.
So, although we could fix this issue concerning widget content on our site, without the patched Sticky Link plugin, you might want to consider some adjustments on the plugin's behaviour of scanning widget content...
Concerning the still unfixed issue with page excerpts, I kindly ask you for some time frame in relation to a possible fix by the second-tier-support. We would like to launch the site and if the feedback of tier 2 support would take some more time, we definitively would prefer to fix the links in page excerpts manually, since it's a manageable amount of links.
Looking forward to your reply.
Kind regards,
Johannes
*Correction*: Perhaps, if WPML and the Sticky Link Plugin would always and only scan the widget's content that really is rendered in the frontend and not, instead of this, trying to scan some content that might or might not be registered internally as a string, but does not get rendered in frontend and, consequently, does not show up there.
Just a note to clarify my point of view. I discovered that the way how WPML/Sticky Link handles the content of custom html widgets in the translation process, might not be something that a normal user like me would expect:
Let's suppose that you set up a site in your original language, for instance in German. You translate all the site's content with WPML to a different language, let's say to English, and publish it. But then, you discover that there is a widget area with some text that you'd like to change on the respective German page, some grammar or syntax error or just a new sentence that you have to insert into that text widget. You then go to the WP widget area in backend (Appearance -> Widgets) and apply your changes to the original language content of that widget. So, the source of the translated content got changed and you'd like to apply those changes to the translated version in English too. For this, you go to WPML -> String Translation to change the respective translated string of that widget.
Checking the results on the frontend will show you that something got wrong (at least in our development environment it was like this...): Instead of the adjusted English widget content, there is the adjusted German widget content showing up on your English page! As if the English translation of that text widget were lost. On the German page, everything looks fine, the changes were applied correctly and shows up in the German widget. But on the English page there is now the new German widget content showing up instead of the English one.
I got this fixed, as i wrote above, by re-registering the adjusted German widget content as a new string in the Admin Text and by retranslating it then in the string translation. In other words: any changes made to a widget's original content in your source language causes WPML to consider these changes in a way as if there were a new widget created. Consequently, this new widget has to be registered as a new string in the Admin Text prior to its translation and in order to make it showing up on the English page again.
Is this really expected?
I think, for a normal user like me, this is very unexpected. I would have expected that WMPL recognises the changes I made to the original widget and apply them automatically to the respective string, so that I could adjust the translations of that string too, without braking anything in the backend. But this does not happen. WPML does not recognise any changes made to an widget's original content after it was registered as a string. The respective string of the original language neither get updated automatically, nor can it be updated manually, as you can for the translated versions of it. Instead, you have to register the adjusted widget as a new string and delete the old string...
Is this behaviour documented in any place, in any support article? I couldn't find anything...
When it comes to widgets, you have two options to translate them:
1) Set the widgets to "All languages" and translate them with WPML > String Translation
or
2) Create one widget per language and assign each widget to a specific language
When using method 1) and widgets are assigned to "All languages," it might occur that they by default are registered as English strings on WPML > String Translation, but this is something that can be adjusted manually on the UI.
I do sadly not yet have any valuable feedback on the escalated ticket and need to ask you for some more patience, as our team is still looking into this.
About "WPML does not recognise any changes made to a widget's original content after it was registered as a string."
- This can happen if a widget is forced to be translated with a string coming from the admin_texts text domain. Could this be the reason for the issue?
If you would like to suggest a specific feature for Sticky Links or anything else around WPML, please drop me a short message with the details about what you expect the plugin to do.
We used option 1) to create our widgets. And the two widgets that I had to register once again, this time in the Admin Texts (the first time they were registered automatically by WPML), were widgets from the domain "Widgets". Now, as newly registered widgets, they appear under the domain "admin texts". Please, see the two screenshots. So, it's exactly the other way around than you thought.
Well, since you asked me if I have any suggestion, I would say: from our point of view with this particular project, we would like WPML to update any text widget content in string translation automatically, supposing that this adjusted content is in the original language and from a custom html or text widget registered under the domain "Widgets". So, even if one has to adjust this content after the widget got registered as a string, the connection between this particular widget and its respective string does not get broken as soon as one alters something in the content. One should be able to adjust the content of such a widget under Appearance -> Widgets at any time, and to adjust then also the respective translation of this widget in its already registered string under WPML -> String Translation. In our case, this isn't possible, as I reported above.
Concerning the links in page excerpts: Ok, I think we'll adjust them manually this time, just to proceed with our project, The feedback from tier 2 support will be indeed valuable for the next project or for any other user with similar issues.
