Imagine you have a view that lists upcoming events on your Drupal 8 site. There's a date filter that filters out any event who's start date is less than the current date. This works great until you realize that the output of the view will be cached in one or many places (dynamic page cache, internal page cache, varnish, etc). Once it's cached, views doesn't execute the query and can't compare the date to the current time, so you may get older events sticking around.

I'm working on a site where the editorial staff may occasionally produce animated GIFs and place them in an article. Image styles and animated GIFs in Drupal don't play nice out of the box. Drupal's standard image processing library, GD, does not preserve GIF animation when it processes them, so any image styles applied to the image will remove the animation.

I recently worked on porting over a website to Drupal that had several dynamic elements throughout the site depending on the IP address of the user. Different content could be shown depending on if the user was within a local network, a larger local network, or completely outside the network.

I just finished up a small project at work to create a basic resource management calendar to visualize and manage room and other asset reservations. The idea was to have a calendar that displayed reservations for various resources and allow privileged users the ability add reservations themselves. The existing system that was being used was a pain to work with and very time consuming - and I knew this could be done easily in Drupal 7. The solution could be extended to create a more general resource booking / room booking system.

I've been away from full time Drupal development for a couple of years and have recently returned, this time making a commitment improve my understanding of core. There's a lot of information out there on Drupal caching, but I found much of it to be fragmented and outdated (Drupal 6). I wanted to provide a more comprehensive look at Drupal 7's core caching, explaining how some of this stuff is actually working under the hood.

I recently started on a project that involves migrating some data from a legacy app & database into Drupal. The old application is a collection of PHP scripts that basically just generate forms, accept data, insert said data into the database, and output it on a website. Pretty simple stuff - there's not a whole lot going on. It was developed long before many of the popular CMS's and frameworks came to be, and probably before people really started paying attention to the character encoding of their data.

In case you've been living under a rock for the past two years: Drupal 7 is known to use quite a bit of PHP memory everytime a page is loaded. I won't get into anything why that is and why it's such a big jump from Drupal 6 (I'm in no position to comment on that), but what you need to know is that Drupal 7 can easily use 40-50 MB per page load for a small to mid size website, and much much more for larger websites. Turn on some sort of PHP opcode cache like APC and you can probably get that small to mid site down to 10MB of usage or lower.

Last weekend @ DrupalCamp New Jersey, Tim Plunkett presented a wonderful alternative of the Calendar module for Drupal, called FullCalendar. I could be wrong, but I believe this was the first presentation given on the module which is very close to a stable release for Drupal 7.

At DrupalCamp NJ (the first ever, glad NJ is getting some love!), Jesse Beach from Acquia presented her thoughts how content is served in Drupal, and how to fix some problems that have surfaced over the years of web development. The traditional method for serving content to browsers is to have the server send off the entire DOM all at once.

I've been working on a project that requires the search block look a very specific way. The text input and submit button needed to be directly next to one another. I could probably get it done with just CSS, but all the extra markup in the search block was really bothering me.