{"id":1377,"date":"2023-11-19T17:30:27","date_gmt":"2023-11-19T23:30:27","guid":{"rendered":"https:\/\/www.nathanhunstad.com\/blog\/?p=1377"},"modified":"2023-11-19T17:30:27","modified_gmt":"2023-11-19T23:30:27","slug":"fun-with-mod_security-htaccess-and-php-updates","status":"publish","type":"post","link":"https:\/\/www.nathanhunstad.com\/blog\/2023\/11\/fun-with-mod_security-htaccess-and-php-updates\/","title":{"rendered":"Fun with mod_security, htaccess, and PHP updates"},"content":{"rendered":"\n

It all started with an updated PHP version. This website had been running on PHP 7.4, which went end of life a year ago. I had requested several times that my hosting provider update to a supported version of PHP for security reasons, but was rebuffed. A week ago I decided to ask yet again, and this time HostGator migrated my site to a server with PHP 8, probably to get me to stop complaining. Post-migration, I changed my site to use PHP 8.1 because trying 8.2 broke everything, clicked around some to make sure everything still appeared to be working, and moved on from what I thought was a successful upgrade.<\/p>\n\n\n\n

Problems Found<\/h2>\n\n\n\n

Today, I get an email from Google Search Console stating that some of my pages were returning 4XX errors. I am certainly not an expert on Google Search Console, but if you have a website, it’s a very good idea to use it to find these kinds of errors. When I looked at the pages that were being flagged as unreachable, I noticed that they were photos from the photo side of my site, which runs on ZenPhoto. All of the affected URLs ended in “jpg.php”, and all of them had a 406 error with the message “Not Acceptable!
An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.”<\/p>\n\n\n\n

\"\"<\/a>
No, YOU’RE not acceptable!<\/figcaption><\/figure>\n\n\n\n

It appeared that all of the individual photo pages in my albums had this problem, and that meant that phots were pretty much inaccessible. Not good! I did some searching and came across this forum post<\/a>, which suggested changing the URL options mod_rewrite suffix under “Options…General” to .html from .php:<\/p>\n\n\n\n

\"\"<\/a>
URL Options in ZenPhoto<\/figcaption><\/figure>\n\n\n\n

Changing this option did solve the 406 Not Acceptable error, and my images were being served up again, with a .jpg.html URL instead of .jpg.php. However, as that forum post stated, changing this option will change your URLs and can mess with SEO. That’s exactly how I became aware of the problem in the first place: the URLs that Google indexed were using the old .jpg.php URLs, and although this website is certainly not popular enough to be getting a lot of traffic to random photos from Google, the fact that this would break URLs in Google search results just annoyed me.<\/p>\n\n\n\n

301 To The Rescue<\/h2>\n\n\n\n

The correct way to deal with this kind of issue is to set up a 301 Moved Permanently redirect on the old URLs to point to the new ones. This is something you can do by using rewrite rules in your .htaccess file. But first, I had to fix the 406 error that caused the issue in the first place.<\/p>\n\n\n\n

HostGator controls the mod_security rules, but per this article<\/a>, you can reach out to them to selectively disable rules if they are causing any problems with your website. So I did this, and they very quickly removed the rule that was causing that error. Once that error was gone, I could add this very simple rewrite rule to rewrite anything that ended with “.jpg.php” to “.jpg.html”:<\/p>\n\n\n\n

  RewriteRule ^(.*)\\.jpg\\.php    $1.jpg.html [R=301,L]<\/code><\/pre>\n\n\n\n
With this rule in place in the .htaccess file in my photo folder, all of my old URLs would redirect to the new one and display properly, something I validated by trying one of the URLs that Google had alerted me on.<\/p>\n\n\n\n
I then regenerated my sitemap<\/a> files so that going forward Google will get the correct URLs for all content, and will monitor those URLs going forward. I also triggered a recheck of the URLs that were throwing errors so Google can validate that the redirect works. And that was that!<\/p>\n\n\n\n
Do It The Harder Way<\/h2>\n\n\n\n
Now, if you were paying attention, at this point you would likely ask “Couldn’t you have skipped most of this by asking HostGator to just fix the mod_security rule and keep the URLs ending in php?” And yes, that would have solved the immediate problem of broken URLs. However, .html is the preferred value for that option now, and it’s one I also prefer. Plus, had I stopped there, I would never have learned how to create those rewrite rules, which is a handy skill to have.<\/p>\n\n\n\n
It took a bit more work, but I did learn a few things about .htaccess files and mod_security along the way. And sometimes, you just need to bite the bullet on breaking changes!<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
After upgrading my website to PHP 8.1, Google alerted me to some URLs that were being blocked by mod_security. Learn how I fixed that error and set up rewrite rules to fix the old URLs on the fly.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[127],"tags":[301],"class_list":["post-1377","post","type-post","status-publish","format-standard","hentry","category-security","tag-php","entry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t