alele

Hello again,

I have one final, very precise update for your developers based on the nightly run results.

1. Confirmation: The TypeError is Resolved After applying the type cast $str = (string) $str; in the wxr_cdata function, the Fatal TypeError in line 634 has completely disappeared from the logs of Instance A. This proves that the string-casting successfully handles the PHP 8.4 strict typing requirement and prevents the backup process from being interrupted at this stage.

2. The Remaining Root Cause (Warning Analysis) While the fatal TypeError is now gone thanks to the fix, the logs show that the preceding warning remains: WARNING: Attempt to read property "post_type" on null

This warning was already present before the fix, but now that the crash is resolved, it confirms the underlying issue: earlier in the execution chain, the plugin attempts to access a post object that is already null. This is the reason why a null value was being passed to the wxr_cdata function in the first place.

3. Technical Conclusion for the Dev-Team:

• Immediate Safety: The type cast in wxr_cdata is a necessary and effective safety net to ensure PHP 8.4 compatibility.
• Structural Fix: There seems to be a missing null-check/object-validation while iterating through the posts in the legacy XML export module. The plugin should verify if the post object is valid (e.g., if ( ! is_object( $post ) ) continue;) before attempting to access $post->post_type or passing content to the XML wrapper.

I am now confident that my backups are running safely again with the manual patch, but I look forward to an official release that includes these null-checks for the legacy WXR module.

Best regards,

Hello @saranshwpm

Thank you for your feedback. To clarify: I am not 100% sure if these are legacy jobs, but the problem appeared immediately after the update to v5.6.9.

It is important to note that my environment (PHP 8.4.15) has been running stable for a longer time without any issues. The error only started occurring with this specific BackWPup version, which points to a regression in the new release.

I’ve analyzed the code at the crash site: class-jobtype-wpexp.php on line 634.

The Analysis: In v5.6.9, the function wxr_cdata($str) passes $str to wp_is_valid_utf8($str). If a database field (like an excerpt or meta value) returns null, PHP 8.4 throws a fatal TypeError.

PHP

if ( function_exists( 'wp_is_valid_utf8' ) ) {
    $is_valid_utf8 = wp_is_valid_utf8( $str ); // Line 634 - Fatal here if $str is null
}

This explains why it worked before: Either the function call was different, or previous versions handled the type casting more gracefully.

Suggested Fix: Please add a simple type cast at the beginning of the wxr_cdata function to ensure compatibility with PHP 8.4: $str = (string) $str;

This should fix the issue for all users on modern PHP environments regardless of their job configuration. Could you please look into this for the next patch?

Thank You.

Hi @zodiac1978

What about adding this to the global settings like “Default action after saving a post” (clear post, clear all, clear nothing)?
In addition adding a “clear cache or this page” functionality to a submenu for the admin-bar icon (which currently clears the site cache) would also be nice.

This would be great.

Thank you
Alexander