Drupal

Verify your Drupal Site!

To use most of the major search engines tools and apps with your website (Google Webmaster Tools, Bing Webmaster Tools (which also works with Yahoo! search), Google for Work, others) first you must verify you own the domain.  This can be done in several ways - updating some settings with your domain registrar, uploading a specific file to the root of your website, and setting a specific meta field on the front page of your website are the most common.  The Drupal Site Verification module can help you quickly verify your site using the latter two methods.  Install it first in your preferred manner.

We will look at verifying your site Google Webmaster Tools.  First log in using your Google account.  Next click on the orange ADD A SITE button on the upper right.  You should see this.

Add a site dialog box on Google Webmaster Tools

Enter your sitename and click Continue.  At this point, you might see one of few different screens, depending on what Google thinks is the Recommended option for you to verify your site.  If the HTML file upload method isn't under Recommended method, then click on Alternate methods.

Google Webmaster Tools Recommended method to verify site ownership

To use this method, first click on the link to this HTML verfification file to download it.  Then in another browser tab, we will use the Drupal Site Verification module you installed earlier to upload it to your site.  Navigate to admin/config/search/verifications. Then click on the +Add Verification link.  Select Google from the drop-down list, then click on Next

Drupal Site Verification module configuration screen

You can upload the verification file Google gave you here.  If you chose the META tag option, you can cut and paste it from the Google page to the field here.  Click Save.  Go back to your Google Webmaster Tools tab and click on the red VERIFY button.  It should give you a confirmation screen.

That's it!  You are verified and have the Seal of Approval!  I'll bet you were wondering what the seal cover image had to do with site verification. We're funny, that's what!  Kinda funny anyway.

Drupageddon: Aftermath

By now you've heard about the Drupal core vulnerability commonly referred to as Drupageddon. Let's look at some common questions.

How Bad Was It?

The Drupal community freaked out. Actually, the Internet community freaked out. Was the freakout justified? Unfortunately, the answer is yes. The vulnerability allows anonymous users potentially unfettered access to PHP and the site database and as soon as the Drupal Security Team announced it, the world knew about it. Within seven hours of the announcement, there were already reports of automated attacks.

There was a report that "at least 12 million" sites had been compromised, but the report based this number on bad assumptions, so you should ignore it, much in the way you should ignore numbers in advertisements qualified with "up to" or "results not typical".

What Was It?

Essentially, the vulnerability allowed savvy site visitors to perform arbitrary operations on the site database. There is an excellent post explaining what the issue was if you're interested in the technical details. Once an attacker gained a foothold in the database, then that opened the door to executing arbitrary PHP code and from there, your world was his (or her) oyster.

Has It Been Fixed?

Yes, Drupal 7.32, released in conjunction with the security announcement, fixed it. Update your Drupal core to that version, or at least apply this patch.

Can I Tell If My Site Has or Hasn't Been Compromised?

You can check for some of the known attack patterns to prove that your site has been compromised, but unfortunately, you cannot prove that your site was not compromised. Attacks could have done their dirty work and then left no trace. They could have left a backdoor that didn't follow any of the known attack patterns. As with many things, it's difficult to prove a negative.

What Is The Safest Thing To Do?

The Drupal Security Team released a frightening (and accurate) PSA that recommended rebuilding your server and restoring your site (code, files and database) from a backup made before October 15. Yes, that means what you think it means.

Do I Really Have To Rebuild Everything?

Per the Drupal Security Team, that's the safest thing to do. You don't have to do it, you merely assume more risk if you don't. Fortunately, there are also some potentially mitigating circumstances. If you host your site with one of the big Drupal-centric hosts, then your risk could be reduced if your host rolled out protections along with the security announcement. Both Acquia and Pantheon posted they had done this. Other hosts may have implemented protective measures as well, but the less Drupal-centric your host, the less likely that would be.

You can also check for some of the known attack patterns. While their absence doesn't mean that your site has not been compromised, it could affect your decision with regard to the risk you are taking by not rebuilding.

  • If your source code is under version control (like git), check to see if your codebase has been modified or if there are new files that have been added.
  • Check your uploaded files (which are normally not under source control) to see if there are any PHP files.
  • If you don't have your source under version control, you can still check for any PHP files (not just in the uploaded files, but everywhere). Be aware that there are plenty of legitimate reasons for a PHP file to exist in your codebase, so don't delete indiscriminately.
  • If you have access to your database, either through the command line or a UI, check the menu_router table for suspicious callback values, like file_put_contents, php_eval, or assert.
  • Look for any suspicious users, especially ones with the administrator role.
  • Look for blocks or fields using the PHP Code text format. Inspect them for suspicious content.

It is likely that more patterns will emerge, so keep an eye on your favorite Drupal blogs for updates.

Want more options? Here's a flowchart detailing how you can evaluate your site along with some recommended actions.

Setting up an XML Sitemap in Drupal

Google and the other search engine crawlers do a decent job of finding their way around your website. But, sometimes they could use a little help, as well as to understand the relative importance of your web pages and how often they are updated.

This can be done with an XML Sitemap.  And of course, there is a very popular Drupal contrib module for it - aptly named, XML Sitemap. Installation is easy, but you will need to configure a few things before it starts doing its magic.  We will look at the Drupal 7 version.  And as always, it's good to have a site and database backup before you start.  We are using the currently released version- 7.20.

So, after installing the module in one of the usual ways, a new section in /admin/modules will appear - navigate down toward the bottom :

Enable XML sitemapXML sitemap engines, and XML sitemap node (as shown above).  And Save.

Now we need to prepare our content to be added to our XML sitemap.  Edit the structure of each content type you want added to the sitemap (such as a Basic page - admin/structure/types/manage/page), then click on the XML Sitemap vertical tab near the bottom left.  Then under Inclusion, select Included.  For most pages you can leave the default priority as is, or change it for frequently or infrequently updated pages.  Then click Save.  Do the same for any other Content Types you wish to include.

Drupal configuration screen to include content in an XML Sitemap

When the XML sitemap module was first installed, it will have created a default (but empty) XML sitemap.  Next we need to rebuild it so it will pick up all the new pages we configured the Content Types to include.  Navigate to /admin/config/search/xmlsitemap

Click on the Rebuild Links tab, then when it changes, click on the Rebuild sitemap button (even though it may tell you that you don't need to).  When done, you should see some numbers shown under Links and Pages.  See if this is about right for your site.  You can view more details on pages in your sitemap and priorities under the Settings tab.

The only thing left to do is tell it to submit your new sitemap to the search engines.  Click on Search Engines and check Google and Bing.  Save.  Done!  Wait a day and check on your Google Webmaster Tools account that it is receiving your XML Sitemap.  You don't use Webmaster Tools !?  You should!  It's free and packed full of information from Google on how your site works with its search.  Look for an article here soon on how and why.  You'll notice the module also suggests you verify your site using the Site Verification module.  Good advice!  We'll cover that soon too, although it's fairly easy to use.

North Texas Drupal October Meetup

We had yet another great meeting of the nascent North Texas Drupal users group this past October 20th.

Travis Tidwell asked the question- When Should You *Not* Use Drupal?  While we all love and user Drupal, it is not always the best tool for the job.  Check out his slides below for more info as well as some notes and related links.

Ian Whitcomb took us through building multi-site Drupal, including solutions such as MultisiteDomain AccessOrganic Groups and andPantheon One.

We also had a discssion of Drupal security, including the recent major core exploit.   Here is a way to see if your site was compromised using a drush command.  

Blog article about presentation with Video and Slides

http://travistidwell.com/blog/2014/10/20/when-to-not-use-drupal/­

Static Site Generators

Bootstrapping your site

"API-first" Development

  • Drupal 8 with Symfony is a solid contender
  • Recommend to start simple with Symfony and bring in Drupal if requirements need it.
  • Other API-first platforms

Twitter Issues On Pantheon?

Having trouble getting your Twitter feed working on Pantheon? Does it work locally but not in your Pantheon environments? If your Twitter solution uses PHP's http_build_query function (as does the Rise theme's front page), you're not going crazy. It's them, not you.

The http_build_query function takes an array and returns a URL encoded query string suitable for use by functions that might find query strings handy, like PHP's curl functions. By default, PHP uses the & character to separate query string parameters, but on Pantheon, this value is set to use the HTML entity & instead. If you try to pass a query string with & instead of &, it will fail.

Fortunately, you can override this value using  the third paramter of the call to http_build_query. For example,

http_build_query($my_params, '', '&');

But what if the call is in somebody else's code and you don't want to hack it and cause kitten-death? Well, there is still a potential solution. If you are not relying on the & output from http_build_query elsewhere on your site, you can globally override Pantheon's value with a setting in your site's settings.php file :

ini_set('arg_separator.output', '&');

That's it. No Twitter token regenerating, no hacking, no hair pulling. Just a one line fix.

North Texas Drupal Users Group - Sept meetup

Great meetup of the North Texas Drupal Users Group last night.  The new Addison Treehouse cowork / incubator space was good enough to host us.

First off Kyle Taylor showed off his efforts in integrating the (becoming standard) Bootstrap theme with the core Color module and LESS.  The lead Bootstrap maintainer, Mark Carver, is one of our members and was in house to answer deep Bootstrap questions.

Then Randall Knutson did a presentation on Static Drupal – Taking the Pain out of Drupal Hosting.  It's based on some work he's doing at Phase2, to improve the load times and security of Drupal sites. You can learn more from his blog post and download the Static module on drupal.org.

We're working on the what and where for the October meetup - stay tuned!

HTTPS is now a Google Ranking Factor

You may have noticed that when you use your web browser to do online banking or shopping, and it generally switches to HTTPS / SSL mode (with the little lock graphic) for added security.  Looks like Google wants to make that the standard for everyone soon. According to the Official Google Webmaster Central Blog

"Over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We've seen positive results, so we're starting to use HTTPS as a ranking signal."

When HTTPS mode is enabled, all traffic is encrypted between your computer and the web server. Which is generally a good thing, but does add a small performance penalty for the time it takes to encrypt and decrypt all the traffic.  Often this is done on non-ecommerce Drupal websites just for the user login and user editing pages, as most content is really not that security sensitive.  But with this announcement from Google, it's time to start thinking about switching your entire site over to HTTPS.

So, how to do that in Drupal? The complete process is too complex for the scope of this blog post, and you will need to make changes on both the webserver and the Drupal sides.  On the server side, you will need to install an X.509 SSL certificate and make some configuration changes. Many web hosts will greatly help with that process, including our hosting partner, Pantheon. On the Drupal side, the easiest way to enable HTTPS mode is by using the Secure Pages module.

Screenshot of Drupal Secure Pages module configuration

The Secure Pages module will not let you engage secure mode until the server is correctly configured to use SSL.  To best comply with the Google initiative, you should select Make every page secure .. and delete all the pages listed in the Pages box, so that every page runs in HTTPS.

Ironically, that Google blog post (and the entire website) is not running in HTTPS mode.

Google And Drupal : Alt and Title Tags for Images

Generally when you see an image on a webpage, the <img> HTML tag is being used on that web page to instruct the browser which image file to display and how.  The code looks like a little something like this (from this very page):
 
<img src="http://fireroaddigital.com/sites/default/files/frd-blog-alt-title-tags.jpg" alt="Squirrel using a video camera">
 
Simple enough, but what’s that alt tag?  
 
The alt attribute is used to help search engines and assistive technology such as screen readers for the visually impaired to understand the image.  Googlebots are getting smarter and smarter, but may not yet know that image is of a 1940’s film camera being operated by a 1940’s squirrel. Or that it might be an Australian spotted flying squirrel.  Or maybe it’s a muskrat.  I’m a human and I can’t even really tell what it is.
 
Sites like Google Images use this alt data to help categorize their collections of images, and the use of alt tags across your site is known to be one of the many Google search engine ranking factors.  So, not only is the use of the alt tag required to achieve HTML conformance, it’s good for SEO.
 
So how do we enable it on our Drupal sites?  Easily, of course.  First we make sure our Drupal site is providing a place for a content editor to enter the alt text for all images and that the resulting text is included in the resulting HTML code.
 
For an example, let’s look at the default Drupal content type Article. Navigate on your admin menu to Structure >> Content types, then under Article, click on manage fields.  If you haven't changed the default Article content type, it should look like this:
 
Figure 1- Screen shot showing Article content type fields

Figure 1: Article content type

The Article content type comes with an Image field by default.  You can also add an Image field to any new content types that you create. Click on edit under Image. Scroll down about halfway until you see this.

Figure 2- Screen shot showing how to enable the Alt tag on the Drupal Article content type

Figure 2 - Enable Alt Field on Article content type

On the Article content type, the Enable Alt field checkbox should already be checked- comes that way by default.  But it won't when you add an Image field to a new content type you created. You will need to check that box.  And notice the Enable Title field checkbox?  Go ahead and check it too - we will talk about it shortly.

So then how do you enter Alt text for images?  Let's create a new Article and find out.  Navigate to Content >> Add Content >> Article.  Enter title & body content.  Scroll down to the Image section.

Figure 3 - Screen shot showing adding an Image to an Article

Figure 3 - Adding an Image to an Article

Choose a file and upload it. I've chosen a picture of four lovely donkeys standing in field.  It's also generally a good idea to name the field descriptively (and use keywords related to your content if applicable).

Figure 4 - Screen shot showing Added Image

Figure 4 - Added Image

Save the node and you are done!  The alt text will show up in your page HTML code.

A few more loose ends though:

  • what about all those little design-element images throughout your website- do they need alt text?
  • what about inline images I add to a page using the WYSIWYG editor- how do I add alt text to them?
  • what about that title attribute you said you'd talk about later?

Ahh good- you've been paying attention.  Let's start with the first one.  You probably have small graphics, lines, shadows etc. all over your website, sprucing up the design.  The W3C standards say that for images that have no semantic meaning to the viewer, you can set the alt tag to null.  ".. if the alt text is set to null (i.e. alt="") it indicates to assistive technology that the image can be safely ignored."

For inline images (like all screenshots I've included in this post) - your Drupal WYSIWYG editor should have a way to enter the alt text.  We use CKEditor on this site, which looks like this while inserting an image. Other editors work similarly.

Figure 5- Screen shot showing setting the title tag for inline images using CKEditor

Figure 5 - Setting the alt tag for inline images using CKEditor

And finally, the title tag.  It tells the browser what to display as a tooltip when the viewer hovers his cursor over the image.  It is generally more useful when the image serves as a link, either to a larger version of itself or to another webpage.  The best practice then is to put a description of what will happen when the user clicks on the image.  It is generally not thought by the community to have any search engine ranking value.  But it is a good practice to follow for good user interaction, which may indirectly lead to better conversions.

If you check the Enable title field checkbox on the Image field in the content type, it will add an additional field under alt for you to enter title text for images.  In CKEditor, the title text can be entered under Advisory Title on the Advanced tab.  

Pages