Title: alele's Replies | WordPress.org

---

# alele

  [  ](https://wordpress.org/support/users/alele/)

 *   [Profile](https://wordpress.org/support/users/alele/)
 *   [Topics Started](https://wordpress.org/support/users/alele/topics/)
 *   [Replies Created](https://wordpress.org/support/users/alele/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/alele/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/alele/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/alele/engagements/)
 *   [Favorites](https://wordpress.org/support/users/alele/favorites/)

 Search replies:

## Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[BackWPup – WordPress Backup & Restore Plugin] TypeError in v5.6.9: wp_is_valid_utf8() null given in class-jobtype-wpexp.php](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/)
 *  Thread Starter [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [1 week ago](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/#post-18893805)
 * 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,
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[BackWPup – WordPress Backup & Restore Plugin] TypeError in v5.6.9: wp_is_valid_utf8() null given in class-jobtype-wpexp.php](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/)
 *  Thread Starter [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [1 week ago](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/#post-18893777)
 * Hello again,
 * Thank you for the update and for sharing the report with your developers.
 * I have further confirmation for you: I conducted a comparative test across two
   independent WordPress instances last night.
    - **Instance A (with my fix):** The scheduled backup (Cron) ran perfectly without
      any errors.
    - **Instance B (original v5.6.9):** The scheduled backup failed again with the
      same `TypeError`.
 * This confirms that the proposed fix works perfectly for PHP 8.4 environments.
 * Interestingly, the error **never occurs when triggering the job manually** via
   the BackWPup dashboard. It only appears during the **scheduled (Cron) execution**,
   which seems to trigger the legacy XML export path more strictly.
 * For your developers, here is the exact location and the fix I applied to **`inc/
   class-jobtype-wpexp.php`** (starting around line 628):
 * PHP
 *     ```wp-block-code
       private function wxr_cdata( $str ) {
           $str = (string) $str; // <--- This line fixes the PHP 8.4 TypeError
   
           // Use wp_is_valid_utf8() if available (WP 6.9+), otherwise fall back to seems_utf8().
           if ( function_exists( 'wp_is_valid_utf8' ) ) {
               $is_valid_utf8 = wp_is_valid_utf8( $str ); // Line 634 (original)
           } else {
               $is_valid_utf8 = seems_utf8( $str );
           }
           // ...
       ```
   
 * By casting `$str` to a string, we ensure that `wp_is_valid_utf8` never receives
   a `null` value, which is what causes the fatal error in PHP 8.4.
 * I hope this helps you to release a patch soon so I can revert my manual changes
   and return to the official version.
 * Best regards,
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[BackWPup – WordPress Backup & Restore Plugin] TypeError in v5.6.9: wp_is_valid_utf8() null given in class-jobtype-wpexp.php](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/)
 *  Thread Starter [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [1 week, 1 day ago](https://wordpress.org/support/topic/typeerror-in-v5-6-9-wp_is_valid_utf8-null-given-in-class-jobtype-wpexp-php/#post-18892884)
 * Hello [@saranshwpm](https://wordpress.org/support/users/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
 *     ```wp-block-code
       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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce PayPal Payments] How to translate Buy Now button?](https://wordpress.org/support/topic/how-to-translate-buy-now-button-2/)
 *  [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [3 years, 5 months ago](https://wordpress.org/support/topic/how-to-translate-buy-now-button-2/#post-16222842)
 * We also have exactly the same problem.
 * I can confirm german translations are not working in firefox at all.
 * Tested in multiple browsers. It seems to work in Chrome and Edge. In Firefox 
   always shows “Buy Now” instead of “Jetzt kaufen”.
 * We are now using old Paypal Standard method.
 * Thanks in advance.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Cachify] empty cache for single articles at gutenberg editor](https://wordpress.org/support/topic/empty-cache-for-single-articles-at-gutenberg-editor/)
 *  Thread Starter [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [6 years, 8 months ago](https://wordpress.org/support/topic/empty-cache-for-single-articles-at-gutenberg-editor/#post-11833856)
 * Hi [@zodiac1978](https://wordpress.org/support/users/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
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Ultimate Addons for Elementor] Choose a Templates with suitable widths?](https://wordpress.org/support/topic/choose-a-templates-with-suitable-widths/)
 *  Thread Starter [alele](https://wordpress.org/support/users/alele/)
 * (@alele)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/choose-a-templates-with-suitable-widths/#post-9892418)
 * Hi,
 * > Are those extra templates from your theme?
 * Yes exactly! I can only choose between the default template of my theme and the
   elementor carvas option.
 * see screenshot:
    [https://drive.google.com/file/d/1GPIoL44AZjSJOy-cesYxjGfMA77hZ_dA/view?usp=sharing](https://drive.google.com/file/d/1GPIoL44AZjSJOy-cesYxjGfMA77hZ_dA/view?usp=sharing)
 * I would like to use the (extra) templates from my thema as base for the Header/
   Footer template. But I can not select it on the right side (see screenshot)

Viewing 6 replies - 1 through 6 (of 6 total)