website

Update: After posting the video yesterday, the site was hit by more low-complexity DDoS attacks, mostly just spamming one URL at a time. After I cleaned those up, the attacker finally switched to a more intelligent offense, posting actual comments to the site overnight. This morning I noticed that, and the fact the attacker found I left my edit domain un-proxied, so I switched to a different IP on DigitalOcean and shored up the Cloudflare configuration a bit more.

It was a good thing I did that, because about the same time, I got an email from DigitalOcean support saying they had to blackhole the other IP for getting 2,279,743 packets/sec of inbound traffic. Sheesh.

After cleaning up a few bits of fallout, the site should be running a bit better at this point, DDoS or no.

Over the years my site has evolved quite a bit; I started this site (well, one form of it at least) around 2004, when table based web design was still a thing. I've evolved the design from table-based to CSS, to semantic CSS, to CSS + RDF, then to mobile-first... and now that macOS 10.14 Mojave is here, with a snazzy (and way easier on my eyes) dark mode, I have made the design work well in both normal (light) and dark mode on macOS.

It's using a new feature in the Webkit nightly builds (er, now called Safari Technology Preview), a media query named (at least, for now) prefers-color-scheme.

And here's how the site looks when you're using Safari Technology Preview 68+ in macOS Mojave with Dark Mode:

A question which I see quite often in response to posts like A modern way to build and develop Drupal 8 sites, using Composer is: "I want to start using Composer... but my current Drupal 8 site wasn't built with Composer. Is there an easy way to convert my codebase to use Composer?"

Unfortunately, the answer to that is a little complicated. The problem is the switch to managing your codebase with Composer is an all-or-nothing affair... there's no middle ground where you can manage a couple modules with Composer, and core with Drush, and something else with manual downloads. (Well, technically this is possible, but it would be immensely painful and error-prone, so don't try it!).

When I was rebuilding www.jeffgeerling.com in Drupal, I decided to use the testing domain new.jeffgeerling.com. This presented me with a challenge, once I started working a bit more on the site, as I set up imagecache, the file system, the favicon, the logo, internal images in posts, images inserted into blocks, etc., into my /sites/new.jeffgeerling.com/files directory.

If I simply renamed the directory to 'jeffgeerling.com' and went live, I'd end up with tons of 404 errors. Currently, there's no easy way to switch the location of your files directory in Drupal. Lacking an easy method, it's time to get your hands dirty with a little SQL (I entered the following commands via phpMyAdmin, since my host doesn't yet allow SSH access):

This weekend I am going to attend the Catholic New Media Celebration. I'll be on two plane flights, I'll be sitting at an airport for a few hours before each flight, and I'll be at a convention all day Saturday. I'm hoping to build out a new site idea I've had lurking in the back of my head for some time: Open Source Catholic.

In the past 45 minutes, I've been jumping around Drupal.org downloading all the different modules and tutorials I think I'll need. I've also saved some of my previous work on other Drupal sites in case I need to refer to a code snippet along the way while I don't have Internet access. I'm going to call it a night for now (I need to pack!), but tomorrow, beginning at the airport, I'm going to start working on the site.

In what will be the first of, I hope, many case studies, I review the process of redesigning the Saint Louis Review website, from the ground up.

The Saint Louis Review is a local Catholic diocesan newspaper serving the nearly 500,000 member Archdiocese of Saint Louis. The newspaper has had a website since the late 90s, which was ported to a custom-designed CMS in 2001. The PHP/MySQL-based site ran quite well throughout the first decade of this millennium, but was in need of either a serious overhaul or a redesign, to go along with the paper's new tabloid layout in April 2009.

The decision was made in 2007 to port the website to Joomla, but after a few months, a new editor, and more work, it was determined that, due to its extensibility, flexible out-of-the-box permissions, and standards/SEO-compliant codebase, Drupal would be a better fit for the site. Work was begun in January of 2009 to transfer the custom CMS' articles database (over 17,000 articles) to a Drupal site, create a new template based off the colors and design of the new tabloid-format paper, and integrate an easier-to-manage ad system and back-end.

I follow a lot of Twitter users among my accounts; probably somewhere around 400-500 different twitter-ers. Because of this, I often get some awesome links to tutorials, guides, how-tos, and general information; many links which I would miss otherwise, because they won't show up on reddit, digg, or other social link sites.

When Twitter users give high-quality, low-visibility links, users read their tweets and blogs more often than the users who spam their Twitter streams with tons of links to their own content. In my opinion, very few people can often and consistently write top-notch content on their own blogs. There are exceptions, but most bloggers are not professional writers, and therefore need to focus not solely on their own writings, but on others' as well.

Whenever you're designing a website, one of your primary goals, besides communicating the mission of the organization for whom the website is being made, should be to make the website accessible to all visitors, no matter what kind of computer or browser they have, and no matter what kind of disabilities they have (whether it be blindness, deafness, or other problems).

Luckily for you, there's a free and easy-to-use tool on the web that lets you check how well your website conforms to coding standards:

The W3C generously provides this service to further their mission of having an open, accessible and free web. The tool is dead simple to use: just type in your website's URL, and click Validate. Errors will then show up, and you can go back to your source code and fix the little mistakes you've made. But there's a lot more about Validation that needs to be said!