0

I have a Wordpress based site with an additional custom PHP application with files in it's own folders - "staff", "volunteers" etc. We have mod-rewrite in .htaccess file so we can use permalinks

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

I have a specific page in the "staff" folder, "form.php" that is giving me trouble - specifically, after Apache/PHP upgrade apostrophes in the POST variables seems to cause an issue - BUT instead of a PHP or SQL error I get Wordpress 404 page. How do I change that so I can start troubleshooting? I can not disable permalinks, the site is live.

RewriteEngine Off in .htaccess in "staff" folder does not do anything.

I am attaching two screenshots to show that the file indeed exists. The first image shows what happens if the form textarea variable had an apostrophe plus space, the second shows that an apostrophe by itself does not cause a problem.

Thank you!

UPDATE: I got it down to a specific combination of letters, spaces and apostrophe

always rembember to 'select' - gives a consistent 404 error always remember to 'salut' - does not

so I think it's reserved query words(?) in combination with apostrophe that is causing the issue and if I manage to keep Wordpress out of this folder, we would not be having any issues!

UPDATE 2: the issue turned out to be a general Apache error - issues with mod-sec. However, instead of generating 403 forbidden that would be easier to troubleshoot, 404 page complicated the troubleshooting process.

7
  • A good place to start troubleshooting is Apache's error (and access) log. In Linux, this is often located at /var/log/apache2/error.log or /usr/local/apache/logs/error_log. Most hosting providers will provide a means to access the error log through a web-interface.
    – bosco
    Commented Feb 12, 2016 at 4:05
  • Just for clarification, when you say "the form textarea variable had an apostrophe plus space", does that mean that the value submitted from a textarea input contains an apostrophe and space? And is the form submitted with a traditional Submit button, or via Javascript somehow?
    – bosco
    Commented Feb 12, 2016 at 4:08
  • yes, the value submitted from textarea contains an apostrophe and space after apostrophe. The form is submitted via Submit button.
    – Natalia
    Commented Feb 12, 2016 at 11:37
  • have you tested the GET form method to see if the error persists?
    – majick
    Commented Feb 12, 2016 at 14:04
  • yes, I have and yes, the error is still there with GET
    – Natalia
    Commented Feb 12, 2016 at 20:20

2 Answers 2

2

You can add a RewriteRule to your .htaccess to instruct mod_rewrite to stop processing any URI that begins with Staff/ or resolves to Staff:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteRule ^/?Staff(/|$) - [END,NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

In effect, this should be the same as a RewriteEngine Off directive in a .htaccess file in /Staff.

Breaking down the new rule: RewriteRule ^/?Staff(/|$) - [END,NC]

  • ^/?Staff(/|$): The first argument of a RewriteRule is a REGEX pattern to check against the path portion of requested URIs, in this case Staff/Schedule/Schedu-Mod_Results_test.php
    • ^ matches the very beginning of the URI path
    • /? matches whether or not a leading forward-slash is present (this is only necessary to compensate for old Apache servers - it isn't needed in Apache 2+
    • Staff matches the literal string Staff
    • (/|$) matches either a forward-slash, or the very end of the URI path
  • -: If the pattern is found in the URI path, the second argument specifies what to replace the entire URI path with. In this case - indicates that the URI should not be modified.
  • [END,NC]: the third argument consists of boolean flags that further modify the rule.
    • END is similar to L (last), however indicates that this should be the very last rule processed within the context of the directory: if the pattern matches the URI, don't process any subsequent rewrite rules OR rounds (thus eliminating any possibility of handing the request to WordPress)
    • NC (NoCase) makes pattern matching case-insensative.
4
  • unfortunately, the same behaviour that ignores "RewriteEngine Off" ignores this solution as well. I am wondering if there is some kind of a bug in Apache?
    – Natalia
    Commented Feb 12, 2016 at 20:40
  • @Natalia I've updated the rule to be a little more authoritative... It could be that a higher configuration is altering mod_rewrite's behaviors - you could check parent directories for additional .htaccess files, then review the config file in for the VirtualHost WordPress is served on, then the global Apache config... Always good to see if Apache's error and access logs lend any insight =/ . I guess you could also log or dump the request URI as WordPress receives it to see if something else is altering it beforehand
    – bosco
    Commented Feb 12, 2016 at 21:06
  • @Natalia Modifying core files to troubleshoot a live environment is most definitely a bad practice (make a backup!), but you can log the relevant details about your requests by dropping the following at the top of the WordPress installation's root index.php file (replace Your IP Address appropriately): if( 'Your IP Address' === $_SERVER[ 'REMOTE_ADDR' ] ) file_put_contents( './my_requests.log', '[' . date('Y-m-d H:i:s') . '] URI( ' . $_SERVER[ 'REQUEST_URI' ] . ' ) PATH_INFO( ' . $_SERVER[ 'PATH_INFO' ] . ' )' );. Send the form request that results in a 404 and see what's logged
    – bosco
    Commented Feb 12, 2016 at 21:36
  • I've accepted the answer, because it does answer the question, however, the issue turned out to be somewhere else :). I have just tested set up two test files on another account on the same server, and after the recent Apache upgrade the word 'select' (and a few others I am sure) in a form field generates 403 forbidden error.
    – Natalia
    Commented Feb 13, 2016 at 14:56
0

WordPress has several methods for seeing PHP Errors, Warnings, and Notices. Specifically, you can set WP_DEBUG to true and enable WP_DEBUG_LOG and WP_DEBUG_DISPLAY, as per these instructions.

However, I am not sure that will fix your issue, as the 404 error likely indicates that your file does not exist, which may not generate any PHP errors. Are you sure that you are entering the exact url, on the correct server, etc?

3
  • yes, the page exists, I attached a screenshot.
    – Natalia
    Commented Feb 12, 2016 at 3:12
  • and I am actually not sure if setting WP_DEBUG will do anything, as this is not a Wordpress page. I just need to disable Wordpress 404 redirection without disabling permalinks somehow.
    – Natalia
    Commented Feb 12, 2016 at 3:17
  • Enabling WP_DEBUG in a live environment is inadvisable as the debugging configuration may expose additional vulnerabilities.
    – bosco
    Commented Feb 12, 2016 at 4:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.