Posted: February 7, 2021 at 7:22 am
I read your similar topic from October 28th, 2020 and created a custom plugin for debugging and added code to my wp-config.php file. I reset permalinks and came up with an updated debug log. Once I have the issue happening again, I’ll cut and paste the debug for your help in deciphering where the issues may lie?
This losing permalinks is a recent development (last 2 weeks). I’ve deactivated a few plugins like cache and autoptimize, but still happening. It’s only happening with event links.
Have you installed any new plugins in the last 2 weeks or made any changes, switched themes etc?
The logging function you’ve added helps use see what request called for permalinks to be flushed which should help narrow this down so yes, please do post the log entry from when this happens (note you can mark your reply private so only EE staff can view it).
The debug.log file is publicly accessible so I can already view that, however, it doesn’t show any issues with permalinks.
Theres a simple check within the snippet that you are using to confirm ‘events’ are set in the permalinks, which is shown at the end:
Means the function found
You’d be looking for:
Or something else weird within the rewrite rules (I can’t see any in the debug log currently).
Does it happen at a specific time?
You could install the WP Crontrol plugin:
Then check the Cron schedule that it adds in the Tools section of your site’s WP Dashboard. There may be a cron event that runs every 24 hours around the time rewrite rules get flushed. That would be a good clue to find.
Just to clarify, WP Crontrol won’t ‘fix’ anything here but it will list any WP CRON jobs that are running daily on your site. If any of those are scheduled to run around the time this keeps happening its a good place to start looking.
No, but I think it’s unlikely to be causing this.
Back up the
The first 4 lines are comments and likely not used, but LiteSpeed Cache is adding them so might as well leave them in.
I did find a similar thread on this for LiteSpeed cache here:
Although the user reporting the problem didn’t reply with details on a cause (if they found it). Try disabling LiteSpeed Cache and see if it continue to happen.
Just to note, this isn’t an EE specific issue, something is breaking permalinks but without some kind of error or log entry pointing to what that is we can only guess to the cause.
Yeah, that’s really strange.
I agree that making the above change should not be bringing down the site, both blocks are identical so removing the dupe should not going, well, anything!
We do try not to run Event Espresso on login requests, so if this is still happening, you could try adding this snippet to the site:
Then wait it out again to see if it happens on the next day.
Looking over your logs, I can see the log entry’s for when (what I assume) is you going into the permalinks options and saving, but there isn’t another log entry between those. Which could mean that a function is alterin permalinks without calling rewrite_rules(). Wouldn’t expect that under normal use though.
That error doesn’t help but does mean there are likely jobs running server-side, outside of your WP install.
Have you checked with your host on what this may be? Check if they have any tasks running around the time it happens.
If you had the code in place before it happened, then no, it didn’t. The code tells Event Espresso to run on login requests to make sure that if the rewrite rules are flushed on that request EE still adds it’s rules in.
If that was in place and it still failed the issue is not from the login request.
Thats ‘normal’ and means that EE’s rewrite rules have been added into WP’s rewrite rules as expected, if this:
was missing, it would show the problem.
That log entry looks like its from you saving the permalinks in settings, it shows what the rewrite should look like.
Delete that debug.log file, it doesn’t have anything usefl as far as I can tell and is basically full of warnings/notices thrown by the theme, 99% of it isn’t related so no need to keep it. Leave the code in place for now and a new one will be created shortly after (likely on the next request as your theme will throw a notice again).
So the above isn’t really helping, the log entries show that:
1. There isn’t a call to flush permalinks at a specific time which then doesn’t include the EE rewrite rules. (Note that doesn’t mean somthing isn’t altering those rules, just that it isn’t being down via
2. When your permalinks are correctly updated when using the Permalinks options page.
What I would do next, is log the rewrite rule option again only this time do it when the EE event page is returning 404 to confirm that it is indeed the write rule causing this (I can’t see if being anything else, but the whole thing is weird anyway so lets check it).
You’re using my snippet with the log function, which I assume is the one using
Add this in the same location you added the other code:
That hooks into wp_footer, checks for a 404 and then if the URI contains ‘event’ is logs the rewrite rules. At least we can then see what the rewrite rules on the actual request throwing this.
One thing you could try is clone the site onto a test server. Then check to see if the rewrite rules get squashed on the other server, with all the same plugins activated, same theme.
Testing this on a clone of the site is a good idea.
I’ve been looking over the log entries created on your site and the missing rewrite rules are not just from Event Espresso, so by this:
May I ask what else you are testing when EE events show 404?
When this is happening, the default WP rewrite rules are in place plus product-category, product-tag and product (your site has many more that should be in place). It’s definitely a rewrite_rules issue and the fact that the above rules are added would suggest something with how Woo is flushing permalink so maybe start by first confirming the issue shows on the clone site, then see if de-activating Woo prevents it from happening.
One option you have right now (although I consider it a stop gap rather than a fix) is to add
It’s not really a ‘fix’ as something is still breaking the permalinks but it should at least prevent the need to manually flush the permalinks every 24 hours whilst you investigate this further on the clone site.
The problem with redesigning the site etc is right now you don’t know the cause. So what happens if (the worst-case scenario here) you redesign the site, upload it and exactly the same thing happens?
I know creating a clone isn’t fun but you’ll benefit from the time doing so now later on. At the very least it lets you experiment without disrupting the live site.
Your call at the end of the day but I highly recommend find the cause before moving forward.