ProcessWire Weekly #300

In the processwire.com blog this week: a case story about fending off a DDoS attack, and the lessons learned

This week's post at the processwire.com blog covers something other than our typical core or module update related posts: it's essentially a case story by Ryan about how a relatively large scale DDoS attack aimed towards our support forum was fended off, and what was learned during the process.

For those looking for weekly core updates: this week there were only a couple of small updates; the modules directory URL in wire/config.php now points to the HTTPS version of the repository and core version in the dev branch was officially bumped to 3.0.150.

What is known about the denial of service attack against the ProcessWire support forum

Starting last Saturday, our support forum — which, as you may know already, is powered by IP.Board and not a ProcessWire site in itself — was under large amount of suspicious traffic. According to Ryan this traffic seemed to come from Chinese IPs, and targeting some lesser known (and relatively performance-intensive) features of the forum.

As a result of this attack there were a number of outages and slowdowns on the forum and on the processwire.com website during the week. This, of course, is less than ideal situation, as a lot of folks are relying on the site all the time, and at any given time there are also plenty of users on the support forum.

The steps taken to fend the attack off, and why we're now better prepared should anything similar happen again

In his post Ryan walks us through the steps that were taken to prevent such issues in plenty of detail, so we won't dive too deeply in the actual practical examples here, but to summarize the key points:

• As far as we know there was no real reason for anyone to attack our site — likely the IP.Board forum software itself seemed like a worthwhile target for an attack.
• This attack was distributed enough (hence DDoS, not just DoS) to make blocking individual IP addresses almost impossible, while blocking entire regions would've been harmful to real users, so this option was out of the question.
• First step was to optimize and upgrade our hosting setup, which meant among other things setting up more efficient caching solutions, switching forum image features to use ImageMagick (instead of GD), and more.
• Long story short, our server environment has now been reinforced against such attacks, and there's an automated script in place that — based on server load — has the ability to intelligently shut down certain features if need be.

Currently both our site and the forum are running smoothly, and the traffic is back to normal. Even if similar attack should occur again, which is always possible, there are already various measures in place that would shield us from the bulk of its effects.

For more details on what aforementioned "automated script" actual does, and what other measures were put in place, be sure to check out the full blog post. Thanks!

New module: Cache Control

Cache Control is a brand new module by Moritz L'Hoest. The way this module works is that you can configure (via module settings) which caches to clear when the default cache action is executed, and actually executing this action happens via a separate admin link (Setup > Clear all caches).

The module also supports programmatically added cache actions, which means that if this single "clear all caches" action isn't quite enough for you, you can extend it — and you can also define a permission for each specific action, which gives you a ton of flexibility when it comes to defining who can do what in terms of cache clearing.

For more details as well as some additional features related to asset cache busting etc. check out the README file in the Cache Control GitHub repository.

For those that are already familiar with the Clear Cache Admin module — which also deals with cache clearing via the Admin — the biggest differences as we see it are...

• Cache Control provides no options in the cache clearing context, which allows you to define a safe set of cache clearing features and then provide less privileged users a single link they can use to execute this "cache action". Clear Cache Admin is, by design, more of a superuser tool due to the provided in-context options.
• Cache Control has support for multitude of cache actions you can define — as well as trigger — via the API. This makes it handy for situations where certain operation happening behind the scenes (including a scheduled script run) should trigger the cache to be cleared in a specific way.

A quick word of warning, though: this module is still in beta, and shouldn't be installed on a production website without taking all the appropriate precautions (backups and whatnot). That being said you can give it a try right now by grabbing the module files from the Cache Control GitHub repository.

Big thanks to Moritz for sharing this module with us!

New module: Inputfield Selector Select ID

Inputfield Selector Select ID, the latest module by Robin Sallis, makes a small but quite interesting tweak to Inputfield Selector — an inputfield that you'll typically see in action while searching for pages, but may also come across in custom listers created using the Lister Pro module etc.

When adding a filter row for "Parent", "Has parent/ancestor", or "ID", by default you're greeted with a regular HTML text input asking for the Page ID — but what this module adds to the mix is a little thunderbolt icon within this field, and when you click that, a modal window containing a Page List Select is opened.

While Page IDs are no doubt familiar to most developers and most likely to experienced content editors as well, they may feel confusing to regular content editors — and having to check the Page ID from a separate tab or window isn't necessarily the nicest thing for experienced users either. As such, what this module does is a really nice addition — and definitely an improvement to the UI/UX of the Selector Inputfield.

If you'd like to give this module a try, you can do so by installing it via the Admin modules manager, or you can grab the module files directly from the Inputfield Selector Select ID GitHub repository. Thanks to Robin for sharing this very useful module with us!

Site of the week: the portfolio of art director René Paritschkow

Our latest site of the week belongs to freelance art director René Paritschkow from Dresden, Germany.

With a background in agency work and decades of experience under his belt, René now works together with other freelance programmers, copywriters and photographers on both digital and offline creations — brand development, logo design, corporate design and web design.

This website was designed by René Paritschkow and developed by Björn Steinborn, and features a slick, minimalist, and modern design, exceptional performance profile, and very interesting and varying list of different projects. Each project has its own page, but apart from that the site is rather compact: home page, project pages, and a few pages with general information is all there is to it.

Some of the technologies used on this site include modules such as All In One Minify (AIOM) and ProCache, on the front-end libraries like Isotope, Handlebars, and the Plyr Video Player — and, as an external dependency, the tinypng API. Thanks to the sites directory entry we also know that this site was developed using the ITCSS approach.

Our congratulations to René Paritschkow for this amazing site, and thanks to both René and Björn for trusting ProcessWire and sharing this project with us. Stunning work!

Stay tuned for our next issue

That's all for the 300th issue of ProcessWire Weekly. We'll be back with more news, updates, and content Saturday, 15th of February. As always, ProcessWire newsletter subscribers will get our updates a few days later.

Thanks for staying with us, once again. Hope you've had a great and productive week, and don't forget to check out the ProcessWire forums for more interesting topics. Until next week, happy hacking with ProcessWire!