Jeff Geerling's blog

Hosted Apache Solr now includes Tika attachment support!

Besides self-managed IP addresses, the most requested feature for Hosted Apache Solr has been built-in support for file attachment indexing. Up until now, the only way you could add data from PDFs, JPGs, and other files attached to your Drupal nodes has been installing Apache Tika on your own webserver.

Today, we're happy to announce that support for attachment indexing has been added to all subscriptions on Hosted Apache Solr! You can find instructions for configuring your Drupal site to index attachments on the support page, Using Tika and the Attachments module to index PDFs, DOC files, etc..

If you have any trouble with attachment indexing, please contact support, as we may need to make an adjustment to older search cores to take advantage of this new feature!

Developing for Drupal with Vagrant and VMs

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

  • Should be simple and easy to set up
  • Should be fast by default
  • Should be flexible:
    • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
    • Should allow configuration of the PHP version.
    • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
    • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
    • Shouldn't have hardcoded defaults
  • Should be complete:
    • Should work without requiring a bunch of extra plugins or 3rd party tools
    • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
  • Should be Free and Open Source
  • Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
  • Should work on Windows, Mac, and Linux with minimal or no adjustment
  • Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

Honeypot for Drupal 8, 3 years in the making

Almost three years ago, on Feb 19, 2013, I opened the 8.x-dev branch of the Honeypot module (which helps prevent form spam on thousands of Drupal sites). These were heady times in the lifetime of the then-Drupal 8.x branch; 8.0-alpha1 wasn't released until three months later, on May 19. I made the #D8CX pledge—when Drupal 8 was released, I'd make sure there was a full, stable Honeypot release ready to go.

Little did I know it would be more than 2.5 years—and counting—before I could see that promise through to fruition!

As months turned into years, I've kept to the pledge, and eventually decided to also port a couple other modules that I use on many of my own Drupal sites, like Wysiwyg Linebreaks and Simple Mail.

Two years ago, I mentioned in the original Honeypot D8 conversion issue that I'd likely write a blog post "about the process of porting a moderately-complex module like this from D7 to D8". Well, I finally had some time to write that post—and I'm still wondering how far off will be the release of Drupal 8.0.0!

Thoughts on the Acquia Certified Developer - Front End Specialist Exam

Previously, I posted my thoughts on the Acquia Certified Developer - Back End Specialist exam as well as my thoughts on the Certified Developer exam. To round out the trifecta of developer-oriented exams, I took the Front End Specialist exam this morning, and am posting some observations for those interested in taking the exam.

Acquia Certified Developer - Front End Specialist badge

My Theming Background

I started my Drupal journey working on design/theme-related work, and the first few Drupal themes I built were in the Drupal 5 days (I inherited some 4.7 sites, but I only really started learning how Drupal's front end worked in Drupal 5+). Luckily for me, a lot of the basics have remained the same (or at least similar) from 5-7.

For the past couple years, though, I have shied away from front end work, only doing as much as I need to keep building out features on sites like Hosted Apache Solr and Server, and making all my older Drupal sites responsive (and sometimes, mobile-first) to avoid penalization in Google's search rankings... and to build a more usable web :)

How to edit and navigate chunks of a giant text file on Mac/Linux

For most log and text files, simply opening them up in $editor_of_your_choice works fine. If the file is less than a few hundred megabytes, most modern editors (and even some IDEs) shouldn't choke on them too badly.

But what if you have a 1, 2, or 10 GB logfile or giant text file you need to search through? Finding a line with a bit of text is simple enough (and not too slow) if you're using grep. But if you want to grab a chunk of the file and edit that chunk, or split the file into smaller files, there's a simple process that I use, based on this Stack Overflow answer:

  1. Run the following once to find the starting line number in the file, then again to find the last line you're interested in:
    grep -n 'string-to-search' giant.log | head -n 1
  2. Taking the results of the first search (X) and the second (Y), create a smaller chunk of the giant file in the same directory:
    sed -n -e 'X,Yp' -e 'Yq' giant.log > small.log

I usually don't need to reunite the smaller chunks again, but if you do, you can recombine the file using the suggestion in the original Stack Overflow answer.

Thoughts on the Acquia Certified Developer - Back End Specialist Exam

A little under a year ago, I took the Acquia Certified Developer exam at DrupalCon Austin, and posted Thoughts on the Acquia Drupal Developer Certification Exam. My overall thoughts on the idea of certifications for OSS like Drupal remain unchanged, so go read that previous post to hear them.

I wanted to post a little more about the additional certifications Acquia is now offering; in addition to the initial, more generalist-oriented Acquia Certified Developer Exam, Acquia now offers:

Earlier today, I took the Back End Specialist Exam, which focuses more specifically on things like Drupal's core API, general PHP syntax and style, secure code, content caching, debugging, and interacting with the Drupal community.

Acquia Certified Developer - Back End Specialist badge

Like the other certification exams, you get 90 minutes to complete the exam (60 questions total), and you have to take the exam either online or in a testing center with an active proctor. This time, I elected to take the exam on my own computer, which was a little more annoying than taking the exam in-person at a test center (as I did at DrupalCon last year).


Subscribe to RSS - Jeff Geerling's blog