Intermittent 404s

404’s should only happen when a rewrite doesn’t work or an Airtable API request returns nothing.

It’s possible it’s an issue with WordPress clearing saved URL rewrites or with Airpress not getting expected data—possibly due to some issue with transients during upgrades or simply an issue with Airtable’s API. I’ll see about adding some deeper logging capabilities for potential issues with API requests (any non 2** responses) and we’ll go from there.

Can you share with me the two Virtual Post “URL Pattern to Match” fields?

Also, I’ve found this plugin very useful during the development of Airpress. Perhaps it will reveal something going on behind the scenes during updates or ???.

https://www.ads-software.com/plugins/rewrite-rules-inspector/

Digging a little more today and here’s all the non-2xx responses I’ve received over the last few months on one of my Airpress sites—note: 404 won’t show up as it simply means (typically) that Airtable returned ZERO results SUCCESSFULLY. So it’s not logged as an error.

WP_Error Object cURL error 28: Operation timed out after 30001 milliseconds with 0 out of -1 bytes received
WP_Error Object cURL error 28: Operation timed out after 10008 milliseconds with 0 out of 0 bytes received

[code] => 502
[message] => Bad Gateway
[body] => {"code": "temporarily_unavailable"}
[raw] => HTTP/1.1 502 Bad Gateway

[code] => 503
[message] => Service Unavailable
[body] =>
[raw] => HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

[code] => 503
[message] => Service Unavailable
[body] => {"code": "temporarily_unavailable"}
[raw] => HTTP/1.1 503 Service Temporarily Unavailable

[code] => 504
[message] => Gateway Timeout
[body] =>
[raw] => HTTP/1.1 504 GATEWAY_TIMEOUT

I’m pretty sure all three VPs are using the regex you suggested a while back.

Yep:
^wardrobe/garment/([^/]+)/?$
^wardrobe/outfit/([^/]+)/?$
^wardrobe/item/([^/]+)/?$

Thanks for the pointer to the plugin; I’ve been driving myself mad writing comment statement after comment statement. I had been wondering if you or anyone else made use of IDEs and, if so, which one, but this might be everything I need.

So after the latest Divi update, a few minutes ago, all I get are 404s. None of the presumed valid URLs still work.

Essentially all my rewrite rules were missing, so now I suspect it’s a process of tracking down an offending or incompatible plug-in. I deactivated everything I’m not presently using and await the next Divi update….

Thanks!

I’ve updated my local test environment to the latest WordPress (4.8.1) and Divi (3.0.71) and I’m not having any problems.

If you’re open to doing a screenshare call or give me a dump of your site I can dig deeper.

Ah! Try making sure there is a valid field (or nothing) in the “Sort Results” field in the Virtual Posts configuration screen.

I added the “Sort” field and put a default value of “Your Airtable Field Here” in it—that broke my request because that’s NOT a valid field — ack!

Working on a fix to push, in the meantime, just make sure your “Sort Results” VirtualPost configuration field is empty or the name of a column in your Airtable table.

No, all three VPs have valid sort fields…

I’m in and out today, but I’ll text you when things settle down and we can figure out next steps. (I wish I could find a reliable trigger — or at least a way to make sure one of my deactivated plugins wasn’t the cause, as I don’t want you jumping through hoops needlessly.)

Ok, I’ve published v 1.1.42 which contains a fix for the default value in the sort field. There’s probably other issues with default fields, but that was a sneaky one.

I’m not closing this ticket until you’re done seeing 404s, so let me know!

Of course, since you pushed 1.1.42, Divi hasn’t released a double-aught update. No 404s, of course, but…

So Divi finally updated today… and the 404s returned.

Rewrite rules inspector shows all Airpress-related rewrite rules as missing. Using that plugin’s ‘flush rules’ button brings them back into existence, and Airpress starts working again. I realize this could easily be a conflict with another plug-in. Is there an easier way to test than, the next time a theme update is available, backing up my site, disabling a plugin, updating the theme — and, if that doesn’t catch the problem, restore, rinse, repeat?

V

Another Divi update — and more 404s. After the update, the rewrite rules inspector plugin showed all Airpress rewrite rules as missing. When I checked the Airpress Virtual Post definitions, though, they showed there were matching records for the test URLs. I noticed one VP didn’t show matches, so I changed the regex from (*.) to ([^/]+)/?$ and saved the VP. At that point, the rewrite plugin showed all rules present, and my Airpress-powered pages began appearing again. I assume the call to flush_rules() was responsible for the fix, but I’m not conversant enough with WordPress programming to understand why it’s not being called (or, if it is being called, what might be blocking it) on the return from maintenance mode.

Hope this helps…

Edit:
In looking through 1.1.42, I don’t see any calls to flush_rules outside of the *Admin modules. Should there be a flush call hooked to plugin activation or loading as well?

• This reply was modified 7 years, 6 months ago by mazoola.

Unsurprisingly, the same thing happened again following last night’s Divi update. If I get a chance to read up on plugin activation (all I know is ‘don’t tie flush_rules() to Init()‘), I may give it a shot.

• This reply was modified 7 years, 6 months ago by mazoola.

The Divi file Divi/core/components/init.php has this on line 12:

add_action( 'shutdown', array( $wp_rewrite, 'flush_rules' ) );

There are a few other calls to flush rules, but they’re based on theme settings/options (3_0_flush_rewrite_rules_2 and 2_5_flush_rewrite_rules) so you can check your options table to see if those are present, but I doubt they are.

Anyway, it would seem that Airpress simply isn’t registering the redirects after Divi performs the flush_rules function during the shutdown action. This is really strange to me as I’m registering the rules with the init hook—but only when in admin.

So is it possible that the Divi theme is updating NOT from the admin console? Do you use WP CLI (not that I’m sure that would count as NOT in the admin console).

I’ll do my best to try and carve out some time to track this down. I’ll probably take an older install of wordpress/divi and “snapshot” it so that I can run the update over and over again while attempting to stop at each step so I can see what has or hasn’t happened yet.

What should be happening (from what I understand) is that WordPress “init”s (at which point Airpress registers redirects), then Divi updates and flushes rules (at which point it should be writing the rules array from memory to the database. So again, if this isn’t working, Airpress’ rules somehow aren’t in the rules array in memory—which happens during INIT…. chasing my own tail here.

Wish I had an answer for you.

Chester –

No, that’s a great help. I was looking at this a couple of days ago until I began to go cross-eyed, but I’m almost ready to jump back in.

One thing I found that looked potentially useful was this — especially the section on flushing rewrite rules on activation.

At one point he describes the 4-step process that occurs whenever a plugin is activated — which I assume also occurs when Divi returns from upgrading itself.

1. The browser loads the plugins.php file.
2. plugins.php file includes admin.php file. As a result, all other plugins have been loaded, and the init hook has already been called. WordPress doesn’t even know our plugin is activated yet, so of course your register_post_type() function hasn’t been hooked into init. Consequently, your CPTs are not registered.
3. Then plugins.php calls activate_plugin()
4. Our plugin is included, and your activate() function is called. Rewrite rules are flushed, but because your CPTs are not registered, nothing really changed.

This chain of events might sound simple and straightforward to you, but it got me every single time I create a plugin. Every. Single. Time.

I don’t know if that parallels Airpress’s experience, but I thought it might be worth a look.

(FWIW, I’m upgrading from the console. This doesn’t seem to be a common problem with Divi, as the only post on Elegant Themes’ Divi board concerning 404s after upgrade is from 2014 and was caused by a WordPress bug involving child themes.)

I’ve had two teapot-sized tempests blow up in the last couple of hours that, irritatingly, have to be calmed. If I free myself from them quickly enough, maybe I’ll kick things around a bit more.

Thanks again!

• This reply was modified 7 years, 6 months ago by mazoola.