bcworkz

Well, as the notice says, the cause is is_page() was called too early. The post_status on null warnings are likely knock on effects from trying to call get_post_states() before the query has been run, because the passed $post object doesn’t yet have valid information.

The is_page() error on line 6131 of functions.php is not useful data for finding the root cause since it’s merely part of the function wp_trigger_error(). You need a debug backtrace to learn what the initial call was that started the entire problem.

Try hooking the ‘wp_trigger_error_run’ action hook and dumping out the return from debug_backtrace() in the callback. The output will give us a better idea of the root cause. Output may not be readily visible on the requested page. You may need to use your browser’s source HTML view to see the output. Search for “array” if the output isn’t immediately apparent.

The typical reason for such an error is a plugin or theme tried calling is_page() immediately on load instead of hooking an action that fires after the query has run.

If you’re not seeing the default block editor view, then threadi’s reply above is most appropriate.

Using plain http:// protocol (instead of https://) on port 443 is invalid. Normal browser requests are typically automatically upgraded to https://. Not so with cURL. Where ever cURL is getting your domain name URL needs to be updated to use https://. I assume this is the site and home URL option settings. On multisite these are not that easy to alter. Try requesting /wp-admin/options.php (type it in, there’s no link in network settings), then searching the long list for the right settings. Don’t forget to scroll to the bottom to click the update button after making changes.

If even options.php doesn’t work, the settings can be updated via the phpMyAdmin app, usually accessed through your hosting account.

Could this be related to the absence or misconfiguration of GD/Imagick?

If neither one is present then that would be a problem. Assuming one or the other is at least installed, the error you’re seeing is because your server responded to an upload request in an unusual manner. As the message suggests, it could be due to lack of sufficient memory or the server being too busy. Or anything else that would cause the server to respond with anything aside from 200 OK. If this happens intermittently and inconsistently, the issue is likely due to lack of adequate server resource.

If the problem occurs consistently with only certain reasonably sized images, and others upload just fine, then the problematic files could be formatted in a way that the image processor doesn’t recognize. Perhaps the image processor version (GD or Imagick) is in need of updating or its configuration is flawed. Seek assistance through your host’s tech support.

There’s no predefined function since apparently a 0xFFFF character is entirely unexpected. However, the wp_insert_post() function does call sanitize_post() before saving data. There are numerous filters available through which you could add code to search and remove offending characters. For example the “pre_post_content” filter. There are similar filters for other default fields such as post_excerpt and post_title.

The actual removal code could be something like:

$invalid = array('￿',); // additional undesirable characters may be added to this array
return str_replace( $invalid, '', $content );

You only need to wrap this with appropriate filter callback code.

This would resolve the problem for the default fields of any future posts, but does nothing for existing data, nor for data from get_field('descripcion').

There is a “esc_xml” filter available through which you could search and remove the invalid character. Of course it would only resolve XML errors, the invalid character would still appear on web pages. While it wouldn’t throw any errors, having the invalid character represented with a ￿ on web pages is not ideal. There are other filters such as “the_content” through which the character could be removed for web pages. But if you could prevent the character from being saved to start with, you needn’t deal with it on output. As I mentioned earlier, you could do a one time global search and remove operation to rid your DB of any existing invalid characters.

To prevent invalid characters from being saved in custom fields like ‘descripcion’, you might be able to use a filter such as “sanitize_post_meta_{$meta_key}”, but I’m not sure how your custom fields plugin saves data. If the plugin offers similar filters, you’re probably better off using one of those.

Happy new year!

The current style enqueue scheme has no provision to defer style loading. To do so, you’d need to work outside of the enqueue scheme. You could hook the “wp_footer” action and output any desired style blocks or link references you desire. Of course you’d then need to manage any precedence yourself.

As you may know, enqueued scripts currently have a provision to defer loading, but not styles.

If you’d like to see a more formal way to do so within the core style enqueue scheme, you could post an enhancement request ticket in the WP Trac system. Please first search existing tickets to ensure there’s not already an existing similar ticket

Escaping is still the right thing to do even if it doesn’t resolve the issue 🙂

Your invalid character encodes as 0xFFFF, assuming it copy/pasted correctly. I’m pretty sure that really is an invalid UTF-8 character code. So what is it doing in your content in the first place? Would you consider replacing it in your database? You could use the Better Search and Replace plugin to find all instances and replace it with a proper UTF-8 character.

It looks like it was supposed to be some other letter (maybe with a diacritic) that somehow got improperly encoded. Does it occur in place of a specific letter? Or is it replacing a variety of different letters? If a variety, you may need to manually replace them with the right letters.

And if it can be replaced, you might need to consider how it got there and take steps to ensure it doesn’t happen again.