Add new comment Your name
E-mail
Homepage
Subject
Comment *

More information about text formatsFiltered HTMLPlain text

Save
Category: Internet / TechTags: DrupalThemingDevelopment

This isn't so much a technical guide as it is a workflow overview. Sometimes the philosophic part of a website can be just as important as, or even more important than, the technical. So here is a collection of some things worth considering if you are developing sites with Drupal. This is more focused towards a designer or developer who builds and manages their own sites.

Separate Databases / Separate Files / Use Same Web Server
Installation / Prefixing

When it comes to each new website I always put them on their own install now. With Drupal it is possible to share things like nodes and users between multiple sites but this usually isn't as good of an idea as it sounds. Just because you can do something doesn't mean you should. Most sites are hardly tied together and most sites don't need to share data. So when it comes to setting up new sites I recommend putting them on their own install. You can put them all on the same database, but I would advise against sharing tables. I usually prefix each site accordingly. So site 1 would be site1_ and site two would be site2_ in the settings.php and so on. They can share the same database, but they don't share the same tables.

For my sites I have a Drupal database for each main version. So I have a drupal7 database that has each Drupal 7 site in that database prefixed accordingly. For some of my old Drupal 6 sites I have a drupal6 database that holds these sites. When Drupal 8 is rolled out I will have a drupal8 database for all these. This makes it easy to backup 1 big database versus lots of individual ones.

Custom Database Tables

Which brings me to my next point. I am also not a big fan of creating new tables for sites. Say you want to store some custom data for a module that you wrote? I really don't like the idea of having to install a new table simply to store the data. It is tricky because it is hard to make sure other sites that will be using this module stay up to date. What happens when you make a change on your table structure? Now you have to make it so all the sites with this table get updated too. The better approach, IMO, would be to have a table that works for ALL your domains.

So rather than having a custom table for each install, I would recommend having a global table that all the sites share. This could even be on a separate global DB. So I recommend having your individual core installation and then all your custom extensions handled on a separate "global" database. In your module you can simply switch to your global connection that you define in your settings.php. So your db query would be like:

<br>db_set_active('global');<br>db_select('custom_table', 'c')-&gt;fields('c')-&gt;condition('domain', 'domain.com')-&gt;condition('more', 'stuff')-&gt;execute();<br>db_set_active();<br>

Then all you need to do is add a column in your table to have some unique identifier like the domain name. This way every time you do a query you just check to make sure the domain matches the current domain they are on so that you know you are pulling the right data. This type of setup has made my life way easier than trying to have a separate custom table for each install. It's just not necessary in most cases.

Files

I also recommend having files separate. I usually have a separate folder that contains the files for each Drupal install. This one isn't as big of a deal, but I think from an organizational standpoint it is kind of weird to store everything in one folder. What if you want to move the site to another server? What happens if you want to move a site over to a CDN? Do you write a script to sort out all the files for that site? What happens if there are shared files? Do you just copy all the files over and deal with having extras? It's not a super big deal, but I just have had more problems in this scenario.

Web Server

As for the actual core Drupal files and web server itself I highly recommend sharing this. Sharing the core files and modules makes it very simple to update all your sites at once. Putting everything on the same web server doesn't really have any negatives. Everything is centralized and organized and it is much more simple to only have 1 directory with all your Drupal stuff.

If you do plan on having multiple servers then I would recommend using something like rSync to copy files from one Drupal web server to the other Drupal web server. This way you still only have 1 main web server to worry about and all the others are simply remote clients that receive their data from the main one. This is how I structure my servers and it works great. You can have an rSync script set up as a cron task or you can just run it manually whenever you want. Just make sure that you don't copy things over that you don't need to like individual site files.

Avoid lots of modules / Use core

I really think most modules should be avoided. There are really only a few modules that I could see being needed, where everything else just doesn't seem as necessary. The only 2 modules I really use on every site I have is pathauto/token and captcha. Most of the things you need are probably already handled in core. Obviously something like ecommerce will need a module and a few other things might, but for the most part you don't need many modules.

Another module that is fairly popular is views, but I don't use this one myself. I've found that views is something that needs to be set up for each site individually and is hard to scale quickly on multiple sites. Which brings me to my next point...

Have one global module that extends Drupal for all your sites

I have one main module that I use on every one of my websites. This way I know that anything I want on all my sites will always be there. I want forms to look a certain way on all my sites. So in that Global module I have custom CSS code that makes all my sites look a certain way. I want all my sites to track things like searches and page load times. So I have a global module that captures all this data and stores it centrally in one global database. If at any point there is something that I want all my sites to do I can easily roll it out to all my sites just by updating my main global module. I want all my sites to have a contact form that sends data to my CRM. So I have a global module that puts this page on a site by default. I have a privacy policy that I want on every site. My global module handles all this. I have certain spam checks I want on every site. My global module handles all this. You get the idea. Having one big module that handles all the custom stuff you want to have on all your sites is a good idea.

My global module is kinda like my mini-CMS that runs off Drupal. I have Drupal as my main CMS, but I have global.module as my own CMS for all the stuff that I want.

Share as many aspects as possible between sites

It is usually a good idea to share as much stuff as possible between sites. It takes a lot of time to customize things for each site and it usually isn't as important as we think. I have probably 3 or 4 main themes that I use between all my sites depending on the type of site it is. Corporate sites have a certain theme, community sites have a certain theme, and sales sites have a certain theme. I really don't need to have more themes than this. Within each theme there may be a few custom things I can do for each site, but this can all be done by changing a header background image for each site. That's really all that needs to be changed for each site. Each site has its own logo and a few other things, but other than that it doesn't need to be different. All sites probably should have a white background and blue links for text. There really isn't any reason to go crazy with theming.

If you look at all the top websites they almost all have very basic themes. Most of the top websites have things like, black or grey text, blue links, white backgrounds, very few images and not a lot of confusing stuff. They're simple and basic. So there really isn't that much of a need to make each site unique. The thing that should be unique should be the content, not as much the theme.

So I try to share as much stuff as possible between sites. I try to find as many things that all my sites should do the same and then I group all these similar things into core modules. Anything that needs to be unique for each site I make unique for each site. Anything that doesn't need to be unique is centralized.

Shift to core trends (images, fields, etc)

It is important to keep up with core trends and shift to these trends as possible. For Drupal 5 and Drupal 6 I had individual Image nodes that would handle my images. With Drupal 7 I have now finally made the shift to the fields API. I now upload images as a field rather than as an individual node. Since fields (CCK) are now a core part of Drupal it is a pretty safe bet to start framing your modules around this.

It's important to pay attention to where Drupal is heading and see how it will affect you into the future. The way you are doing things right now may not be the best way to do things into the future. There may come a point where you need to shift from doing something with modules to doing it with core. There may come a point where you need to shift from doing something with core to doing it with modules. But as often as possible I would recommend using core since you don't need to worry about sorting out all the bugs and problems. Which brings me to my next point...

Extend using core

Core is almost always going to be more dialed in than custom solutions -- so use core as much as possible. Sometimes you can save a week of coding just by using core instead. Drupal should be seen as a framework and should be used as that. If you have data chances are it can be stored through Drupal. You don't always have to use custom tables in a database to store data from a custom form. Why not just use a node? You don't always have to create custom fields in a table to collect data for customers. Why not just use fields? You don't always have to create custom tables to organize things. Why not create a new vocabulary and organize it with taxonomy? Many of the data and organizational things you need to do can already be done through core. I use nodes all the time to store data. I use taxonomy all the time to organize things. You don't always have to write something custom and mess with custom tables if you can do it with core.

Use blocks for a lot of stuff

Block come in really handy. I use them all the time for shared pieces between sites like contact forms and recent content pulls. But blocks can also be nice for individual site "hacks". Like say you want something to not show up on a certain site. Rather than write some 4 hour piece of code to allow certain options for each site it may be better just to throw some CSS in a block that hides a div on a certain page. Blocks are nice because they can show only on certain pages if you want. So if you want something to only happen on certain pages use a block.

Sometimes a block can also be your main content. For example, on a landing page you may not really have a lot of text content. Your landing page may be mostly an image or a form or something really graphical and custom like that. So rather than try to do this all with a node, I would recommend using a block. Just have a blank node or page, and then have a block that is your content. Make your landing page a block that only shows on your homepage, for example. Your main content may only be 500px wide and you may be limited by using a node or a page through a module. Your best bet would be having a part in your theme that allows you to use the full width of your page. This way you can then have a big header that takes up 900px of space and really uses the most space possible. Blocks are handy for stuff that you want to have happen on only specific pages. In many ways, blocks can be pages.

Sometimes quick custom code is better than pre-written excessive code

There are lots of modules out there. You can probably find a module for just about everything that you want done. But sometimes it may be better just to write your own code. Most modules almost always come with stuff you don't want and don't need. Most modules come with tons of options and many install tables in your database. A lot of modules also are hard to scale and update with. What happens if you want to now move to Drupal 8 but the module you are using isn't ready? You may only be using 1 feature out of the 20 features it does. Do you update the whole module yourself? The better thing to do may be just writing that 1 thing yourself, this way you don't have to drag around all the slop that you don't need.

It may just be me, but I just think most custom modules have waaaaaay too much stuff that isn't needed. Most modules have tons of options and settings that just aren't needed. I don't think most people care about settings. I think most people want a module that does exactly what it should do, is slim and is always up to date and working.

It also is a pain when modules have dependencies and need other modules to work. One module can quickly turn into 5 other modules that you don't need -- all for just 1 feature you want. I am very careful with new modules and usually avoid them if I can. Most of the stuff you need from a module can usually be done with 100 lines of code or less.

Keep it simple

With all this said, the underlying theme is keep is simple. The main thing people care about on a website is content. Focus your site around your content. You don't need 10,000 modules. You don't need some eye catching theme. What you need is eye catching content. What you need is eye catching value. Keep your network of websites easy to manage and easy to scale. Keep your network of websites doing what people want. Make sure your sites load fast and are always live. All the extra features can be decided once you have the basics done first.

These are my thoughts on Drupal and how I approach building my sites. Hopefully this helps a few people.

Headline: I've been using Drupal for around 5 years now and through those years I've developed certain ways I do things with it. I am writing this post to hopefully help a few people think about how to handle certain parts of their website.Image: