What plugin are you using for the custom 404 page? or if not a plugin, how is the custom 404 page done?
No plugin is being used for the custom 404.php (I’m a theme developer FYI), the 404.php template is automatically displayed by WordPress when a page isn’t found as per WordPress’s template hierarchy.
The custom 404.php only contains the header and footer includes with a short “Page not found, sorry about that” bit sandwiched in the middle.
ah, when you said custom 404 page my mind went in a different direction than just the standard 404.php template file.
we’ve already determined that /wp-admin/admin.php is never loaded because we tried putting code at the top of that file.
we know that the file exists, or at least it should exist. The only reason that the .htaccess file should be redirecting is if the file does not exist. This line in the .htaccess file checks
RewriteCond %{REQUEST_FILENAME} !-f
If the file exits then the rewrite is not done.
I’m not sure how to troubleshoot past this point. I might suggest some things.
In your 404 page output the content of $_SERVER.
‘echo ‘
'; print_r($_SERVER); echo '
‘;
See if you can figure out exactly what the server thinks the requested file is. Do the same with $_POST and $_ENV.
To be honest, I don’t know what to tell you to look for. I’m just shooting in the dark. I would do these things and study the output and hopefully I’d see something that made it all make some kind of sense without really knowing exactly what I was looking for.
Totally understandable re: shooting in the dark.
Will try your troubleshooting suggestions soon as I can scrape together some time. Might even setup a fresh test environment for this to see if I can replicate on a different server.
I was doing some research into something else an came across a post about updating a post in WP causing the same issue. That person traced the problem to mod_security, you can read about it here https://www.mkyong.com/blog/wordpress-display-404-after-updated-post/. If you have mod_security on your server and you are able to, try disabling it and see if that clears up the problem.
cool, i will check it. Thanks John 🙂
Interesting find, thanks for sharing John 🙂
I just wanted to +1 on this. I found this thread because I was experiencing this same issue with ACF Pro 5.5.7. Everything worked fine on my MediaTemple VPS and in my entire teams’ local development environment. When the site was moved to the client’s host of choice (not GoDaddy), the options page wouldn’t update and would redirect to a 404. I removed the https:// from the link fields and hard-coded it into the PHP file and everything worked fine.
In my case, I’ve been able to fix this issue by checking the chrome console.
I’ve found that one of my options was used to save javascript code (adwords, olark, etc) and while this was working fine on localhost, at the staging server it was producing an error:
The XSS Auditor refused to execute a script in xxxxxxxxxxx/wp-admin/admin.php?page=XXX-theme-settings because its source code was found within the request. The auditor was enabled as the server did not send an 'X-XSS-Protection' header.
Si I’ve removed any javascript contents and started working again.
I’m wondering if there is some kind of workaround for this?
Been reviewing some older posts about problems like this.
First step is to turn on debugging and make sure there are no PHP errors when submitting the page, better yet, make sure there are no php errors. Any site that is live should run without generating errors and warnings. If you have other plugins or your theme is generating errors or warnings then these should be reported to the authors. https://support.advancedcustomfields.com/forums/topic/cant-save-post-if-i-add-a-url-to-a-texturl-field/
Next step https://www.georgebuckingham.com/blog/wordpress-404-error-with-advanced-custom-fields/
Checking console errors suggested by @alfonsoc is also a very good idea.
If all else fails then disable all other plugins and see if you can get it to go away that way.
There are a lot of topics here about this, but I have never seen the issue. So it’s very hard to debug. If you have a site that’s free of errors and this problem persists on a WP site on the same server with noting but WP, ACF and one of the default 20XX themes installed then the best hope you have is to submit a support ticket https://support.advancedcustomfields.com/new-ticket/
This just started happening to a site i’m working on. Seems to be an issue with a bunch of URL input fields which I’m using to house the client’s list of social media URLs.
I can’t imagine that “twitter” and “linkedin” are reserved WP variable names.
I just moved them to another Theme Option section so I could edit the other values. WACKY.
The work-around I’ve found is to temporarily disable ModSecurity (cPanel), then edit and save the site option field. Then, turn ModSecurity back on when finished.
My webhost is LiquidWeb.
Had this exact same problem, and the solution ended up being to modify two rules in our ModSecurity settings.
We’re with liquidweb, and they are the ones who figured this out. Thanks to @raygulick for steering us in the right direction!
I don’t know ModSecurity at all, so I don’t know if the rule ID’s are a standardized thing, or if they are unique to each server setup, but for us, the two rules were:
340464, and 340465
The “Justification” for both of these rules were identical:
Match of "rx ://%{SERVER_NAME}/" against "ARGS:acf[field_52881450ecaab]" required.
I don’t know how to bring this to attention of the ACF developers, but possibly the way they pass the arguments for the Options page could be changed to a more secure method?
It’s interesting to note that the description of the RuleID is:
Atomicorp.com UNSUPPORTED DELAYED Rules: Remote File Injection attempt in ARGS (admin.php)
So, clearly ModSecurity is viewing the way that the Options Page saves URL values as an injection attempt. So, I don’t really want to disable these rules if it is making us vulnerable to a file injection of some sort
It would be better if ACF could change the way the values are saved. If we use a regular page to save some URL fields, then we don’t run into this problem – only if we use the Options Page. So, clearly it’s possible to save URL values in ACF fields without triggering this injection attempt rule (as is evidenced by a standard page with custom ACF fields being able to save URL values without issue).
It’s 2023 and I now have this issue (again) on a different site.
I have been battling this problem as well and thought I’d add some info. One of my options page fields is a 'type' => 'wysiwyg' field. If the user adds any html field that generates quotes in the markup I get the 404. As long as the markup does not contain quotes it submits fine.
For example, centering text generates <p style="text-align: center;"> which blows out the page, but <h2> is just fine.
I don’t have a solution (yet) other than changing the field type.
