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: Exception
This topic contains 0 reply, has 0 voices.
Last updated by Bruno Kos 1 year, 5 months ago.
Assisted by: Bruno Kos.
| Author | Posts |
|---|---|
|
January 31, 2025 at 7:23 pm
#16657067
|
|
|
Background of the issue: Symptoms: Questions: |
|
|
February 1, 2025 at 5:09 pm
#16658673
|
|
 Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00) |
Hi, This is probably not related to the RC1 because we had this issue in several previous cases. That being said, is only one page affected (e.g. home) or all the pages? If so, if you are using the templates (footer, header) etc, can you do this for the templates and the page where the the issue occurs: 1. Open the default language page/template in Edit mode. Does the issue occur then? It is based on |
|
February 7, 2025 at 6:57 pm
#16681116
|
|
|
It is on all pages, and unfortunately this is not resolving the issue. All assigned Spanish translations are throwing that error, editing the Header/Footer and global widget that are on the page as described and resaving does not fix the issue. Here is the error: [07-Feb-2025 18:54:43 UTC] PHP Fatal error: Uncaught Error: Call to a member function get_class_name() on array in /home/1234567.cloudwaysapps.com/hqwfvqkvnu/public_html/wp-content/plugins/elementor-pro/modules/global-widget/widgets/global-widget.php:196 |
|
|
February 7, 2025 at 7:06 pm
#16681124
|
|
|
Now, when I go into a single page, it wants me to retranslate the entire page. All the pages have already been translated. They've been linked to their corresponding English translations. Resaving the linked translation does not work. This is incredibly frustrating after having all the pages translated and linking the corresponding Spanish to English translations. WPML seems to be requiring us to start completely from scratch. Am I missing something? Greatly appreciate any assistance you can provide to resolve this. |
|
|
February 10, 2025 at 6:51 am
#16685032
|
|
|
Bruno Kos Supporter |
Would you be willing to provide me with WordPress and FTP credentials so I could investigate the issue directly? So I would see this issue if I try to open the translation in the frontend? Or if you try to open translation in Elementor in the backend? To confirm, did you translate pages using Advanced Translation Editor (https://wpml.org/documentation/translating-your-contents/advanced-translation-editor/#side-by-side-contextual-translation-editor) or directly in Elementor? I marked your next reply as private so that you can safely add credentials. |
|
February 13, 2025 at 7:16 am
#16700148
|
|
|
Bruno Kos Supporter |
Before I check this further, can you update to our new versions? Does it fix the issue? We released it only 3 days ago. |
|
February 13, 2025 at 3:19 pm
#16703393
|
|
|
Unfortunately it is still throwing the error. |
|
|
February 14, 2025 at 11:58 am
#16706147
|
|
|
Bruno Kos Supporter |
I see, so the error occurs as soon as I want to open any translation in Elementor directly. And even if I visit the translated page in the frontend? To troubleshoot this problem, I'll install the Duplicator plugin and generate packages for further debugging purposes. I'll ensure to exclude all media files to maintain a minimal package size. You can find more information about the process here: https://wpml.org/faq/provide-supporters-copy-site/ Please confirm if this approach is acceptable to you. This will most likely required debugging because WPML troubleshooting functions did not help. |
|
February 15, 2025 at 3:53 am
#16708374
|
|
|
Yes, that's correct, frontend throws the error as well. Sounds good, thanks so much. |
|
|
February 17, 2025 at 10:27 am
#16713145
|
|
|
Bruno Kos Supporter |
I am checking this with our 2nd tier and will keep you posted. |
|
February 19, 2025 at 7:53 am
#16722440
|
|
|
Bruno Kos Supporter |
What if you try this: DELETE FROM wp_posts WHERE ID = 2994; Do Spanish pages work now (both frontend and backend)? |
|
February 24, 2025 at 6:25 pm
#16742674
|
|
|
I've pushed the site to a staging site before deleting that post ID. I'm not sure how to provide the new URL to you here privately in this reply. If you can provide that form again, that would be great. The credentials stay the same as the files/db are identical. Backend: when attempting to edit in Elementor loads the page, however the formatting looks off and there are some background images of elements that aren't showing. A form widget (I assume what we deleted) is gone. Frontend: loads until reaching an error. It appears a form widget doesn't load so the page fails at that point. Here is the PHP error: [24-Feb-2025 17:55:15 UTC] PHP Fatal error: Uncaught Error: Call to a member function get_class_name() on null in /home/1234567.cloudwaysapps.com/abcdefghij/public_html/wp-content/plugins/elementor-pro/modules/global-widget/widgets/global-widget.php:196 |
|
|
February 25, 2025 at 8:06 am
#16744202
|
|
|
Bruno Kos Supporter |
I set your next reply as private. Please install https://wordpress.org/plugins/pexlechris-adminer/ to that site and provide me FTP and WordPress credentials. |
|
February 26, 2025 at 10:05 am
#16750082
|
|
|
Bruno Kos Supporter |
I am checking with the help of our 2nd tier and will keep you posted. |
|
February 27, 2025 at 7:28 am
#16754124
|
|
|
Bruno Kos Supporter |
We’ve prepared a workaround to address the issue with the global widget. Please follow these steps: 1. Navigate to: .../wp-content/plugins/elementor-pro/modules/global-widget/widgets/global-widget.php 2. Add the following code below:
if ($data) {
if (
$data['widgetType'] === 'global' &&
(get_post_type($data['templateID']) !== 'elementor_library' || $data['templateID'] === '' || $data['templateID'] == 2994)
) {
$data['templateID'] = 2970;
}
}
Placement: Insert it right below this function declaration:
public function __construct( $data = [], $args = null ) {
This adjustment ensures that the templateID is set to 2970 , which exists on your site. 3. After implementing this fix: While this workaround should resolve the issue temporarily, we have a few concerns: - Post ID 2994 appears to be a revision, not an elementor_library entry. - This fix is specific to one templateID . 2970 . If multiple pages are affected, it may be better to recreate or duplicate the global widget and remove the original to prevent further issues. - Potential Elementor bug: post_type before processing global widgets. Please let us know how you'd like to proceed or if you have any additional context that might help identify the root cause. |
