Missing custom SiteOrigin widgets after updating WPML (v4.8.4 + String Translation v3.4.1)

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client is experiencing issues with custom widgets turning into 'Missing widget' entries after saving a page in SiteOrigin Page Builder, following updates to WPML v4.8.4 and String Translation v3.4.1. Additionally, there is a 404 error on the pagination of a custom post type archive, which temporarily resolves upon re-saving the ACF custom post type but reappears later.

Solution:
We have determined that the issue with the widgets is not directly caused by WPML or String Translation, but rather by how the custom widgets are loaded and registered. Ensure that all custom widgets are registered using the standard

widgets_init

action and confirm that widget IDs and class names exactly match those saved in SiteOrigin. Also, check for PHP 8.3 compatibility as the plugin might use outdated code.

For the 'Missing widget' issue, disabling the 'Automatically detect best options for translating image texts' setting under WPML → Settings → Media Translation might resolve the issue. This is because WPML's media duplication process could be stripping necessary backslashes from the widget's data when saved in a secondary language. If problems persist, it's recommended to use

wp_slash()

when saving data to ensure backslashes are preserved.

If these solutions do not resolve the issues or if new problems arise, we recommend opening a new support ticket. Additionally, it's advisable to check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. For further assistance, please visit our support forum at WPML Support Forum.

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.

Tagged: Custom Work

This topic contains 18 replies, has 0 voices.

Last updated by Dražen 5 months, 2 weeks ago.

Assisted by: Dražen.

Author	Posts
November 6, 2025 at 12:16 pm #17553780
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, our 2nd tier checked and found the problem. The issue occurs because the custom widget saves its data directly into the database instead of using the standard WordPress functions for saving post meta. In the original post, the panels_data meta field (a serialized array) includes backslashes in one of its elements. When the post is saved in a secondary language, those backslashes are removed. This happens because WPML re-saves that field as part of its media duplication process, and the standard WordPress functions automatically strip the slashes. This behavior became noticeable starting from WPML 4.8, when changes were introduced to handle media duplication more efficiently. Workaround solution Disabling the setting “Automatically detect best options...” under WPML → Settings → Media Translation resolves the issue. After disabling this option, the widget can be saved correctly in the secondary language. Note the issue is caused by the way the custom widget stores its data (bypassing WordPress’s standard functions). WPML behaves as expected with widgets that follow WordPress conventions. I would advise rechecking on this and adapting your code to avoid any further future issues. Hope this helps and makes things more clear. Regards, Drazen
November 7, 2025 at 11:55 am #17556972
Malene	I’ve tried disabling the “Automatically detect best options for translating image texts” setting, but the widget still turns into a missing widget after saving.
November 7, 2025 at 12:44 pm #17557257
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, Let me double-check once more to ensure we’re not missing anything. Just to confirm, the original issue occurs because your custom code doesn’t fully follow the recommended WordPress standards. However, we can review again why this workaround isn’t working on the staging site. Please note that we might not be able to provide a complete workaround since it involves custom code that would need to be adapted accordingly. I will update soon. Regards, Drazen
November 10, 2025 at 6:31 am #17560716
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, Thank you for waiting. It seems our earlier suggestion was incorrect — it worked in some other cases, but not in this one. Our Tier 2 team has reviewed the issue and recommends that your developer investigate and adjust the implementation. Our process for handling images in secondary languages involves re-saving the SiteOrigin panels_data post meta with the updated image details. However, when this data is saved using the native update_post_meta function, WordPress automatically strips backslashes. Your developer can review the custom widgets and use wp_slash() to properly escape backslashes. This ensures that when update_post_meta later runs wp_unslash(), the single backslashes within the class element values are preserved correctly. Hope this make sense. Regards, Drazen