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
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:
test Choose test Choose test FROM test Choose test FROM publish_meta Remove DROP DROP test
The next offered me a 404:
Choose * FROM test Choose * FROM publish_meta Remove FROM Remove FROM test Remove FROM publish_meta DROP TABLE DROP TABLE test
MORE EDITS -
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
FINAL EDITS -
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
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.
PROBLEM FINALLY DISCOVERED -
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.