Drupal Layout Builder

Drupal's new Layout Builder is without argument an exciting new capability allowing authors more flexibility in building pages.

With that said, the addition of this functionality creates a new issue that project managers, architects, and developers need to be aware - something which seems to me will result in more complex content migrations from other CMS's to Drupal, and from Drupal to other CMS's.

In the Drupal projects I have been involved in, when we needed to provide space for image banners, ad banners, embedded Marketing Automation forms, slideshows, etc., we would either add fields to Drupal nodes referencing the entities to include; or we might add fields to those entities referencing the nodes they should be displayed on.

From a logical viewpoint, one can argue that separating these things from the node is a good thing - that they aren't part of the content, so this provides better separation between content and display.

However, when you think about migrating content from another CMS to Drupal, or from Drupal to another CMS, you can see that the use of the Layout Builder makes these activities more complex.  In migrating content to Drupal, first you will have to determine which content should be stored as content in nodes, and which should be stored as items in page layouts, and then custom scripts will have to be built for the latter (I would expect that as this knowledge proliferates in the community, there will eventually be an effort to enhance the Migrate module to enable import of layout items, but that functionality does not exist today).  Similarly, if you decide to use the Layout Builder, keep in mind that if you want to minimize the risk of lock-in, this will make migrating from Drupal more complex.

Acquia - Lock-in Risk?

Just received an email from the Real Story Group warning followers about the risk of being locked into Acquia's web hosting services.  Here's a link to their web page containing similar content:

www.realstorygroup.com/Blog/2908-Be-wary-of-lock-in-with-Acquia

Here's the text I'd like to discuss:

Today, Acquia offers hosted products for:

• Search

• Behavioral personalization

• Multi-site management

• CDN

• And more on the way...

Note that unlike a standard Drupal module you could swap in or out, these products bind you to Acquia. There is no formal community around them, save your fellow customers.  With some exceptions you can only use them in conjunction with Acquia's own cloud service, based on its own distribution of Drupal.  In short, these products mimic offerings from a commercial software vendor.

Taking each one of these products individually:

Search - Acquia uses Apache Solr, a free, open-source product.  There's nothing keeping you from implementing Solr yourself.  No lock-in.

Behavioral personalization.  I believe Acquia provides this service separate from its hosting service.  So even if you moved your Drupal site to a new IaaS provider (or your own data center), you can continue using this service.  No lock-in.

Multi-site management.  This is a core Drupal capability.  If you take your Drupal implementation elsewhere, you can still implement multi-site management.  No lock-in.

CDN.  CDN services are incredibly easy to implement - and replace.  I see no lock-in here.

Maybe Acquia provides some service/services that actually do increase your risk of lock-in, but nothing on RSG's list seems to have any relevance here.

Drupal Overview for Tire Kickers

I frequently get asked by managers for my opinions about Drupal.  Rather than re-draft them every time I get a request, I'm posting some thoughts here.

Drupal strengths:

• It’s open source – anyone can access the code. If you don’t like the way something works, or you want to make an enhancement, you are free to do so. In other words, you aren’t dependent on a commercial vendor to approve your request and make the change for you.
    
• It’s a powerful platform. With enough effort, you can do just about anything you want to do.
    
• There are thousands of developers continually working on it and available to provide you with guidance and recommendations.
   
• If you want commercial support, you can get it.
   
• Some very large and/or well-known sites use it. For example, whitehouse.gov, Sony, Twitter's developer community, weather.com, etc.  Listly has an interesting list of sites using Drupal.
   
• Many many sites use it. As of this post, builtwith.com reports that, of the top 10,000 sites, about 20% are built on Drupal.

 Weaknesses:

• While there are a lot of Drupal developers, they are not cheap. Demand for their services is incredibly high.
• If you host your own site(s), know that major version upgrades (which happen about every 2 years), are not trivial. You can get by skipping a version, leaving you with a 4-year upgrade cycle.  While this will cut your upgrade costs in half, you should still be prepared for a lot of work for the upgrades you do. Note that you shouldn't skip more than one version - The Drupal community only supports the current and previous versions.  If you have an older version, you're on your own.  It will be interesting to see what Drupal hosting companies do in terms of migrating customer sites to the next major version. If they handle it, that’s a significant benefit of those services.
• If you host your own site(s), you cannot simply install Drupal and leave it alone. You need to employ (or contract) system administrators to manage your database (normally MySQL), your web server stack, PHP, and Drupal.  Each of these has periodic security fixes and version upgrades, and you shouldn't ignore them.
• For any site of any complexity, you can't install Drupal and simply let authors "have at it".  You should do a professional site design (preferrably by designers with experience with Drupal sites), and then you will need Drupal developers to select pre-existing community modules and develop custom modules to meet your requirements.  You will then either need to keep developers on staff or retain a consultancy for the inevitable on-going enhancements you want to make to your site(s).

Is Promotion the Elephant in the SEO Room?

I've listened to many SEO gurus' presentations on SEO over the years. There's always a lot of discussion about keywords, meta tags, url's, page titles, headings, javascript, etc. And usually the presenter mentions that Google puts more weight on the links to your pages (and the "quality" of the referring site) than on the factors you can control on your site. But after that short statement, they always quickly move on. Even Google only reserves two of 31 pages to this subject in its SEO Starter Guide (see pages 28 and 29).

So hold on - the most important factor always gets the least amount of air time? Why is that?

My guess is that the things you can control are many, they are somewhat technical, and so they make site owners feel they need the services of SEO gurus. At the same time, the "external factors" are few, easily understandable, and take a lot of time and effort to get right. And you can probably do a better job in this area than your consultants could anyway.

I'm not saying that keyword research, meta tagging, etc are not important - they are. But those are just table stakes. If you want to differentiate your site, you have to focus on the external factors, and spend the time and effort to get this area right.

So what is it you should be doing? Here is a list of possible activities:

• Find the most influential (i.e., highest ranking) sites that publish about the same subjects as you do on your site. If you make widgets, find out who publishes the most influential reviews of widgets, who posts educational content about widgets, who the biggest users are of widgets, etc.
  
• Review your content to ensure that it will be seen as having value to those influential sites.
• Build relationships with the influential sites' publishers. Show them who you are. Convince them of your authority in your shared market.
• Build out your online relationships with these publishers. In other words, you want them to understand that linking to content on your site will enhance their content. At the same time, if they have content that your site visitors would value, be sure to link to it.
• Use your relationships to find out what content they - and their visitors - want. If it's something that you can provide, and that will build your reputation or make people interested in you, develop that content - and let the publishers know when you have done so.

In other words - you have to promote your site - with the right crowd. If you can build your reputation as a valuable resource, and get influential sites to link to your content, you can optimize your search results rankings much more than you could by solely focusing on your internal factors.

Here's a good article on this subject: http://sites.google.com/site/howtoseo/seo-3-external-ranking-factors.

How a Web Design Goes Straight to Hell

Lately I've received several requests for web site changes that don't make sense, either for our web site visitors or for us. The latest request reminded me of a comic I read a long time ago. It was a great comic, so I spent some time searching for it. I'm sure I'll want to reference it some day, so this post is to make sure I can easily find it again. And you may get a kick out of it.

http://theoatmeal.com/comics/design_hell

converting text to numbers in Excel

I found a helpful trick in Microsoft's Excel help for converting text to numbers in a range of cells. Thought I'd pass it along.

1. Enter any number in a cell.
2. Copy it (Ctl-C).
3. Select the range that you want converted to numbers.
4. Select the menu options Edit, Paste Special.
5. Select "multiply" on the pop-up form.
6. The range you selected should now contain numbers, not text.
   

It's in Microsoft's help, but who looks there?

Drupal - Better way to translate blocks

There are custom blocks on a site I manage that contain simple English text. We just started a push to add Spanish to the site. So I researched how to make blocks multilingual. The documentation I found mentioned 2 ways to do this: 1) use Drupal's string translation to translate whole blocks into different languages, or 2) create separate blocks for each language and enable them only for the nodes in the associated language.

I wasn't happy with either of these options. I don't want my contributors creating and maintaining string translations, and neither do I want them editing blocks.

Meanwhile, content (node) translation in Drupal is elegantly implemented. To translate a node, you go to the node and create a translated version. The translated versions are then always tied to each other. With this my contributors can create English and Spanish content easily.

Happily, I found another - and I think better - way to do this with the "node as block" module. I don't think this module was developed with multilingual content management as a prime driver, and I don't see much discussion about this valuable use.

There are a couple of quirks you have to know about. One, by default the block only displays a subset of the content of your node, so you have to include the "<!--break-->" tag to make sure all preceding content is displayed (if you know a way around this, let me know!). Two, when you translate a node, you have to make sure to specify with the translation that you want a block created (even if you've done so with the original node). And yes, this means you'll end up with 2 blocks.

Even with these quirks, this is going to be a much better way for my contributors to edit content in multilingual blocks.

Note that there are several other seemingly similar modules that I haven't researched, including "nodes in block" and "node blocks". If you've found that these or other modules serve this purpose better, let me know!