According to various investigations, unlike PHP7.0, updating to PHP8.0 does not seem to have any effect on WordPress operation or improve performance, but it will still be in the future. With that in mind, I want to make sure that the latest version works fine, and I remember running this site on PHP 8.0 since early 2021.

Meanwhile, when I recently connected to the server via FTP, I noticed that the debug log file was ridiculously large.

The date seems to be from PHP 8.0, and when I opened it while saying “Nothing appeared on the screen even if I set the debug mode to true …”, the following line warns me Was spit out a lot to the log as

PHP Warning:  Attempt to read property "ID" on null in /Hierarchy up to the theme/functions.php on line 〇〇

Translated literally, it says, “I tried to read an empty ID in line 〇 in functions.php.” It’s not an error because it’s a warning, but I’m curious, so when I checked the target line, it was the part where the value of the custom field was judged and processed (the code will be described later). The code should be correct …

If I could deal with it, the conclusion was “What is that?”, But I was able to deal with it, including why this warning appears, so I will introduce it as a memorandum.

This time, it will be an example of “Handling custom fields”, but I think that the basics are the same for other events, so I hope it will be helpful to someone.

Why did the Warning start to appear?

Why did the Warning start to appear in the first place? The answer is that PHP 7.x has changed to PHP 8.0, and it has become stricter than “if there was no XX …”.

In this case, when calling the value of a custom field in a user-defined function, when the front page or archive page, which is the content for which the custom field is not set in the first place, is accessed, “There is no such custom field! I was warned.

I had a lot of trouble getting to this point because the log is only spit out here in the program, not where it was accessed, as shown below.

PHP Warning:  Attempt to read property "ID" on null in /Hierarchy up to the theme/functions.php on line 〇〇

What made me realize was that the number of warning lines was overwhelmingly small for the number of PVs (access requests) on this site.

If the cause is known, it seems that we can deal with it … So I edited the code immediately.

Code modification (example)

The user-defined function that was warned is for adding an English site to the subdirectory introduced on the following page.

The problem was the following code, “Judge each language page with or without custom fields and output the appropriate hreflang and canonical tags.“

/**** Multi-language header output (main site) ****/
function hab_add_multi_lang_header_parent(){
//Variable setting
	global $post;
	$ha_mlang_customfield = get_post_meta($post->ID, 'cf_en_url', true);
	$ha_ima_url=(empty($_SERVER["HTTPS"]) ? "http://" : "https://") . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
//Other than posts / fixed pages
	if(!is_singular()){
		echo '<link rel="canonical" href="' .$ha_ima_url. '" />';	
//When there is an input in cf_en_url on the post / fixed page
	}elseif($ha_mlang_customfield){
		echo '<link rel="alternate" href="' .$ha_mlang_customfield. '" hreflang="en" />';
		echo '<link rel="alternate" href="' .$ha_ima_url. '" hreflang="ja" />';
		echo '<link rel="canonical" href="' .$ha_ima_url. '" />';
//When there is no input in cf_japanese_url on the post / fixed page
	}else{
		echo '<link rel="canonical" href="' .$ha_ima_url. '" />';	
	}
}
add_action('wp_head', 'hab_add_multi_lang_header_parent',1);

The code flow itself is processed in order as follows.

1. Specify the variable used in this user-defined function
2. Give the URL of the page a canonical tag except for fixed pages and posts
3. If the custom field has a value other than 2, it should have ahreflang of each language page and canonical tag of the main site.
4. If the custom field has no value in 3 (in this case there is no English page), give the URL of that page a canonical tag.
5. Output the result of 2 to 4 to wp_head (header) with add_action

Why isn’t that complicated code? That is a frank impression.

However, as shown in the factors in the previous section, the problem with PHP 8.0 is that it completely ignores (does not detect) anything that does not have a custom field itself.

The following code has been modified.

/**** Multi-language header output (main site) ****/
function hab_add_multi_lang_header_parent(){
//Front page, archive page
if(!is_singular() || is_front_page()){
	$ha_ima_url=(empty($_SERVER["HTTPS"]) ? "http://" : "https://") . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];	
	echo '<link rel="canonical" href="' .$ha_ima_url. '" />';	
}

//All posts and fixed pages except the front page on fixed pages
if(is_singular() && !is_front_page()){
	//変数の設定
	global $post;
	$ha_mlang_customfield = get_post_meta($post->ID, 'cf_en_url', true);
	$ha_ima_url=(empty($_SERVER["HTTPS"]) ? "http://" : "https://") . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
	
if(empty($ha_mlang_customfield)){
//If there is no input in cf_japanese_url
	echo '<link rel="canonical" href="' .$ha_ima_url. '" />';	
}else{

//If there is input in cf_en_url
		echo '<link rel="alternate" href="' .$ha_mlang_customfield. '" hreflang="en" />';
		echo '<link rel="alternate" href="' .$ha_ima_url. '" hreflang="ja" />';
		echo '<link rel="canonical" href="' .$ha_ima_url. '" />';	
}
	}
}

add_action('wp_head', 'hab_add_multi_lang_header_parent',1);

The difference from the unmodified code is that the presence or absence of custom fields is basically processed separately as shown below.

1. Completely separate by whether it is a fixed page and a post
2. For the top page and archive page, process by specifying the necessary variables other than the custom field
3. For fixed pages and posts, process according to the presence or absence of custom field values

The code above and below will give the same result, although the method of determining and processing the value of the custom field (whether it is empty) is different.

Now, pages that don’t have custom fields (front pages and archives) will no longer be warned because they won’t let you do something that doesn’t have custom fields.

Of course, I also checked the page source to see if it was processed properly.

Since the warning and caution logs do not mean that they do not work in particular, there is a temptation to avoid it by writing something that does not output an error at the beginning of the file, such as “It’s annoying …”, and with WordPress. If there is, if you set debug to false in wp-config.php, nothing will be displayed, so it tends to be a teacher as it is, but if you take such measures, it may suddenly be deprecated from a certain version. I’m just putting off the problem, so I think it’s important to deal with it properly.

Later: After dealing with this warning, once I deleted error_log, I started getting warnings related to plugins that I hadn’t seen before. Somehow there is a feeling of small amount, and I think “Isn’t all the logs spit out?”, But I will deal with what comes out for the time being.

There are other warnings, so I’ll keep a memorandum each time, so stay tuned for a later article! !!