Drupal Site building 101
Most developers who have had the pleasure to work with Drupal know that there is a steep learning curve to get over first before you can really begin to love Drupal and flawlessly develop sites with it.
This learning curve is often visible to developers when beginning development on existing sites which have been passed on from less experienced developers, or when further developing a site which the developer has built as one of their first sites using Drupal. Because of the common pitfalls and beginner mistakes associated with the learning curve, the difference in coding standards and common practices (or lack thereof) can become very apparent in these situations.
This post will be part 1 of a 3 part series which will aim to address these issues and provide valuable development tips which will help you avoid these mistakes.
Always use relative paths
Sites often go through development, UAT and live stages, which means it is common for the site URL to change numerous times. Drupal is designed to understand relative paths such as /some-page as opposed to an absolute path such as mysite.co.uk/some-page. It is therefore important to always use relative paths as any absolute paths will break as soon as the base URL is changed, which would be the case if the sites domain name changes (which would be the case when pushing from development or UAT to live for example).
Link to pages using their node ID as opposed to their path alias
Path Auto is one of the must have modules for any new site build. It's job is to transform the default URL naming convention such as /node/12 into something user and search engine friendly such as /mens-clothing/shirts/white-cotton-long-sleeve.
The problem with these path aliases is that many new developers will often use them when creating links, and of course if anyone changes the path alias then these links quickly break. For this reason the default path should always be used - /node/12 - as this will never change.
A quick way to find this path is to hover your mouse of the edit link of the node and make note of the path which is displayed at the bottom of the browser window.
Learn and live by the Drupal folder structure
The Drupal site structure is built with extensibility and modularity in mind. It is also designed in a way that (if used correctly) makes upgrading Drupal a piece of cake.
The most important thing here is to only make changes within the sites folder, this way when you are updating to a newer Drupal core release, you can simply overwrite everything but the sites folder with the new core files, and not risk losing any valuable work.
Another common practice is to add contrib and custom sub-folders into sites/all/modules. This way you can separate any downloaded modules into sites/all/modules/contrib, and any custom built modules into sites/all/modules/custom. Drupal will not check the custom folder when it is looking for module updates, so developers can also move a contrib module to the custom folder if they have applied a patch or edited it for their own reasons and don't want it to get updated.
Understand the difference and when to use nodes, new content types, views and blocks
One of the trickier things to grasp as a beginner is understanding the best way to go about building a specific feature. Ideally we want to build features in the simplest way, keeping extensibility in mind so we can easily add or change features with minimal effort, and also keep it easy for end users to edit the content. After all Drupal is a CMS so we should be building with our clients in mind.
Here are a few things to consider when building with a mix of these:
- End users will be much happier working with elements which can be accessed and edited easy such as the Edit tab on a node, or the cog contextual link on a block. A view for example may be easier to be built as a block than a page, but then added to a basic page. The end-user should ideally not be editing the view, so at least this way they can edit other elements on the page. A basic page link can also be coded in terms of /node/x, unlike a views page link which can easily be changed, therefore creating broken links.
- Nodes, Views and Taxonomy terms can work together quite well, rather than making multiple content types such as Shirt, Hat, Belt and struggling with duplicate changes, you could easily have a single content such as clothing and add a clothing type taxonomy term to it.
- Nodes can have many different display styles, therefore you could have different display settings for the full node and the node teaser, which reduces the need for duplicate content.
Use modules which have been accepted and tested by the community
As of writing this there is currently 20,559 Drupal modules available to download. Due to the vast selection it is important to know what to look for when choosing a module.
Version – Does the module support your current version of Drupal?
Download/install count – How many other people use the module? If there are plenty of others using the module it will be much easier to find quality documentation and help on using the module. There will also be more people to help contribute to the module, submit patches, and even answer questions in the issue queue. A highly used module is also motivation for the contributors to keep the module up to date and well maintained.
Issue Queue – How many open issues does the module have? Does the module seem to be active in addressing issues? If the queue does not appear to be active, it will most likely mean your calls for help will unlikely be answered if you ever run into problems.
Maintenance and Development Status – This is a quick way to check the condition of the module. Ideally the module should be “Actively maintained” and “Under active development”, although "Bug fixes only" is usally fine if it is a mature module. If this is not the case you may wish to proceed with caution.
Recommended Releases – Is there a recommended release of the version you need? Other releases and Development Releases are usually available to download, but they are listed as that way for a reason, and are not guaranteed to be 100% working. Ideally developers should avoid sandbox modules at all costs unless they are using it as a basis or shortcut to writing their own module.
Avoid Spam from the start
Unfortunately we can't avoid spammers, but we can do our best to prevent it. At its very least spam can fill your site with unwanted comments and user registrations, but at its worse this rapid activity can substantially slow your site down or even crash it. Decide from the start who will sign up to your site and which content types you want users to comment on.
Under Admin > Configuration > People > Account Settings you can set who can register accounts. If you don't need registered users on your site then set this option to Administrators only, but if you need visitors to register and you set this option to Visitors, then be sure to add a spam filter to your user registration form.
Similarly, if you don't want people to comment on your content, disable the commenting feature on all your content types. Make sure you do this before you begin adding content as you may need to configure individual content if this is not set from the beginning.
Looking for a spam filter? Try Mollom (See the actual site here - www.mollom.com), it is free to use and provides a quality image captcha which can be added to individual content types and forms.
Install the must have modules
Once you have installed Drupal there is a few modules which every site should have. Personally I always install Views, Chaos tool suite, Pathauto, Token and Admin Menu. With the exception of Admin Menu, most developers will know about these modules already as the functionality they provide is necessary for most sites. Admin Menu on the other hand turns the default click-through Drupal menu into a drop-down menu which is a huge time saver, and makes the module a must have.
Use a feature rich base theme
Base themes generally fall into 3 categories, Adopt, Adapt and Annex.
Adopt – These themes improve Drupals core template markup to improve
Adapt – These themse adapt a framework to use within Drupal, such as 960 grid.
Annex – These themes tend to do everything, which can include adopting frameworks, extending them functionality, and adding additional support.
To understand more on base themes read Emma Jane Hogbins handout from DrupalCon Munich 2012
Base themes are important as they add plenty of additional features which greatly improve your sites appearance, and are a huge help when you begin to theme your site. Sasson is my current personal favourite which ships with the following useful features:
SASS – Includes a Sass compiler to allow you to use .scss stylesheets on top of .css.
Responsive – Includes an out of the box responsive base layout.
HTML5 – Converts the core theme templates to HTML5 markup.
CSS reset / Normalize - Includes normalize.css from HTML5 Boilerplate and Eric Meyer's CSS reset.
Know what changes to do before going live
When pushing a site live there is a few key points you need to remember:
Password Security - It is common practice to set the admin password to something basic on development sites, but when pushing a site live this password needs to be changed to something secure. Try StrongPasswordGenerator to auto-generate a secure password.
Performance – Once development is complete navigate to Admin > Configuration > Development > Performance and check the Aggregate and Cache fields. These features are turned off in the development environment to make live much easier for developers, but this comes at a cost as they slow the site down considerably. Once the site is live changing these options is the quickest way to improve the speed and performable of your site.
Status Report / Report Log – Check the status report and report log for any issues which you may have missed. Most of these issues will be quick to fix but if missed may cause many problems for your end users, and even worse can cause potential security problems.
Robots - If you are hosting a verison of your site on a test server - most commonly used to be able to show work to a client for approval - then you should prevent Google from indexing any of the pages by modifiying the robots.txt file to tell it not to crawl the site. When pushing the site live make sure you remove these changes so that Google can properly crawl your site again, and index its pages.
Use quality naming conventions
Lastly, remember that it is often the case that you may not be the first or last developer to work on a site, and for this reason it is considered good practice to use suitable naming conventions. This is important when creating views, blocks, menus or new content types, as the content will be named in a way that only the admin can see. Name content in a semantic way that would make logical sense to any other developer who may pick the site up, as developers can waste a lot of time browsing content which is unrelated to the task at hand, simply because the names have caused confusion.