Drupal

Whither Metatag 1.0?

Submitted by on

Tags: 

In my recent appearance on the DrupalEasy podcast I mentioned that I was aiming to have Metatag 1.0 ready by the end of February. Next week is the end of February and, being honest, I haven't really touched it since releasing 1.0-beta9 on Drupal's birthday, January 19th last. I felt it best to explain where my contrib efforts have been lately and explain why I'm not making my goal.

As you might be aware of, I co-maintain a number of modules along with Metatag. One of the ones I like the best is Panelizer, a module originally written by Earl "merlinofchaos" Miles as a replacement for the lackluster Panel Nodes submodule of Panels. I originally helped with its port from D6 to D7 as I thought it had great potential, but it truly came into its own when Earl released v3 back in 2012 when it went from "Panel Nodes++" to a complete solution for displaying all view modes (!) of all entities (!!). The module has become critical to my site building tool chest and several projects I'm working on need several key bugs and feature improvements resolved. As a result, for the past month I've been focusing on fully understanding the detail of many of these issues so that I can lead the charge on the forthcoming v3.2 release.

Additionally, recently I've become the co-maintainer for many of helper modules for Panels - Panels Everywhere, Panels Content Cache and Panels Hash Cache, so I've also been trying to improve them bit by bit and learning how best to use them in my own sites.

Lastly, I've also been trying to finish off the next release of Code Per Node, and because of trying to help a friend I've ended up becoming co-maintainer of the AntiSpam module, which needs some fixes.. and there's Nodewords for the existing D6 sites.. and I need to do a new release of GoogleNews.. and...

So, as you can guess, I haven't gotten back to Metatag lately.

My current plan is to finish off the important fixes for Panelizer and then loop back to do another round of bug fixes & patch reviews for Metatag, which should lead to v7.x-1.0-rc1. After that I'll probably bounce around between Panelizer, Metatag, CPN and Panels Everywhere while I put together stable releases for each one, so hopefully by the end of March there'll be a bunch of new stable releases out.

Before I go I'd like to firstly thank my awesome employer Mediacurrent who sponsor much of my work on these modules, and Gregory Boggs for using Metatag as the guinea pig with a number of Drupal beginners he was helping

On contributing to Drupal 8 [updated]

Submitted by on

Tags: 

Recently Drupal 8's development reached two milestones that have created lots of discussion – contrib project maintainers are now being asked to start porting their modules, and two well known core contributors (Dave Reid, Nate "quicksketch" Haug) have asked to be at least partially removed from the list of core maintainers. As a long time contributor, I'd like to share my opinion on these.

First off, on porting modules to Drupal 8

The Drupal 8 codebase hit "code freeze" on July 1st and I celebrated with my family by having a baby. That said, the APIs are not really frozen and there are a lot of agreed-upon major API changes expected shortly, never mind ones that will likely be identified over the next few months. This means that the Drupal 8 API continues to be a moving target and will continue to be so for several more months, which makes porting a module a bit problematic, particularly for people who don't have a lot of spare time on it.

Secondly, on people "leaving" Drupal

Remember that, other than a select few, the majority of core contributors are not paid for their contributions to core, they do so on their own personal time, and this is time that could instead be spent hanging out with (non-Drupalist) friends & family, with new babies, etc. Being listed in the Drupal MAINTAINERS.txt file indicates that you are committing to putting a good amount of time into working on improvements & bug fixes until that release of Drupal reaches its support end-of-life, which could be three to five years after launch.

Lets be clear about this - neither Dave nor Nate are leaving Drupal. Dave has come to the realization that he didn't have time to put the effort into maintaining certain core components (Contact, Path), and doesn't currently have the necessary time to fully learn how rewritten components (Path) work with the new D8 architecture. Because of these, Dave has decided to limit himself to just maintaining the core Token module, along with the large volume of contrib modules he's involved with, most notably the Media module, rather than making promises he can't keep by saying he'll co-maintain Path or Contact.

Nate, on the other hand, feels like the components he put a great deal of effort into for Drupal 7, specifically the image processing system and the image field, are so completely divorced in D8 from what he had written for D7 that he felt it was no longer appropriate to remain as the maintainer of those components. Furthermore, Nate states that he no longer feels comfortable working with Drupal 8, so do not expect to see his (awesome) modules to be ported to D8 any time soon. That said, he is committed to supporting D7 and his D7 modules for some time and will re-evaluate D8 at some point in the future when it's stable & usable.

Don't panic!

In neither case should a Drupal user be overly concerned about either contributor's intentions. I see their moves as a nothing more than the community realigning itself after a) the vast amount of internal changes that have gone into D8, b) the fact that people have lives outside of Drupal. Yes, both Nate and Dave are amazing members of the community, and both really great people too, but lots of others have only started to contribute during the D8 development cycle, so it will survive. And I'm still looking forward to seeing both Dave and Nate at next year's Drupalcon (presuming I go), and also meeting some of the many new contributors.

Pick your battles

Also keep in mind that we now have six codebases to contribute to:

  1. Drupal 6 core
  2. Drupal 6 contrib
  3. Drupal 7 core
  4. Drupal 7 contrib
  5. Drupal 8 core
  6. Drupal 8 contrib

There's only so much time in the day, so you have to pick what you're comfortable with otherwise you're setting yourself up for burnout, and nobody wants you to do that. Remember that nobody's expecting you to kill yourself in the name of the community, any contribution is worthwhile, no matter how small. There's no shame in stepping back, in looking for a new co-maintainer or maintainer for your existing project, the only wrong decision is to not realizing that you need to step back.

My intentions

As for myself, I was never that much of a contributor to core, mainly only interacting with the core issue queue when I came across a specific bug. I've also not had time to get into D8 due to both my contrib work and family life (e.g. aforementioned new baby), and I don't expect this to change any time soon - I'm still trying to get Metatag to a solid v1.0 after all! I'm not going to look into D8 until its APIs are stable (i.e. beta1 if not RC1), Metatag is stable and I get to do some new releases for some of my other modules (CPN, etc), so it'll be Spring 2014 at the earliest before I start porting my modules.

BTW, I'm also looking for a new co-maintainer for one of my modules as I haven't been able to give it the amount of time it deserves, if you're interested just reply in that issue and I'll get you set up.

Update: Nate Haug put his money where his mouth is and created a fork of Drupal called Backdrop which backtracked to before Symfony2 components were added, what might be considered Drupal 7++.

Panels / Panelizer / Panopoly presentation from Keenan Holloway

Submitted by on

http://www.slideshare.net/KeenanHolloway/paraphrasing-panels-panelizerpanopoly

Tags: 

Forum One's Keenan Holloway put together a really good presentation on what Panels, Panelizer and Panopoly are and why you should consider using them on your Drupal site. Also, I'd like to thank Keenan for the mention at the end :)

Drupal Search Engine Optimization (D7)

Submitted by on

As anyone who builds websites will know, search engine optimization (SEO), i.e. optimizing your website & its content to be more readily searched & discovered via search engines, is both deceptively simple in nature yet takes a good deal of time to maintain correctly. Drupal, the CMS system that I have focused my career on over the past four & half years, has many features that give it a leg up in the SEO battle, though in the end the single most important way of improving a site's SEO is by having good content. That said, there are some tools to help improve a Drupal site's SEO capabilities and a new book from Packt Publishing aims to guide you through it. So, how good is it?

Disclaimer: I was given a free copy of this book in exchange for this review.

The book has just five chapters: an intro to what SEO is all about, how to configure Drupal's core functionality to improve SEO, contrib modules that can help, building an SEO strategy, and tips for maintaining & monitoring the site's progress. All of this comes in at roughly one hundred pages, which is pretty short compared to the previous Drupal 6 SEO book, written by self-made Drupal SEO expert Ben Finklea, which was over 250 pages.

As the maintainer/co-maintainer for two of Drupal's most commonly used SEO-focused modules (Nodewords for D6, Metatag for D7) I was hopeful to see the modules I've put much of my personal time into improving see some promotion, and I wasn't too disappointed in this regard.

The third chapter starts with a page explaining what contrib modules are how to search the Drupal website for them, which should indicate the audience this is written for. It then proceeds to briefly summarize the "Top SEO modules for Drupal", which includes SEO Tools, Facebook social plugins, Global Redirect, Metatag (booyah!), Page Title, Pathauto, Search 404, SEO Checklist, SEO UI, SEO Watcher, Sexy Bookmarks, TagClouds, XML Sitemap. So there's that. Once it finishes explaining what each of the modules is for it then goes into a brief summary of how to configure each module. And this is where I have a problem with the book.

One of the reasons I collaborate with the prolific Dave Reid on the Metatag module is that it covers most of the metadata that pages need, and you don't really need any other modules to handle this functionality. Specific things it is able to handle are the page title (the normal HTML "title" tag), the canonical URL tag, Open Graph tags (used with Facebook), Twitter Card tags (used with Twitter), Dublin Core tags, etc, along with some of the more basic "description" and "keywords" meta tags. Our idea is to have all of this functionality (and more over time) bundled together so it can be easily customized via one location, rather than having to go to one module's page to change the canonical tags, another for the page title, somewhere else for Open Graph, etc.

Why do I bring this up? Well, as with every other Drupal 7 -focused SEO article I've read, the book promotes using the Page Title module for handling the title tag even though the Metatag module has always let you customize the page title (even Dave's first code in early 2011 had it!) thus making the Page Title module completely redundant. Secondly, while Drupal core outputs a canonical URL tag on its own, with Metatag you can actually control what is output and override it per page (if you really need to), but the book discusses using GlobalRedirect module for this and not Metatag; yes, GlobalRedirect can help with other things, but you sure don't need it to add the canonical URL tag.

Another aspect that would have improved the book is a good explanation of what tokens are and how to use them as many of the SEO modules use them extensively. For the uninitiated, tokens are the small strings found in e.g. Metatag's fields on node edit pages that are wrapped in square brackets that get converted into something more useful when the page is displayed, e.g. [site:url] will output the main URL for the site, [node:title] shows the title of the current node page, etc, and it definitely would have helped to cover these in detail.

The rest of the content is fairly good, I'm just a bit disappointed at the inaccuracies in its coverage of modules. Between that and the book's length, this is a book I'd only recommend if you really are new to SEO best practices, and even then expect to need to do a lot of additional research.

My Rating: 

3
Average: 3 (1 vote)

Favorite?: 

No

Tags: 

Pages

Subscribe to Drupal