Version 3.0.135 of ProcessWire on the dev branch focuses on .htaccess updates, adds additional layers of security, adds clarity to debug mode, and improves upon the installer.
This week a lot of focus went into making some updates to our root .htaccess file. I don’t like updating this .htaccess file very often because I know that’s something that requires manual updates for many existing installations. But we’ve recently had some great ideas from users such as Teppo and Netcarver. In addition, I compiled a bunch of other updates I’ve been wanting to make to it for a long time. Things like options for AWS/load-balancer setups, more optional features, optimizations to various rewrite rules, and more. Between all of these, it seemed like a good time for a core .htaccess update. Among other things, this post will detail how to update your existing .htaccess to the newest version. While not technically required, the update is still worthwhile.
Regardless of what ProcessWire version you are running, you can upgrade to the new .htaccess v301 now, as it is compatible with not just ProcessWire 3.0.135, but also all prior versions of 3.x and 2.x (as far as I know). So while this version of the .htaccess comes as part of ProcessWire 3.0.135 on the dev branch, there’s not any reason I can think of at present to wait for the dev version to become the master version before installing this .htaccess update, should you want to.
If you have never modified your main .htaccess file, then you can simply replace the old one with the new one. If that’s all you need then just replace the file and you are done.
But chances are that you have updated something in your .htaccess file, such as uncommenting rules for enforcing HTTPS, redirecting domain.com to www.domain.com (or reverse), adding custom redirects, or any number of other things. If you already know what you've changed or added to your existing .htaccess file and are comfortable applying the same updates to the new .htaccess file, then that's a solid route to take, and there's no need to read further. But the rest of these instructions assume you have an existing .htaccess file that you'd like to update, focusing on the most significant stuff, and leaving out everything else.
For these instructions, I’m also assuming your current .htaccess version is 300, which is what it would already be if you are running any version of ProcessWire 3.x. Though earlier versions of the .htaccess were also very similar, so should be roughly the same in terms of updates.
Replace all of section #5 in your current .htaccess file with section #5 of the new .htaccess file. This new section does the same thing as the old but blocks more file extensions with an emphasis on adding backup and temporary files that sometimes appear on web servers. Note that the new section #5 includes 5A and 5B, and you’ll want to include both of them.
Next, replace all of section #15 in your current .htaccess file with section #15 from the new .htaccess file. This improves upon our rewrite rules for access restrictions, adds detection for blocking more file types (like common backup extensions) and improves upon the inline comments and readability in the section.
You might notice the new section 15 includes 15A and 15B. The 15B part is optional and commented out by default. 15B blocks download of any archive files (like ZIPs and such) outside of /site/assets/files/. This is worthwhile because, when helping people with their sites, I sometimes come across http accessible archive files sitting on the server that appear to be copies of the database or perhaps even the entire site. They shouldn’t be there in the first place, but given that it happens and I’ve seen it a few times, I thought a rule in the .htaccess file to block these was good insurance. Of course, there are many legitimate uses for ZIP files or other archives, so that’s why section 15B is commented out by default. Uncomment it if you think it will be beneficial in your case.
The HTTPS enforcement section has been largely rewritten in the new .htaccess file. But if you are already enforcing HTTPS and all is working fine, then I would leave what you’ve got in your current .htaccess file. If you are not yet forcing HTTPS and plan to, then I would suggest replacing section #9 from your current file with section #9 from the new file. Everything that enforces HTTPS is commented out by default, but the new section #9 is more verbose and includes better comments and more options, so it’s worthwhile to use it if you will be migrating to full HTTPS at some point.
The new .htaccess file includes support for Strict-Transport-Security (HSTS) in section 9F, which forces client-side SSL redirection. This is different from server-side SSL redirection that appears in the earlier parts of section 9. For more details on why your site might benefit from HSTS see here.
The HSTS rules are commented out by default, so if you want to enable them you’ll want to copy, uncomment and edit one of the example HSTS lines in the .htaccess file. Though note that once you enable HSTS, it becomes non-revokable for the duration of the max-age that you set (typically a year). So if there are cases where your site must be accessible without SSL, or if there’s any danger that your SSL might expire and not get renewed for some period of time, you may want to skip HSTS.
Lastly, go to the top of your .htaccess file and locate the line that says # @indexVersion 300 and replace it with # @htaccessVersion 301 (note the change in wording from "indexVersion" to "htaccessVersion"). This will let PW know that your .htaccess file is now up-to-date. These instructions intentionally have focused only on the big picture changes and have left out everything else. If you'd like to review other small changes, search the new .htaccess file for the word "(v301)" and it will point out other parts that have changed.
After making changes, test out your site to make sure everything still works as you expect and if you run into any issues please let me know.
After installing 3.0.135, you may get some notifications about it installing System Update #17. Here we will take a closer look at what's in this update.
While working on the .htaccess updates (as noted earlier in this post), I felt that ProcessWire could benefit from having additional layers on top of the main .htaccess file. So not only does ProcessWire 3.0.135 update the main .htaccess file, but it also uses the SystemUpdater module to install several fallback .htaccess files at a few locations in /site/. While these aren’t technically necessary, they do serve as useful fallbacks in case the main .htaccess files ever goes missing for some reason. It’s another layer of security that likely will never be needed by most, but in certain cases it will be good insurance.
The additional .htaccess files that it installs essentially duplicate rules that are already in the main .htaccess file, but like already mentioned, they serve as fallbacks in case the main .htaccess file stops working or goes missing. That may seem unlikely, but actually it’s not as rare as you might think. Because .htaccess is a hidden file (i.e. has a leading period) it sometimes gets missed during site migrations since many file transfer utilities (FTP, rsync, scp, etc.) might exclude hidden files by default. In addition, an .htaccess file in the web root is a common file among nearly all CMSs running on Apache, which makes it a target, at least if you are running PW alongside another system like WordPress. Basically, I think having additional layers is worthwhile here.
Unlike the main .htaccess file, the extra .htaccess files should install automatically without you having to do anything. Though if any of the locations are not writable, it may ask you to copy the file in there yourself. It’s not required, so you decide if it might be beneficial in your case. After installing ProcessWire 3.0.135, see the System Updater log (Modules > System > System Updater), for a summary of updates it made and if any of them request action on your part. There may still be more fallback scenarios we can handle in a similar manner, but I thought this was a good place to start.
This week, ProcessWire’s installer received some small updates as well. The most significant is that it now asks you if you want to start out in debug mode. The reason for this is that lately I’ve come across new PW users that emailed me because they couldn’t figure out why they were encountering a 500 error after installation, or after making some modification to a template file. Essentially, they didn’t know about ProcessWire’s debug mode, which is something you definitely want enabled when you are getting started with ProcessWire.
At the same time, I don’t feel like I can just enable it automatically in the installer because NOT knowing about debug mode and having it ENABLED on a live site becomes a potential security concern. As a result, the installer now provides a fairly verbose description of what debug mode is and asks you if you want it enabled. It also tells you how to enable/disable it on your own by editing the config.php file.
In addition to the debug mode addition in the installer, superusers now get a notification about debug mode being enabled (if it’s enabled) when they login. The notification reminds them how to disable it when they are ready. If the login happens to be the first login (only) to a new installation of ProcessWire, and debug mode is NOT enabled, it also tells them about it and how to enable it if they want to.
Thanks for reading! Hope that you all have a great weekend and enjoy reading the ProcessWire Weekly!
14 June 2019 7
ProcessWire 3.0.133 adds a useful new $page->meta() method for a new type of page-specific persistent data storage, adds the ability for users to create their own bookmarks in Lister, and has a handy and time saving update for the asmSelect input type. Read on for all the details, examples and screenshots. More
19 July 2019
A look at two new WireMail modules for sending email, plus details on how you can configure ProcessWire to use Gmail for sending email. More
“Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his/her ways of doing things.” —Guy Verville, Spiria Digital Inc.