farnely

The entries in my robots file relating to Google have remained (rightly or wrongly) unchanged for years but now, since WP 6.8 was released in April, Google has got the idea that (taking the first item in the list) the URL https://my-site/wp-*.php exists when it doesn’t, hence the 404s. The only place wp-*.php appears is in the speculation rules script that loads since WP 6.8.

Excluding those paths in robots would be a request to not crawl any of those locations. In other words, “don’t crawl my site”.

Yes it’s 157.15.90.216. According to https://www.iplocation.net/ip-lookup, it’s in India.

I use a third party plugin for custom posts and fields so I don’t know what hook is used.

I’m of the opinion, however, that the custom post type must be registered by the time the template_redirect hook runs because if I change the post status to publish, a 404 is not returned and the content template loads. I think that when the post status is private, the post is considered non-existent for a logged out user and logically you can’t fetch the post type for a non-existent post.

Working with private posts in wordpress is cumbersome!

@quantum-leap
This isn’t the first time the developer/s have released a version containing basic coding errors and I doubt it will be the last. I got fed up of waiting for them to acknowledge the issue when I reported it let alone put it right and have now removed the plugin from my site. But thanks to you for sharing the solution.

So, I’ve checked the content of the options field and mine looks like this:-

a:1:{s:12:"_multiwidget";i:1;}

I’m not displaying mine as a widget, I’ve just put the shortcode in the editor in WP Admin.

It occurred to me that there might be an incomplete div tag somewhere so I had a look at your PHP files. One thing struck me: on most of them your HTML is preceded by a closing PHP tag and then you PHP echo values within your HTML. For example, like this:-

<label for="text_color"><?php _e( 'Text Color', 'weather-atlas' ); ?></label>

In the file weather-atlas.php, however, you echo your HTML within your PHP. For example, like this:-


echo "<div class='weather_demo_wrapper'>";
echo do_shortcode( '[shortcode-weather-atlas selected_widget_id=' . $widget_id . ']' );
echo "</div>";


Personally, I like a consistent approach but it’s not my plugin and it shouldn’t affect the output. What is probably more of a problem though is that the opening PHP tag on Line 49 is incomplete; it reads <? instead of <?php.

Might I suggest you scrutinise your code thoroughly in case there are other instances of incomplete PHP tags and you might find a “<” or “>” is missing somewhere too.

This piece of code which appears in at least 3 of the plugin’s files (eg: line 52 in weather-atlas/admin/weather-atlas.php) doesn’t use a WP wordpress function:-
$widget_options = $wpdb->get_results( "SELECT * FROM {$wpdb->options} WHERE option_name LIKE 'weather_atlas_widget_%'" );