This thread is resolved. Here is a description of the problem and solution.
Problem: You are experiencing a fatal error when saving or editing a translation page in WordPress, where WPML's hook crashes due to expecting a WP_Post object but receives null. This issue persists even after updating to WPML 4.9.2. Solution: We have investigated the issue and found that it appears to be specific to your hosting environment rather than a bug in WPML itself. We recommend contacting your hosting provider to ensure that the REST API is not blocked and to temporarily disable any restrictive security layers that might be interfering with the save process. Additionally, consider whitelisting WPML-related requests from these protections. If the problem continues, you might need to consider changing your server. For more details on REST API dependencies, please visit https://wpml.org/documentation/support/rest-api-dependencies/.
If this solution does not resolve your issue or seems irrelevant due to being outdated or not applicable to your case, 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 needed, please open a new support ticket for further assistance.
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.
The site migration is now complete and oss-material.ca is properly registered as an independent site. However, the original fatal error still persists even after updating to WPML 4.9.2.
The error occurs when saving or editing an existing translation page in the WordPress editor. WordPress attempts to create a post revision during save, wp_insert_post returns null, and WPML's hook crashes because it expects a WP_Post object.
Full error details:
An error of type E_ERROR was caused in line 55 of the file:
wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/src/UserInterface/Web/Infrastructure/WordPress/CompositionRoot/Config/Event/Translation/Links/ItemUpdateEvent.php
Error message:
Uncaught TypeError: Argument #2 ($post) must be of type WP_Post, null given, called in wp-includes/class-wp-hook.php on line 343
Stack trace summary:
- edit_post() is called
- wp_update_post() triggers wp_insert_post()
- wp_after_insert_post() fires
- wp_save_post_revision_on_insert() is called
- wp_save_post_revision() → _wp_put_post_revision() → wp_insert_post() returns null
- do_action('save_post', 2572, NULL) is fired with null post
- WPML's ItemUpdateEvent closure receives null instead of WP_Post and crashes
This appears to be a bug in WPML 4.9.2 where the ItemUpdateEvent hook does not handle a null $post argument gracefully. Could you please escalate this as a bug report or provide a fix?
Are you sure that the entire database and all files were migrated correctly?
Would it be possible to perform a test migration to a local environment using an alternative method (e.g., a plugin like Duplicator or All-in-One WP Migration within the fix above) and check whether the issue still occurs?
I’ve also enabled debug information for this support ticket. Please follow this guide to retrieve it from your site and share it
Same setup and content works fine on another server where I copied the content from.
I also migrated the very same web page on another (3rd one for testing purposes) server, and that works fine too.
Also used UpdraftPlus for the test migration.
I suspect this may be related to a server configuration issue or possibly corrupted database entries.
I would need temporary access to your site (wp-admin and FTP)—preferably to a staging or test environment where the issue can be reproduced. When you submit your next reply, you will find the required fields below the comment area. Please note that this information is private and will only be visible to you and me.
Additionally, please provide the exact steps to reproduce the issue, so I can follow the same process on my end.
Let me know if I have your permission to temporarily install the Adminer plugin.
The fatal error sometimes occurs.
I use WordPress editor to create translated versions of the pages.
I do not use translation dashboard since I need to change page content and layout when necessary.
So to create a language version of the related page I click + sign on the right of the page name (ie: please see the attached 001.png as an example to create the Portuguese version of the page).
Then I copy the content from English verison and then change all the text (content) to that language (ie: Portuguese).
After clicking publish, WordPress normally saves. It generally does.
But sometimes I get that fatal error (did not get a screenshot but it says: "There has been a critical error on this website. Please check your site admin email inbox for instructions. If you continue to have problems, please try the support forums. Learn more about troubleshooting WordPress.").
The interesting part is that, the page is saved despite that error.
I'm not sure if there's been a firewall delay just about that saving process and WPML can not communicate with its servers at that exact delay period, or there's a mistake on the database itself. I'm not a code guy, just try to understand and solve the issue.
Following up on this ticket. Here is a summary of what has been done so far and the current status on hidden link :
**What was done:**
- WPML Multilingual CMS updated from 4.8.4 to 4.9.2 via FTP
- WPML String Translation updated from 3.4.1 to 3.5.1 via FTP
- Site migration completed: oss-material.ca is now properly registered as an independent site, alias to tgsteels.com has been removed
- Hosting confirmed ModSecurity has been disabled on the server
**Current status:**
The fatal error in ItemUpdateEvent.php on line 55 still persists. It is now confirmed to be triggered not only when saving/editing translation pages, but also when TablePress performs a wp_insert_post() call (e.g. when copying a table).
This confirms the bug is in WPML's ItemUpdateEvent hook, which does not handle a null $post argument gracefully. Any plugin that calls wp_insert_post() can trigger this crash.
Full error:
Uncaught TypeError: Argument #2 ($post) must be of type WP_Post, null given in ItemUpdateEvent.php on line 55
**REST API 403 Forbidden Issue:**
After extensive troubleshooting with the hosting provider, it was confirmed that the server's firewall is blocking loopback requests to the REST API endpoint (wp-json/wpml/v1/rest/status), returning 403 Forbidden. The hosting team disabled ModSecurity but the issue persisted, suggesting another security layer (possibly Imunify360 or a similar firewall) is responsible.
As a workaround, we implemented the following code via the Code Snippets plugin, which intercepts WPML's REST API status check before it reaches the server and returns a synthetic 200 OK response:
After applying this, the admin panel became significantly faster and the 403 errors stopped.
**ItemUpdateEvent Fatal Error:**
The fatal error in ItemUpdateEvent.php line 55 (Argument #2 ($post) must be of type WP_Post, null given) also appears to have stopped occurring since applying the workaround above, suggesting the two issues may be related.
We are sharing this in case it is useful for your team to investigate the root cause. The site is now stable.
Following up on the ItemUpdateEvent fatal error. The issue is still occurring.
Current behavior:
- When saving a page, the content IS saved successfully
- However, immediately after saving, WordPress attempts to create a post revision
- During the revision creation, wp_insert_post() returns null
- WPML's ItemUpdateEvent hook crashes because it receives null instead of a WP_Post object
- The admin page then shows a fatal error screen
- I have to navigate away and continue from another browser tab
This is happening when editing translation pages in the WordPress classic editor.
Full error:
Uncaught TypeError: Argument #2 ($post) must be of type WP_Post, null given in ItemUpdateEvent.php on line 55
Call stack confirms:
- edit_post() is called
- wp_update_post() saves the page successfully (post ID 2759)
- wp_save_post_revision_on_insert() tries to create a revision (post ID 2770)
- wp_insert_post() for the revision returns null
- do_action('save_post', 2770, NULL) fires with null post
- WPML's ItemUpdateEvent closure crashes
Note: The REST API 403 issue has been resolved via a pre_http_request filter workaround. This ItemUpdateEvent error is a separate, unresolved issue.
Could you please provide a fix or patch for this bug?
I’ve taken a close look at the issue and attempted multiple times to reproduce the error by following your steps when saving a post translation, but I was unable to replicate it. I also enabled the debug.log to monitor for any related errors during the process.
Based on my findings, the issue appears to be specific to your hosting environment. This is why I’m unable to escalate it further at this stage—most likely, it would not be reproducible on a local setup at all. This strongly suggests that the root cause is related to server configuration or security settings (layers), as you already mentioned, and you have already tested the same site on different servers, where everything works as expected.
It’s possible that certain server-side security layers (such as firewalls, mod_security, Imunify360, or similar protections) are interfering with the save process, which could result in the fatal error you’re experiencing.
Regarding the REST API, this is not a bug. The REST API should not be blocked, as WPML relies on it for core functionality, just like WordPress itself.
I would recommend contacting your hosting provider again and asking them to ensure the REST API is not blocked. Temporarily disable any restrictive security layers for testing. Or whitelist/exclude WPML-related requests from those protections.
If it persists, consider changing the server as well, since we are unable to fix this on our end.
Thank you for your patience and efforts in troubleshooting this issue.
I have decided to migrate the website to a new server environment that is specifically optimized for WordPress. I’m hopeful that on this new infrastructure, I won't need to rely on the workaround we implemented to bypass the previous server's limitations.
