PHP 8.x is breaking my translation rendering

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 8 replies, has 2 voices.

Last updated by Andrey 1 year, 10 months ago.

Assisted by: Andrey.

Author	Posts
August 7, 2023 at 8:20 pm #14166165
benediktS-12	I am trying to: Move from PHP 7.4 to 8.x (bc I have to) Link to a page where the issue can be seen: hidden link vs hidden link I expected to see: The same rendering as in the german version. Instead, I got: A broken website with a 500 status on the /en/ folder. The hoster is shutting down 7.4 on Thursday (!), so I have to move to 8.x. I tried 8.1 and 8.2 so far, and both version render the same error. I activated error log, so pls see the console for detailed errors. Everything runs smooth so far on 7.4. So far I found out that it’s only the home page, as others like hidden link work fine. Also, when switching to a vanilla theme, it renders without errors. But I can’t find any clue about what is causing the error. I appreciate any help! Please let me know if you need anything more. Thanks a lot in advance! Bene Kögl
August 8, 2023 at 2:43 pm #14170191
Andrey WPML Supporter since 06/2013 Languages: English (English ) Russian (Русский ) Timezone: Europe/Kyiv (GMT+03:00)	Thank you for contacting WPML support. I'll be happy to help you with this. 500 error means that there is an error in the PHP code that your site runs. When errors are not caught, the server stops everything and returns a page that says “500 error” or an empty page. Different servers are configured to display these errors slightly differently, but they all mean the same – there is an unhandled PHP error in the site’s code. First, you need to see what the errors are. Guessing what might be the problem and trying different solutions may lead to even more trouble. The first step is to enable debug. You can do this by adding a few lines to the site’s wp-config.php file. With error log enabled, you will see what the actual problem is. To enable it, open your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to: define('WP_DEBUG', true); In order to enable the error logging to a file on the server you need to add yet one more similar line: define( 'WP_DEBUG_LOG', true ); In this case, the errors will be saved to a debug.log log file inside the /wp-content/directory. https://wpml.org/documentation/support/debugging-wpml/ Let me know what you see after the debug mode has been enabled.
August 8, 2023 at 5:24 pm #14171629
benediktS-12	Hi Andrey! Thanks for your help! I already activated WP_DEBUG, but it didn’t give me anything I could make sense of. However, the WP_DEBUG_LOG throws one fatal error – besides a ton of deprecaton warnings that don’t seem to be fatal (I copied the site to a local machine): [08-Aug-2023 17:20:21 UTC] PHP Fatal error: Uncaught TypeError: ltrim(): Argument #1 ($string) must be of type string, array given in /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/formatting.php:4415 Stack trace: #0 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/formatting.php(4415): ltrim(Array) #1 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/themes/imed/template-parts/blocks/doctors/doctors.php(334): esc_url(Array) #2 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/plugins/advanced-custom-fields-pro/pro/blocks.php(678): include('/Users/bene/Loc...') #3 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-hook.php(308): acf_block_render_template(Array, '', false, 4110, Object(WP_Block), Array) #4 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters('', Array) #5 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #6 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/plugins/advanced-custom-fields-pro/pro/blocks.php(652): do_action('acf_block_rende...', Array, '', false, 4110, Object(WP_Block), Array) #7 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/plugins/advanced-custom-fields-pro/pro/blocks.php(569): acf_render_block(Array, '', false, 4110, Object(WP_Block), Array) #8 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/plugins/advanced-custom-fields-pro/pro/blocks.php(502): acf_rendered_block(Array, '', false, 4110, Object(WP_Block)) #9 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-block.php(258): acf_render_block_callback(Array, '', Object(WP_Block)) #10 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-block.php(244): WP_Block->render() #11 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-block.php(244): WP_Block->render() #12 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/blocks.php(1072): WP_Block->render() #13 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/blocks.php(1110): render_block(Array) #14 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/class-wp-hook.php(308): do_blocks('<!-- wp:acf/hea...') #15 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/plugin.php(205): WP_Hook->apply_filters('<!-- wp:acf/hea...', Array) #16 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/post-template.php(255): apply_filters('the_content', '<!-- wp:acf/hea...') #17 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/themes/generatepress/content-page.php(73): the_content() #18 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/template.php(785): require('/Users/bene/Loc...') #19 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/template.php(718): load_template('/Users/bene/Loc...', false, Array) #20 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/general-template.php(204): locate_template(Array, true, false, Array) #21 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/themes/generatepress/inc/theme-functions.php(568): get_template_part('content', 'page') #22 /Users/bene/Local Sites/imed19-privat/app/public/wp-content/themes/generatepress/page.php(34): generate_do_template_part('page') #23 /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/template-loader.php(106): include('/Users/bene/Loc...') #24 /Users/bene/Local Sites/imed19-privat/app/public/wp-blog-header.php(19): require_once('/Users/bene/Loc...') #25 /Users/bene/Local Sites/imed19-privat/app/public/index.php(17): require('/Users/bene/Loc...') #26 {main} thrown in /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/formatting.php on line 4415 Can you make any sense of that? I can’t, I am afraid 🙁
August 8, 2023 at 5:26 pm #14171633
benediktS-12	I can send you the whole log as well. How do I do that here?
August 8, 2023 at 8:32 pm #14172215
benediktS-12	I think I have a clue about what’s going on. I could narrow it down to a WP Query that’s inside a block. It iterates through the 'post_type' => 'doctors' to retrieve the detail information of the respective doctors. Click on a photo in the german version, and you’ll see what I mean. It seems though, that not every doctor has an english translated text, and since version 8.x, that throws an error in the translated version. But, if that’s true, I have no idea how I can fix it. Do I have to alter the query? It’s basically just a standard query like this one plus some ACF field outputs (ACF multilngual is also present, and for the german language version, it works just fine): https://developer.wordpress.org/reference/classes/wp_query/#standard-loop Thanks for your help!
August 8, 2023 at 9:45 pm #14172351
benediktS-12	Okay, another update: I found out that optimizing and troubleshooting the PHP code of the query didn’t help. But after some trial-and-error, I learned that re-opening every single 'doctor' postmin the editor, changing its option to 'edit in wordpress editor' and saving it did fix the issue – at least on my local machine. But as I wanted to reproduce the same on the staging server, I couldn’t change the editing setting – it always jumped back to the WPML editor. I am seriously losing my nerves here … the hoster will shut down PHP 7.4 on Thursday, and I am still fishing in cloudy waters here.
August 9, 2023 at 8:53 am #14173735
Andrey WPML Supporter since 06/2013 Languages: English (English ) Russian (Русский ) Timezone: Europe/Kyiv (GMT+03:00)	Thank you for your feedback. Yes, you are right. The fatal error which breaks the site could be: [08-Aug-2023 17:20:21 UTC] PHP Fatal error: Uncaught TypeError: ltrim(): Argument #1 ($string) must be of type string, array given in /Users/bene/Local Sites/imed19-privat/app/public/wp-includes/formatting.php:4415 We are compatible with PHP 8.x. I noticed that your staging site uses very outdated WPML plugins with the latest WP. Could you please update your WPML plugin to the latest version 4.6.5, and add-ons to benefit from the latest bug fixes and improvements? This may not necessarily resolve your problem. However, in order to troubleshoot the issue best, we need to work on the latest code available. You can check the latest released versions under "My Account -> Downloads" on this site. Instructions to update can be found here: http://wpml.org/faq/install-wpml/ Please remember to back up your database first before you proceed. Let me know if the issue persists after an update has been done.
August 9, 2023 at 12:29 pm #14175653
benediktS-12	Hi Andrey! Thanks for your answer! I updated the plugins, but that didn’t do the trick. In the meantime, I am happy to report that I could resolve the issue … it was quite late yesterday night, and I was already dead tired, so couldn’t answer any earlier, sorry. Here’s how I got there: I re-opened every english translation of the 'doctors' post type, changed the translation’s option to 'edit in wordpress editor' and re-saved it. I did this for all 29 published posts. After that, the error was gone. How I got there? Let’s say I had a vague idea, as I could narrow the error down to the particular wp_query, but there wasn’t any PHP or HMTL code error in it. So I looked at the posts themselves, knowing that the base language worked fine. I reproduced the solution on the staging site, now it’ll be next to reproduce it on the live site. Do you have a clue what had happened there? Thanks for your support anyway!
August 9, 2023 at 8:11 pm #14178223
Andrey WPML Supporter since 06/2013 Languages: English (English ) Russian (Русский ) Timezone: Europe/Kyiv (GMT+03:00)	I am glad to hear that it works now. Thanks for the update. Suppose you again change the translation option to translate with the WPML translation editor and get no error. In that case, I suspect that by updating every post you did, some custom post type meta fields were updated with missing information that could be the reason for the error.