So I have been attempting to make several changes to some custom WordPress theme which introduces a whole overhaul from the Dashboard. I keep finding little difficulties with the initial theme that I have to fix (not correctly checking for duplicate posts whenever you import brand new ones, publish metadata not receiving saved properly, posts not receiving sorted to their proper groups, etc.)

As I have been dealing with this I have needed to check out and customize the database numerous occasions either to see exactly what the theme does towards the database or fix things it messed up. Regrettably I had been not able to set up phpMyAdmin so I have been making changes by directly typing SQL and placing it in to the theme in appropriate places, then getting the script die() in order to begin to see the creation of my SQL.

All of a sudden it struck me which i may find a wordpress plugin which combines phpMyAdmin functionality into WordPress. And So I installed wordpress-phpMyAdmin.

Everything appears to become running smoothly until I attempt to really DO anything. I'm able to see the tables, see the rows, and check out everything. However when I attempt to edit a row or remove a row I recieve rerouted to some 404 error, stating that whichever a part of phpMyAdmin I been being able to access (for instance, tbl_row_action.php) does not exist. Basically go straight to these pages without posting the shape to edit or remove a row they work all right and that i recieve an error message that my SQL query was blank.

Has other people experienced this? I truly can't determine precisely why or where it's delivering a 404. It's absolutely absurd.

EDIT - Just a little more information:

I have found that I only obtain a 404 error when phpMyAdmin calls sql.php using the sql_query parameter set

EDIT (again) Body further update:

I only obtain the 404 error when sql_query consists of a legitimate query. Searching through sql.php (I've not spent A lot of time searching, actually) I actually do observe that it appears to parse the query and see if you are Chooseing, DROPing, Removeing, etc. to allow them to look at your user permissions. It might be associated with this parsing code.

The next queries didn't produce a 404:


Choose test

Choose test FROM test

Choose test FROM publish_meta



DROP test

The next offered me a 404:

Choose * FROM test

Choose * FROM publish_meta

Remove FROM

Remove FROM test

Remove FROM publish_meta




So towards the top of sql.php I placed this type of code:


It does not die after i result in the bad queries in the above list. It is going right to the 404 message. Clearly this really is something related to WordPress's redirect script and never with phpMyAdmin


I have done much more research and been grep'ing the heck from WordPress.

I highly suspect that i'm getting this problem because of newer and more effective WordPress security feature. Older versions of WordPress apparently accustomed to allow SQL to become input into URL's, which posed an enormous security risk. Consequently it's obvious they wouldn't allow SQL to become passed through URL's now. Right before web site the need for is_404() has been set to true. It's being set within Wordpress::parse_request() (that is known as by Wordpress::primary() that is known as by wordpress() that is known as within wordpress-blog-header.php)

Whenever there's a suspected SQL query ANYWHERE within the asked for URI, I recieve started to some 404 page. I must change this behavior while making as couple of modifications to WordPress core as you possibly can. I want somebody that is actually good with WordPress that helped me to here. I presume a solution is available including the $wordpress_rewrite variable, which consists of numerous URL rewrite rules.


For anybody interested who finds this publish or was following it or just had similar issues, I finally situated the origin from the 404 errors. It did not lie with WordPress whatsoever. The issue fell to mod_security, an Apache module which prevents any demands that appear to be suspicious (including individuals with SQL within the request URI)

Remember to create your mod_security configurations correctly.