@todo - custom ds fields

D7 Production Techniques

Drupal is so flexible you could build every site in a different, but perfectly acceptable way. Unfortunately if we all ‘freestyle’ the approach to build it makes it very difficult to:

  • Share work around an agency
  • Support future work within the agency
  • Reduce time by reusing common components
  • Refine common QA issues

We therefore try and stick to some of the ‘tried and tested’ best practices.
There is nothing technically difficult outlined in this guide, but the first time you work with the items described here - you will need to follow it up by looking at some working examples, or asking a fellow production member to give you some assistance.

Core techniques

The approach to building sites ‘the NDP way’ will change over time, but the core approach will often consist of the following techniques. It is good to have a detailed understanding of what is possible using the following :

  • Drush
  • Starter template
  • Features
  • View modes and DS
  • Views and view modes
  • Display formatter modules
  • Path alias patterns
  • Ckeditor
  • Media module
  • Slideshows
  • Bootstrap
  • Field collection
  • Entity reference and ECK
  • Search
  • Redirect & Meta data
  • Data management

Drush

If you don’t already know about Drush it is important you make this the first thing you learn. Drush can do a lot of handy things via the terminal window that would take you much longer to do through the normal UI.
Find out more from the project page - https://github.com/drush-ops/drush
We commonly use Drush to:
Install new sites
Manage features
Download and install new modules
Clear caches, run cron
Work with Pantheon environments

Even if you are only using drush to clear caches and run cron it is a great time saver.

Features

Using features is essential for a stable ongoing production workflow where you need to move your DB configuration via code.
Working with a team, deploying to live sites and just generally as a tool - you shouldn’t ever work without it.
You should be comfortable packaging content types, views and other settings into features.
We provide some basic starter features, but your project will need to start its own set to manage views and content types.

Key considerations with features:

  • Namespace - your features are treated as modules - so always give them a prefix. We recommend it be the initials of the site. If you were building sitebuild.com - your features might be named ‘sb_feature’
  • Larger complex sites will often have features for each section - i.e. ‘sb_blog, sb_clients’
  • Simple sites might just need a feature for the functionality - i.e. ‘sb_views, sb_content_types

TIPS:

  • Start working with your features as soon as you start a project - don’t leave it until later otherwise it will take you longer
  • Update and test deploying your features often - it’s much harder to work out what was missing if you leave it too long or have too many items to test.

View Modes and Display Suite

Display Suite, view modes and field formatters are a powerful combination to achieve content layouts across a whole site that are easy to manage and update.

View modes

You can create new view modes for your entities to extend beyond the normal ‘default, teaser, search index’ view modes. We quite often add in ‘simple teaser’ or ‘grid teaser’ for example.

Display Suite (DS)

DS is an extremely powerful tool. Enable a basic DS layout on an entity view mode and you will be able to have much more control over the available fields. The most basic example is that on a standard teaser you can move the title below and image.

DS custom fields

You can extend DS and easily create custom display fields. You can use the UI based editor to do this, or preferably you can create a simple helper module and include your fields here. With a small, simple piece of training this can be a powerful helper.

TIPS

  • You should rarely need to create views that have lots of fields - where possible always use a content view mode
  • Map out your content view modes in your build plan - try to share as many as possible to keep things simple.

Views & View Modes

We try to avoid using view fields where possible. Most of your content listings will actually be using a standard approach to displaying content content across the site. If you keep the layout and styling of fields controlled via View Modes and DS - you only need to show the content display in a view.

Often you will find that you only need to show the ‘teaser’, ‘grid teaser’ or ‘simple teaser’ in your views. If you construct these layouts using views fields you will need to create and maintain these fields across multiple views - this can get time consuming and prone to error.
By using view modes in your views - you will be able to update multiple views just by editing the DS layout for the content being displayed.

Sometimes you will still need to use view fields, this is fine. We’re not against view fields… its just about being smart on when to use them.

Display Formatter Modules

Many people don’t realise that there are many powerful display formatter modules available. Often when you think you might need to hide a field and show it using a view, or start writing lots of theme over rides - there will be a display formatter that could come to your rescue. Anything from making any field a tokenised link, to displaying images as background css can be achieved.

Its worth looking at the following examples:

TIPS:

  • If you want to reduce reliance on views fields - you will need some of these display formatters

Path Alias Patterns and Menus

When you start a build it is essential to have an idea of what your path patterns need to be. It is essential that you ensure content is automatically generating the right path when created - this will be good for SEO, but it will also make breadcrumbs and menu trails work correctly.

A good example would be a blog article. If you blog section is located at www.site.com/blog - your blog nodes probably need to be saving with a path that looks something like - ‘blog/[node:title]’.

If you have a content type that is manually placed into the menu structure and can exist at any depth, you will want to use the default pattern supplied in the starter template - ‘[node:menu-link:parents:join-path]/[node:title]’ - this is very useful as it will build a path structure based on menu parents, or if there are none - it just uses the node title.

TIPS:

  • Start thinking about path patterns early - this way you are less likely to place blocks on wrong paths
  • Keep an eye out for active trails while you build. It can be harder to fix if you leave it until the end

Ckeditor

We use CKeditor via the WYSIWYG module for our sites. The editor will come with a default implementation in the start template - but it is essential you understand the configuration so that you can ensure the client has the best set of tools.

Some key considerations :

  • WYSIWYG profiles - these allow you to serve tailored version of CKeditor to different roles
  • If you add a new role - it will need to be assigned to a WYSIWYG profile
  • Toolbars for each role - think about the roles on the site you are building and consider which profiles they have access to. Do basic users get to add images for example.

Footnotes

If you're using the Footnotes module along with its sub-module Footnotes WYSIWYG then you'll need to make some alterations. You'll need to use the dev version of the module along with this patch - https://www.drupal.org/node/2025027#comment-9586869. You'll also need to make sure you're using the latest version of CKEditor (version as of writing, 4.6.2). The patch needs to be applied using "git apply" rather than a normal "patch -p1" since it has to create an image file.

TIPS:

  • Always remember to log in as your roles and test what they will see when using the editor - add images, links, styles etc in the test

Media

Use the media module for managing image and file uploads. If you need to serve YouTube or Vimeo embeds - also use the media module.

It is important that you understand how the media module displays files. Each file type is treated as a separate entity and has its own set of view modes and display settings. You can then reference these display settings when you place media fields on other entities.

An example might be :

  • Video embed - displays are ‘teaser’ and ‘full mode’. The teaser is set to show a thumbnail and the full display will show a large video player.
  • When you set this field on a content type - you would choose the ‘teaser’ view mode for you content teaser and the ‘full mode’ for your default node page.

Media popup

The media module allows users to reuse media they have added via a ‘library’ popup. We prefer to ensure this popup is used then selecting media for fields and inside the CKeditor.

TIPS:

  • If you add a media field - ALWAYS make sure you test its display straight away.
  • Dont forget you can create new view modes just for media entities - this gives you the flexibility to achieve most layouts

Slideshows

@todo - OWL in custom js
As most sites are responsive these days - we typically use owl carousel.
http://www.owlcarousel.owlgraphic.com/

We can use owl carousel via the following methods

The benefits of using owl carousel via the themes JS is that we don’t need to use a module. It also keeps configuration in code which is a bonus.

Bootstrap and responsive

If you are building a responsive site you need to think in terms of the responsive requirements.

We use a theme that is a child of the Bootstrap framework (http://getbootstrap.com), although many default theme elements will be taken care of, but you must ensure to consult the front end dev team to ensure you take the right approach when building your content displays.

Things to consider

  • Breakpoints - what breakpoints and grid are required
  • Regions - you need to plan template regions in advance, speak to the front end team, find out what they need
  • Listings and grid layouts - how will they respond, what containers would be needed

  • Complex build elements - how will they respond, will the front end team need additional wrapper, classes etc

    Field Collection

    The field collection module is useful when clients might need to add varying rows of information that do not require different fields.

https://www.drupal.org/project/field_collection

Entity Reference & ECK

If you need to build a slideshow, or an entity that doesn’t neccessarily need a ‘page’ of its own we highly recommend using the ECK module - https://www.drupal.org/project/eck

You can create a new entity type, create bundles and then add fields as necessary. The most common use case is when you have to build a homepage slideshow. In this scenario it makes sense to just create a new entity type of ‘slide’.

How do you then use these entities? If you need to create links between entities - we always use the entity reference module - https://www.drupal.org/project/entityreference

You can add an entity reference field and then choose to build a reference to any entity available - this includes the new ECK entities.

Also always consider using the inline entity form module - this allows the user to create and edit referenced entities from within the edit form they build the reference - https://www.drupal.org/project/inline_entity_form

TIPS:

  • Always consider using the inline entity form - it makes life so much easier for the user
  • Remember to try and use a view mode for displaying the entity as you would normally

Often you will be expected to build a more sophisticated search page than the Drupal default. In this situation you should disable the default search module and instead add the Search API modules.

When you use Search API you will also then need to add either the ‘Database’ server or ‘Apache Solr’ - decide in advance and ensure you consider any additional hosting requirements.

If using search api - you will often also be expected to product faceted filter blocks using the ‘facet api’ modules.

If you build a new search api index - you will then need to use views to create a search page, with an exposed filter serving as the search box.

TIPS:

  • Pay attention to the fields you add to a search index - not all fields need to be added
  • How big is the site and how much traffic is expected. You need to consider performance if the site is going to be large.

SEO - Redirect & Metadata

All sites will need a default minimum level of SEO consideration. You should always ensure that the site has the following items considered :

  • Metatags - ensure metatags is turned on and available to admin roles
  • Redirect - ensure redirect is turned on and available to admins
  • Global redirect - ensure it is is turned on
  • Google Analytics - be sure to enter the clients UA-xxxx code
  • XML sitemap - including and excluding node types.
  • Site map module.

Working with Data

Every site you build or work on deals with different levels of data. From passwords to user management. NDP has two guides for managing data

  • Data Protection & Information Security Guide
  • Data Protection Developer Policy

Please read through these guides to understand how we handle data. We generally share passwords using Lastpass and adhere to the individual data requirements per site.

It’s good practice to run the following command after downloading a database to work with: drush sql-sanitize

This will rewrite all of the user emails and passwords, by default to"user+[uid]@localhost" and "password" respectively.

results matching ""

    No results matching ""