Built with Drupal 8: A Front-Ender's Tale of Danger and Suspense

Error message

  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /home1/markspap/public_html/kathy/includes/menu.inc).
  • Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /home1/markspap/public_html/kathy/includes/common.inc).
May 3, 2015

UPDATE: In August 2015 I moved this site back to Drupal 7. Drupal 8 is still in beta, and though it's going to be fun, it's obviously not ready for prime time yet.

A few weeks ago I decided to rebuild this blog from scratch.  It had been literally years since I'd posted, so I figured I'd include just a few of the last entries.  Also, Drupal 8 was in beta and I'm impatient.  Why not build a brand new site in 8.0.0-beta9?, I thought.   How hard could it be?

So, okay.  It was a little bit hard.  But surprisingly, the experience wasn’t as hairy as you might expect.  Here’s a summary of my adventurous, experimental walk on the wild beta side. 

Installing Drupal 8

Before I go further, I should mention that I installed Drupal 8 on a previously set up local environment.  (If you don’t know what that means, you can find out more here.   For fellow Mac users, I’d recommend these instructions.)

Honestly, installation was a breeze.  The whole process took less than 5 minutes and was similar enough to Drupal 7 that I felt on solid ground.  I just downloaded and untarred core, added a new database in Mamp, went to the site in my browser and followed the instructions.  Easy peasy.

Playing with core was equally as uneventful and fun.  I added a new user, enabled and disabled core modules, added a new content type and a taxonomy vocabulary, tweaked permissions, etc.  All without a hitch.  The admin interface looks and acts almost the same as D7's. For someone who builds a lot of sites for non-technical admins, this is a big relief.

I decided this was easy.  Drupal 8 was a lot more stable than I’d expected.  I was feeling confident, so I decided to try creating a custom theme.

Custom Theming: Take One

Considering D8’s not even released yet, the documentation on drupal.org on Theming Drupal 8 is pretty extensive.  In fact it’s so extensive, it’s a bit overwhelming at first. 

If you're familiar with D7 theming and just wanted to get up and running quickly, you might prefer 27 Questions (and Answers) from My First Drupal 8 Site Build by Matt Korostoff.  His article was extremely helpful, although I was glad to be have the d.o documentation to refer to when I got stuck or wanted to delve into something more deeply.

Adding JS, CSS and Font Files and Libraries

I decided to keep a hand on the tow line and created a Classy subtheme, following Matt’s instructions for setting up the x.info.yml and and x.libraries.yml files.

You can see the .info.yml file looks a lot like the .info in Drupal 7.  The main difference is the way CSS and JS are added.  Instead of adding them directly to the .info.yml file, you include a reference to a .libaries.yml file, and that is where you add your scripts, stylesheets and dependencies. That was probably the biggest gotcha for me--figuring out how to include JS scripts, libraries and dependencies and font libraries.  There was conflicting information on the webs, but this is what worked for me:

Because I had a number of CSS and JS files, I followed the advice (from d.o. maybe?) to break them into two groups—global-styling and global-scripts,. These will now be available to every page.

My scripts.js is actually just a teeny few lines to handle the navigation bar, but surprisingly, Drupal 8 doesn’t load JQuery on every page automatically like D7 did. You have to add it as a dependency, as well as any other js you want to run on every page.

One thing I never figured out was how to add my custom fonts. I use Google's PT Serif and Inconsolata in this theme, and the only way I could get the fonts to load was by adding an @import to my main CSS file:

@import url(http://fonts.googleapis.com/css?family=Inconsolata|PT+Serif:400,400italic,700,700italic);

It works, and that'll have to do for now.

Twig Templates

I find Twig to be easier and more intuitive than the PHP of previous .tpl.php files. If you don't agree, some of the documentation on d.o might be helpful, especially Twig Coding Standards.

The Classy theme was a godsend for me when it came to creating custom templates. Whether you create a subtheme of Classy or not, you can look at the slew of templates it includes to get an idea of how to create your own.

For this theme, I needed a custom block--search-form-block.html.twig and changes to page.html.twig and node.html.twig. For instance, like Matt Korostoff, I don't much like the default "submitted by" line. To tweak it, I copied the node.html.twig from Classy, plopped it in my theme's template folder, and changed the line:

I still haven't figured out how to get my custom date/time format to print, but I'll keep working on it. :)

Custom Modules and More

I enabled a few contrib modules (Prepopulate, Youtube Field, Captcha and Recaptcha) that were absolutely required before going live. All worked beautifully out-of-the-box. However, the other contrib modules I tried gave me either a WSOD or that ghastly pink error message.  

At this time I'd recommend enabling contrib modules cautiously, if at all.  Most are still in dev for a reason.  Maybe try them on a test install first and see what blows up.

Luckily this is a simple site that can run without many contrib modules. If you have a complex site that requires a number of them, you may have to wait a bit before they're all ported to 8. Bluespark publishes a helpful live list of the current status of the top 100 Drupal modules. Check it out to see if your modules are listed.

I'm know you're waiting on tenterhooks for your favorite modules, but remember that most of the people who create and maintain contrib modules do so on their own time and without pay.  That's pretty darn generous of them, and I'm grateful for all the vacation time and off hours they spend creating modules that make my life easier. Unless I'm able to jump in alongside and start slinging code, I'm happy to wait patiently for contrib modules to be ported.

(Note to self: Patience you must have, my young padawan.)

Conclusion

The (sort of) bad news: Not everyone is crazy enough to spend two days and nights building a D8 site. It still isn't easy. You may get discouraged.  You will lose sleep. I still can't get drush 7 (required for D8) to rebuild caches. Importing and exporting a database between dev and live without at least a few WSODs is nigh on impossible. I encountered a number of alien requirements and strange error messages that took time to track down and debug.

The good news: Smarter people than me are working on those problems. Yay!

More good news: I'm no longer afraid of WSODs or error screens that fill three screens. Also, I busted my local dev site and had to rebuild it so many times, I now know a great deal about installing, enabling and configuring Drupal 8.

Was it worth it? You betcha! I'm no programmer, so I was nervous about Drupal 8 coming down the pike. I'm not nervous anymore. In fact, I'm looking forward eagerly to a release candidate.

Thanks to all the people who put so much time and effort into Drupal 8. It's really spectacular, and we thank you for generously sharing your code with us.

Comments

Viagra Efectos Causa

Dapoxetina Costo

Pages

Add new comment