Fatal PHP Error

Hi Tara (@taraclaeys),

Thank you for getting in touch, we do appreciate your time. Our apologies for the trouble you are experiencing.

The error you mentioned is not a widespread issue, and instead is usually something we see if/when a marker is being accessed in the background incorrectly. This can happen for a few reasons, and it varies between installations when it does occur. In some cases, these kinds of reports can also be a result of a marker being deleted while it is being accessed by another user, for example.

One way that we can debug this a bit further is by taking a closer look at the full error log for this issue, these are usually available from your host or hosting control panel, by looking for (or requesting) your PHP error logs. These logs will contain more insight into the error, along with a history of events that took place, leading up to the error.

Could I ask that you request/download these on your side and send them over to us by opening a support ticket on our website? This will allow me to help you get this resolved as soon as possible.

I look forward to hearing back from you.

Same for me also;

PHP Fatal error: Uncaught Exception: WPGMZA\Marker ID ‘6’ not found in /www/*/public/wp-content/plugins/wp-google-maps/includes/class.crud.php:414

Hi @dennycy,

I am sorry to hear you are also having trouble. As mentioned in my last reply, this usually only happens when an unexpected read of a marker occurs (sometimes due to background processes), where the marker no longer exists.

Unfortunately, we cannot confirm this without the additional PHP error log stack, usually included in a more comprehensive error log file which should be accessible via your hosting control panel.

If you could send that over to us on our website, we can take a closer look and assist in finding the reason for the exception being reported.

Same issue here also on three separate websites.

Hi @johnwpc,

Unfortunately, we cannot provide any additional insight until we receive PHP error logs from affected sites. We do need to take a look at the call stack, which showcases a series of events that took place prior to the exception being thrown.

To clarify, this is a failsafe built into the plugin which will prevent missing markers from being loaded onto a map. In other words, if a marker is deleted and it then accessed, the exception prevents it from being loaded.

I’m also facing the same issue:

Please check the log:

2024/02/28 07:13:18 [error] 75941#75941: *123993 FastCGI sent in stderr: “PHP message: PHP Fatal error: Uncaught Exception: WPGMZA\ProMarker ID ’10’ not found in /www/se_664/public/wp-content/plugins/wp-google-maps/includes/class.crud.php:414
Stack trace: 0 /www/se_664/public/wp-content/plugins/wp-google-maps/includes/class.crud.php(85): WPGMZA\Crud->read(‘single-read’) 1 /www/se_664/public/wp-content/plugins/wp-google-maps/includes/class.marker.php(29): WPGMZA\Crud->__construct(‘wpha_wpgmza’, ’10’, ‘single-read’) 2 /www/se_664/public/wp-content/plugins/wp-google-maps-pro/includes/class.pro-marker.php(28): WPGMZA\Marker->__construct(’10’, ‘single-read’) 3 /www/se_664/public/wp-content/plugins/wp-google-maps-pro/includes/class.pro-marker.php(464): WPGMZA\ProMarker->__construct(’10’, ‘single-read’, false) 4 /www/se_664/public/wp-includes/class-wp-hook.php(324): WPGMZA{closure}(’10’, ‘single-read’, false) 5 /www/se_664/public/w” while reading response header from upstream, client: 94.102.51.144, server: https://www.sustainableengineering.co.nz, request: “GET /wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/10 HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php8.0-fpm-sustainableengineering.sock:”, host: “www.sustainableengineering.co.nz:17270”, referrer: “https://sustainableengineering.biz/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/10”

Hi @ravimakwana,

Thank you for sharing your logs and issue with us.

Taking a look at your error log, we can see a public request to your WordPress REST API at the following path:

wp-json/wpgmzA/v1/markers?__method=get&random=/wpgmza/v1/markers/10

This request path is not a standard request, meaning our plugin is not calling this internally. This is what leads us to believe that a 3rd party is attempting to access your REST API.

Coincidentally, they have targeted marker ID 10 which fails, and the error is thrown because the marker does not exist. It’s not clear what that 3rd party is attempting to do. They may be testing for a weakness in the website, or they may be attempting to scrape the marker data.

The plugin should not fail in this circumstance, but it’s worth mentioning that this is isolated to a single request, and it does not originate from our plugin.

With that said, I’ve logged the failure, along with your log and we’ll release an update to handle this more gracefully. We expect an update for this edge-case to be released early next week.

We are seeing similar spurious traffic on our website. I believe these are attackers looking to exploit the vulnerability detailed here:

https://wpscan.com/vulnerability/f5687d0e-98ca-4449-98d6-7170c97c8f54/

If you’re on the latest version of WP Go Maps (9.0.32) then you should be safe, but you’ll still get PHP fatal errors until the plugin handles this scenario more gracefully.

Hey @reubenpearse,

Yes, we believe you are correct in saying that this is a pen-test based on that report. The plugin is safe from the root issue, but the REST API endpoint is not dealing with the missing marker ID’s correctly.

We’ve already prepared an internal build which solves this and makes handling more graceful. That build is going into testing today with our team and we expect it will be released early next week.

Hi everyone,

I’d like to give you all an update on the status of this issue. We finalized a release which should solve this issue along with various other issues within our systems.

That version moved to testing late last week and the tests have passed. We are finalizing a few last changes, and we expect to release an update within the next day or two, pending the final changes mentioned.

I will update this thread as soon as the update has been released. Thank you very much for your patience and understanding.

Hi everyone,

Just a quick update to let you all know that we have just released an update (9.0.33) which will handle these REST API errors more gracefully, which should prevent those errors from being thrown.

I will be marking this as resolved, but if you do still have trouble please do reach out to us on our website, or in a new thread and I’d be happy to assist!