The following overview of key Drupal components should help describe what the build process looks like – and help create an understanding of what is custom and what is not. It will hopefully provide you with a clear background as to how we’d build out your specific deliverables.
From your perspective probably the most important component of Drupal are the content types. A content type might be a blog post, a product, a tour, a destination, a resort etc.
Out of the box, Drupal just comes with two content types, so adding relevant content types is part of the build process. This is not custom coding however. Rather content types represent most of your high-level data model – because we define the elements of data that each content type requires to do its job.
Every individual content record in your website is a node. So, if you create a page for ‘Man bites Dog’ using the News content type, the collection of data that makes that entry is a node.
managing migration from other CMS
In terms of data migration, if this is required from an existing CMS, the challenge is to export the records from your existing database into nodes within Drupal.
Migrating data requires a clear understanding of the existing and required data models at each end. If you are migrating to Drupal from a well known CMS it’s possible that there will be either modules or published work which either enable or strongly guide that process – which will help to simply the process.
In the case of proprietary, or less common CMS the challenge can be more complex. Your existing databases, because they pertain to your existing CMS will have fields and tables in them, which are not relevant. We’ll need to identify and ignore these. There will be relationships between various database tables, which don’t always need to be maintained, but which need to be understood to make migration work.
Because of how you may want to improve areas such as search, for example, its possible that we’ll want to format some of the data in a slightly different way to achieve this.
Finally, there’s the issue of data quality. It’s possible the existing content may contain in-line styles for example, which we may want strip out. Also how some of the data is encoded can also sometimes cause a few headaches, especially with diacritics.
Any images, documents or videos etc. that the sites use can be managed by a media module, with media then associated to nodes. If we are migrating content from an old CMS, when we transfer images from your existing sites we’d be pulling them into the media module. What can then be applied to that media, in terms of how we describe it, or how we might crop, optimize or resize images comes down to what other module based functionality we hook up to the media module.
Taxonomies are a means of building categorisations. Taxonomies are made up of vocabularies, so a taxonomy called Destinations might have vocab items like UK, USA, Poland etc. Taxonomies give us a means of being able to describe data so we can manage it, either manually, or to a set of rules.
As you’d expect, the menu structure allows you to create a browsable hierarchy and then assign content to that.
users, roles and permissions
Any user, from an unregistered potential customer all the way up to Super Admin has a role assigned to them by the system, against which permissions are associated. From a content management perspective configuring this is key to determining what kind of people can do what in the back end.
Drupal is made up of some core code (the key code Drupal considers all web apps require) and then some core modules, which can be turned off or on. Functionality is then extended, by using other contributed modules or custom modules. The next few paragraphs look at the distinctions.
Drupal’s core ships with some default modules – which, with the objective of keeping the core as lean as possible are those which are most likely going to be required by any use-case.
Other modules can then be downloaded and installed from drupal.org. These are called contributed modules. Before a contributed module is published on drupal.org it has to go through a fairly rigorous process of quality control, whereby its robustness will be interrogated by the Drupal community. Contributed modules have maintainers and for each, issues and bug queues are managed. If we find an issue with a contributed module we can patch it to fix it, but the challenge is to have that patch accepted by the maintainer as the fix, so that it becomes embedded in the next version of the module. This process is the key means by which the range of off the shelf functionalities available in Drupal via contributed modules are improved.
An example of a contributed module is the media module. It’s not part of core, because it’s not a given that every website uses media.
We’ll only look to ever create custom modules when the contributed route is exhausted. What’s key to remember here is that the better a developer knows Drupal, the more avenues s/he has to go down in order to exhaust that route, because they have a clearer idea of what it is they are looking for. There is a common saying in Drupal, which is, ‘There’s a module for that,’ and in many cases this bears true.
The decision to go with a custom approach on any feature is one that we’d explore with you, so you can assess the trade off between bespoke code and specific functionality.
When we evaluate the need for a custom module one of the first things we consider is whether it’s likely that anyone else might benefit from that, or whether its use case is obscure and unique. If there’s likely to be a benefit to others we’ll strongly encourage clients to allow us to contribute that back. There are three main advantages to doing this:-
- As the contributing client you get some kudos from doing this. It becomes a statement of your belief in the project and thus raises your profile with other Drupal developers and agencies. That could be of use in a situation where all the miggle developers get run over by the same bus and you need a new agency.
- The module is no longer custom, it’s contributed, so it’s part of the eco- system and is no longer bespoke functionality.
- To be accepted as a contributed module there’s an acceptance process.
The benefit of this is that it means the code we write is vetted, and improved if necessary, by other developers, which then strengthens the solution.
When we write any custom code we always do it by adhering to Drupal Coding Standards (https://drupal.org/coding-standards). In that respect, anything we write is done so in a way that is understood by the wider community.
How this process of managing modules works is something we see as being far in advance of how other open source content management systems embrace extended functionality and is a key advantage of using Drupal.
Theming is the process of making the site look good and the interface work well.
It’s essentially the process of taking designs, exporting them into code and then pulling that code into a theme.
Theming in Drupal is very much different to theming in WordPress, where in the latter you are tweaking your look and feel from a largely finished design. Drupal themes are more like a design framework in which you can achieve certain objectives, like responsive design for example.
Like modules, themes can be custom or core/contributed (or base as they are referred to from a theme perspective). We have experience of both approaches, but we tend to favour using base themes, because of the Business Continuity Planning (BCP) benefits they give. (Picture a bus, carving through the miggle developers like skittles... You now need someone who has experience of using the Omega theme (a popular base theme) – this is an easier and specific skill to go and find.)
That aside, with many of the base themes we use, we have slight issues with them and to this end we are working on an internal project at the moment which will see us contribute a custom theme we have been working on as a base theme, which is an approach we may recommend for you. (This is a good example of where our involvement in the community seeks to improve the overall platform.)
looking at the HTML/CSS with a view to making the site responsive
Even if designs don’t change that much, in general, when we rebuild an existing website in Drupal we’ll invariably change the front-end code (i.e. the HTML/CSS) especially if the sites need to be responsive, as is the case here. Doing an audit of the quality of that code would be something we’d do in our requirements validating stage.
what else makes up look and feel?
Theming in Drupal includes working with components such as templates, views, blocks and panels. A Drupal themer has to think about how each of these will be used and what is the editorial use case behind it. It’s not just a case of saying, that on the Offers page there are various areas for latest offers. Those offers may appear because a) they have been automatically syndicated to appear, b) they were editorially selected (with perhaps the call to action being written especially, c) in date, price order, or by user preference.
Also, offers may appear at different points on the page, or editors may want to alter where on a page they appear. Finally A/B testing requirements may mean different variants need to be created and run concurrently for testing.
Then there comes the issue of editorial resource. While you’ll want the vast bulk of content management tasks to be really easy to use, it’s unavoidable that some complex actions might involve a few more steps. Is this practical? Do the skills or time exist internally do to manage more complex, or infrequently used functionalities, or is there a requirement for additional support from your development team and where does the line fall? What does training and documentation look like? It’s unlikely you’ll want to give all staff access to do everything, so roles and responsibilities need to be defined.
Finally there’s a distinction between what is content, what is a new feature or functionality and what is part of the design fabric. i.e. you could change the background colour of a site, but should you be able to?
The answers to all of these points will determine to what extent we use a balance of blocks, panels, views and templates and how we architect the sites to support that. When we validate your requirements there will be a number of questions we will have around that, when we think about the types of content, where it comes from and how it is generated.
We’ll also look at the resources you have, discuss the practicalities of various models of workflow and identify what sort of training, support and documentation you’ll need, so that we can make that part of the overall development plan.
If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.