Support

Home Forums Event Espresso Premium Irregular 404 errors – still a problem

Irregular 404 errors – still a problem

Posted: March 15, 2020 at 1:26 pm


Joost

March 15, 2020 at 1:26 pm

For half a year we are struggling with 404 errors on EE event pages. The previous (now closed) top is: https://eventespresso.com/topic/irregular-404-errors-continued/

We observed the site for some time now and checked the real-time PHP memory usage many times, during daily operations. Some typical values we’ve seen are as follows:
– when events start throwing 404 errors, just before deactivating EE plugin: 64.85 MB
– after deactivating the EE plugin: 53.76 MB
– after activating the EE-plugin: 64.39 MB
– after activating the EE promotions and wait lists plugins (both remain disabled after reactivating the EE core plugin): exactly back on 64.85 MB and then the problem is gone until the next day.

So, our conclusion would be that the PHP memory limit is not a factor in relation to our problem after all.

But we still have the problem that after about a day and a half all event pages start throwing that 404 again. This seems unrelated to the number of visitors on our site (ranging from a daily 125 to 400).

We made it now our daily routine to deactivate and reactivate the EE core plugin every morning as a work-around to the problem. But of course this is not a sustainable solution. Do you have any further suggestions how we could proceed to solve the problem?


Tony

  • Support Staff

March 16, 2020 at 7:21 am

Hi Joost,

In short, we can’t reproduce this so it’s rather difficult to troubleshoot. We’ve tried multiple times with various setups and permalinks remain working just as they should whenever we run tests on this.

So, our conclusion would be that the PHP memory limit is not a factor in relation to our problem after all.

To be honest, I’m not sure how you’ve come to that conclusion just from the above.

In your previous thread I posted this:

Now having said all that, I’ve been looking at your site at various times and at the time of writing your site has been sitting at a real-time memory usage of 2GB (77% of your total, spiking up to about 85%) and it hasn’t dropped in some time. This leads me to believe the problems does indeed lie with memory. Something on your server is consuming all of the available memory and continues to do so, bumping the memory available helps, until again it is all consumed.

Did you investigate why the memory usage was spiking/climbing?

De-activating EE and re-activating EE (and its add-ons) is all well and good, but if memory is spiking and the request to rebuild/flush permalinks can’t process it would cause issues like this with said permalinks.

From the above, you’ve checked the memory usage after the issue has occurred, de-activated and noted the usage, then re-activated and noted usage, but none of that seems to be when the issue is actually occurring, correct?

Do the permalinks stop functioning at a specific time in the day?

If so do you have any daily scheduled tasks running on the server which would run roughly around the same time the issue occurs?

—-

What may help is to add a snippet to the site that writes a log entry saving the date & time, all of the rewrite rules and a call stack to a file. It isn’t going to fix anything but should give an idea of what is calling to flush the rewrite_rules and when/if they are missing from the site.

There are a few steps you’ll need to take to set that up if you’d like to try it?

You’d basically need a function to write to a log file that you leave active on the site until the permalink issue happens again (hopefully within 24hours from the sounds of it) then send that over to me to have a look over. Note that file may end up huge pretty quickly depending on the notices/warnings and other errors are thrown.

(Again we are guessing as to what the cause is as we can’t reproduce on multiple different setups, so just to be clear, this may well end up being a wild goose chase but I think its worth a shot)


Joost

March 17, 2020 at 3:58 am

This reply has been marked as private.


Tony

  • Support Staff

March 17, 2020 at 4:38 am

This reply has been marked as private.


Tony

  • Support Staff

March 17, 2020 at 1:25 pm

Hi Paul/Joost,

Just checking in to confirm you received the above?


Joost

March 17, 2020 at 1:44 pm

Hi Tony,

I just installed the plugin and updated the wp-config.php.

Regards,
Paul


Tony

  • Support Staff

March 17, 2020 at 2:57 pm

Ok, before we even get into EE’s lost permalinks you have a bigger issue to fix first as it’s very likely connected.

Every request on your site is flushing permalinks, even some front end requests which is crazy as flushing permalinks is expensive and should only be done when needed (new rules need adding, plugins activate/de-activate etc).

Also, each of those requests is saving different rewrite_rules, which is likely a hint towards the problem you have with EE’s permalinks.

I’m assuming you have a local copy of the site?

If so, open up the entire wp-content directory in a decent text editor (Sublime Text for example, or an IDE such as PHPSotrm if you have it) and search for flush_rewrite_rules, start working through what is calling that and on which hooks it’s calling it on. Anything calling that function on init is using it incorrectly.

Find out what is calling that function on every request, if it’s a plugin check for updates and if there are none, find another plugin. If it’s a theme… check for updates, if it’s your own theme, remove that code and use it correctly:

https://codex.wordpress.org/Function_Reference/flush_rewrite_rules

Your site should not be flushing permalinks anywhere near as often as it is and the fact that you are getting different rewrite_rules on those requests means something is running the above incorrectly.


Joost

March 18, 2020 at 12:13 am

Thanks, Tony. I’ll do as you suggested and let you know the results.

Regards, Paul


Joost

March 18, 2020 at 2:31 am

Hi Tony,

I did as you told me. I see the flush_rewrite_rules function in several plugin PHP files. But it’s not clear to me from the code if it’s actually being called during PHP execution, as the conditions in the program flow are not clear to me.

I could try to disable those plugins one by one and look for any change in the logfile. Could you tell me what change to look for exactly in the logfile?

Or I could send you the PHP files that contain the flush_rewrite_rules function. Would that be sufficient for you to see what’s going on?

Please advice.

Best regards, Paul


Tony

  • Support Staff

March 18, 2020 at 2:57 am

I could try to disable those plugins one by one and look for any change in the logfile. Could you tell me what change to look for exactly in the logfile?

Sure, I’ll reply in a private thread with specifics for your site after this one but you would disable the plugin then view the log file and note the ‘last’ entry containing the rewrite_rules wait a few seconds without visiting the WP Settings page in the admin (load a front end page of the site a couple of times) and just refresh the log file, if new rewrite_rule entries were made in that time, it’s not that plugin.

Repeat until it stops adding rewrite_rule logs on each request and you’ve found the plugin.

(See next reply for specifics relating to your site)

Or I could send you the PHP files that contain the flush_rewrite_rules function. Would that be sufficient for you to see what’s going on?

Whilst we can do that, code review isn’t covered under support so it would require support tokens to cover the time spent doing so.


Tony

  • Support Staff

March 18, 2020 at 3:04 am

This reply has been marked as private.


Joost

March 19, 2020 at 7:38 am

This reply has been marked as private.


Josh

  • Support Staff

March 19, 2020 at 9:03 am

Hi Paul,

That’s a really interesting find. I downloaded a copy of Really Simple SSL and checked its code. The code that triggers a rewrite rules flush would normally prevent anything like this. It’s supposed to only flush rewrite rules once about 1 minute after plugin activation, and once after activating SSL. So unless the plugin or SSL setting is getting deactivated/reactivated a lot, the rewrite rule flushes shouldn’t be happening.

One thing you could do is add the following to your site’s wp-config.php file:

define('RSSSL_NO_FLUSH', true);

What that will do is tell Really Simple SSL to not update the option rsssl_flush_rewrite_rules, which that’s the option that’s later checked to see if rewrite rules need flushing.

Do you happen to also have any of the 3 following plugins activated on the site?
W3 Total Cache
WP Fastest Cache
Zen Cache


Joost

March 20, 2020 at 8:49 am

This reply has been marked as private.


Josh

  • Support Staff

March 20, 2020 at 8:55 am

Hi Paul,

I can advise to contact WooCommerce support, they should have some troubleshooting steps for this because normally WooCommerce only flushes rewrite rules when needed.


Joost

March 20, 2020 at 8:57 am

Thanks. I’ll do that and let you know the result.


Joost

March 27, 2020 at 4:54 am

This reply has been marked as private.


Tony

  • Support Staff

March 27, 2020 at 6:29 am

When you say it’s blank, do you mean it’s a whitescreen or no products? (meaning you can see some/all of the theme output but not the products themselves)

If it’s a whitescreen it likely means the function is running over and over again then running out of memory.

Load shop, then check your servers error logs, any errors?


Joost

March 27, 2020 at 6:49 am

The page is there, only the WooCommerce generated output is completely missing.

If I enable the rewrite_rules log plugin, it’s still there, but as soon as I also enable the logging, the products list in the shop page is gone. The product pages are still there. With enable logging I mean:

define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
        @ini_set( 'display_errors', 0 );
         define( 'WP_DEBUG_LOG', true );
         define( 'WP_DEBUG_DISPLAY', false );
}

in the wp-config.php.
No errors in the server log.


Tony

  • Support Staff

March 27, 2020 at 8:36 am

Hmm, strange.

The write_log() function at the beginning of my plugin writes to the error log but only when WP_DEBUG is enabled so the difference between the above just when you set:

define( 'WP_DEBUG', true );

Or

define( 'WP_DEBUG', false );

Correct?

I have the latest version of Woo and my plugin enabled on a test site, loading the shop works fine for me with it enabled…. but, I also know that my site isn’t constantly flushing permalinks so that function should basically be doing nothing there anyway.

So, a couple of things to try on your site.

Comment out/Delete THIS LINE and THIS LINE.

Its possible something is catching the exception (shouldn’t be but not much else I can think of).

Rename ‘write_log’ to something else throughout that plugin, for example I would use tw_ee_write_log just to be 100% sure nothing else is declaring a write_log function before mine that does something different.


Joost

March 29, 2020 at 9:19 am

Renaming write_log() to tw_ee_write_log() solved the problem of the missing WooCommerce shop page output. I will now report back to WooCommerce that enabling the plugin still causes a lot of permalink flushes with their updated plugin.

You must be logged in to reply to this support post. Sign In or Register for an Account

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3

Documentation for Event Espresso 4

Status: publish

Updated by  Joost 20 hours, 1 minute ago ago

Topic Tags

Tagged: 

Notifications

This topic is: not resolved
Do NOT follow this link or you will be banned from the site!