To clarify -- these files in the error were NOT edited at the time of the error, I checked twice. And I checked again by doing a diff with a fresh WordPress install. I had to remove the broken line -- shown below -- because it crashes WordPress. This line does not crash all WordPress blogs, obviously, and I have another blog on the same LEMP stack without the fatal error. How is "kses" activated in this case? Is it the content of the blog? I don't know, but I don't see any plugin or theme in the stack trace.

Here's the error:

[error] FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in /home/www-data/example.com/wp-includes/kses.php:1871
#0 /home/www-data/example.com/wp-includes/kses.php(1871): in_array()
#1 [internal function]: wp_kses_named_entities()
#2 /home/www-data/example.com/wp-includes/kses.php(1842): preg_replace_callback()
#3 /home/www-data/example.com/wp-includes/formatting.php(981): wp_kses_normalize_entities()

This line does not work in PHP8:

return ( ! in_array( $i, $allowedentitynames, true ) ) ? "&$i;" : "&$i;";

There's no plugin or theme referring to "allowedentitynames" as per grep.

  • This make post claims there are only deprecation notices left. Which WP version are you on? Could also be that a plugin/theme is using a WP function wrong, try to deactivate them one by one and check if the error disappears.
    – kero
    Jul 29 at 9:27
  • @kero Latest WP version as of this morning.
    – PJ Brunet
    Jul 29 at 18:51
  • @kero Removed PHP8 from the question, keeping an open mind as to what the problem is.
    – PJ Brunet
    Jul 29 at 20:51
  • 2
    Does your installation configuration or one of your extensions define the CUSTOM_TAGS constant?
    – bosco
    Jul 30 at 22:37
  • is this a full stack trace? That variable is passed through filters that can be misused e.g. it's passed through an array_map with _wp_add_global_attributes, and if you define CUSTOM_TAGS it prevents WordPress from defining that variable.
    – Tom J Nowell
    Jul 30 at 23:23

2 Answers 2


When you use the deprecated CUSTOM_TAGS constant, you have to define the variables WordPress would normally create in kses.php at the top. If you do not then you will encounter this issue.

 * Specifies the default allowable HTML tags.
 * Using `CUSTOM_TAGS` is not recommended and should be considered deprecated. The
 * {@see 'wp_kses_allowed_html'} filter is more powerful and supplies context.
 * @see wp_kses_allowed_html()
 * @since 1.2.0
 * @var array[]|false Array of default allowable HTML tags, or false to use the defaults.
if ( ! defined( 'CUSTOM_TAGS' ) ) {
    define( 'CUSTOM_TAGS', false );

Instead, you should use the wp_kses_allowed_html filter to modify which tags are allowed, using the context parameter to control when and where the adjusted tags are usable:


Just keep in mind that the list of tags is chosen to avoid allowing dangerous things into posts and comments. E.g. iframes or script tags. Changing these will have significant security consequences.

How is "kses" activated in this case? Is it the content of the blog?

kses functions are used everywhere in WordPress and play a pivotal role in security. E.g. wp_kses_post is used to strip out dangerous tags when saving a post, and wp_kses can strip out tags and attributes that don't fit a whitelist. wp_kses and it's wrapper functions act as both pseudo-escaping and as sanitisation functions.

  • This fixed the fatal error for me, also thanks to @bosco for pointing out this possibility. The particular blog is over 10 years old and the "CUSTOM_TAGS" was set many years ago. I don't know the exact version of PHP where this in_array() warning was converted to an error, but I believe it's somewhere between 7.0 and 8.1
    – PJ Brunet
    Jul 31 at 7:36
  • I doubt it's a PHP version issue, if not an error it will have filled the log with warnings and notices. Based on a reading of the problem this will have been a major security problem for those 10 years while it was there, glad you have it resolved now
    – Tom J Nowell
    Jul 31 at 18:26

Never edit core files, and definitely do not make this change.

Looking at the source the problem doesn't seem related to PHP 8.1 at all. Something in a theme or plugin is causing $allowedentitynames to be null, which it should not be. See this trac ticket for a previous discussion with somebody who encountered this issue.

  • Of course, I'm not advocating anyone comment out core code LOL. I added the stacktrace to the question. There's no theme or plugin in the error.
    – PJ Brunet
    Jul 29 at 19:14
  • Maybe PHP is not the problem, but that was the main change moving from one LEMP server with PHP 7 to another LEMP server with PHP 8. Same files. I tried grep -r "allowedentitynames" * in pllugins and themes and no matches.
    – PJ Brunet
    Jul 29 at 19:55
  • Stack traces have a configurable depth in PHP - the one you have provided is truncated. The absence of plugin or theme from a truncated stack trace is not evidence that a plugin or theme is not at the top of the stack - or as it may be, that it is not otherwise responsible for producing the error even if it is not the origin of the call which produced the error.
    – bosco
    Jul 30 at 22:17
  • My stack trace is not trucated LOL. Nice try though @bosco
    – PJ Brunet
    Jul 30 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.