Drupal Site Building Guide

(1)

Drupal Site Building Guide

Version 1.0

1st Aug 2012

Disclaimer for the Market / Agency

The market / agency can go through the details of the guidelines and recommendations required for your Drupal website to be hosted in the shared environment. Obviously, given the nature of a shared environment, there will be certain constraints and rules (though minimal) to be followed for your website. If in case you believe these constraints are an obstacle to your website, you can opt for a virtual machine and take full ownershop of the machine and host your website there. To make it easy for you, the constraints and advantages are captured in a separate section at the end of the document.

Author Gopala Krishnan S

Current status Published

(2)

Document control

Document Owner Gopala Krishnan S

Document Type Guidelines & Standards

Review Cycle in months Next Review Date

Table 1: Document Owner and Review Cycle

Date of

version Version Authors

Changed made (section number and description) Also indicate the related PLC number or Nestool

Work Request (DEVWR, DEVCR)

Status

Table 2: List of Versions

Review Name – Entity - Function Date

(3)

1 Introduction

1.1 Intended Audience

This document is intended for the following audience

DSU SD Team To understand the overall Drupal website building best practices and guidelines

Web Agencies To adopt and follow the Nestle recommended standards when building websites with Drupal

1.2 Scope

This document contains the Nestle standard & recommended coding standards and conventions that the agencies are required to adopt.

1.3 Nestlé Standards

For easier readability, Nestlé standards are outlined by special bullet points and a yellow border on the left side of each standard.

Examples:



Nestlé Standard. Detailed/Additional Description.

(5)

2 Best Practices

Building an enterprise-level Web site is like preparing for the courtroom: All of your efforts are tested upon launch, and you have no second chance to make a first impression. While site builders have the advantage of a “beta” period — and opportunities for refinements over a long run — eventually every public-facing Web site has to face a trial by audience. Effective preparation involves examination of two areas: business goals and technical assets, which we will cover later in the document.

There are 4 key things that you need to remember, when actually starting to build the website

Plan your site. Drupal provides a good toolset to help you build your site but you still need to plan. Good wireframes

and proper planning can avoid significant misunderstandings and problems later.

Plan for the future. You should revisit and reevaluate your site each time there is a major version release of Drupal.

This does not mean you have to upgrade it, but you should evaluate and plan for an upgrade approximately each 12-24 months.

Get involved in the community. This will help you follow development trends and, while helping others, you may just

come across a cool idea that solves your own problem.

Back up your site. Back up both the database and the files on the web server. Test your backups! If you don't test

them, you have no idea if you are doing it right.

Test your PHP snippets. Drupal gives you a great deal of power and flexibility when using PHP code in blocks.

Unfortunately, a stray character or a missing semi-colon breaks PHP. Drupal then attempts to evaluate this broken code on any requested page, the PHP interpreter chokes on it and therefore your whole site is broken. Fortunately, there is a very simple and easy solution. Instead of writing and testing your code inside the administer > blocks page, go to create content and create a new story or page node. Use PHP input format, write the code, and the Preview to debug your code. When you are satisfied that your code is working, copy and paste the code into the block.

Generic Drupal Best Practices



Back up your site files and database



Never Hack Drupal Core



Avoid HardCoding



Avoid Too Many Modules



Make your website accessible - http://drupal.org/node/394094



Bundle Site Settings using Features - http://drupal.org/documentation/modules/features

Tools

• Use SVN / CVS for Version Control in your development environment • Eclipse / Adobe Dreamweaver for Development

(6)

3 Strategy & Tactics

The below diagram illustrates the lifecycle of building a Drupal Site, or in fact any website in general. It is highly recommended to follow this lifecycle process in order keep your website alive and always meeting customer expectations

The lifecycle represented above defines a complete strategy for building a Drupal website. However, strategy without tactics tends to fail quickly. So, in alignment with the strategy, the following tactics are recommended to take a site from concept to a living entity.

1. Data Organization

2. Module Selection and Organization to augment Drupal’s core

3. Site Presentation, as realized through theme development and UI Testing

Let us take an example of a photo gallery. Often a client will have a huge collection of existing graphics, gathered over a period of years. They may be of different sizes and resolutions, unlabeled, and ungrouped. How could Drupal turn that collection into a coherent whole?

(7)

The first tactic — DATA ORGANIZATION — means determining how those photos will be grouped. In Drupal, one way of grouping such items is by content type: For example, product photos might be put into a “Catalog item" content type, and augmented with fields such as price, quantity, and available colors. Meanwhile, staff headshots might go into a “Personnel" content type, with fields that provide their subjects’ department and contact information.

Another way to group those photos could be by “tagging" them with descriptive data, in structures that Drupal calls taxonomies. So a photograph of someone at a party could be tagged with the subject’s name, the party’s location and date, the

photographer’s name, or any other data that serve your goal. Often, the hard part is in determining what those groups of tags, called “vocabularies", should be. One usually needs to revisit how your taxonomies are set up after a site has been launched demonstrating, once again, the value of the methodology’s cyclical nature.

The need to turn data into visual information brings us to our second track – MODULE SELECTION & CONFIGURATION.

The lightweight solution shown here uses the Image module, which includes an add-on that automatically creates galleries. This solution is simple, but not appropriate for all situations. Another possibility ould be to use Content Construction Kit (CCK) and FileField to add fields to our content type, ImageAPI and ImageCache to import and resize graphics on the fly, and possibly a dedicated photo-display module such as Lightbox to make the galleries more interactive. As always, part of the challenge is choosing from several possibilities to find the one that’s right for your needs — a process that benefits tremendously from experience. The job isn’t complete — some photos still need to be “tagged" with a descriptive title, for example — but the process is well underway.

Finally, we come to our third track: SITE PRESENTATION. This is where the earlier work to create site maps and wireframes comes to fruition. Programmatically, the wireframe is converted to a Drupal theme. A theme is a collection of PHP, HTML, and CSS code. Themes are sets of user interface designs. The site map becomes our template for the menuing system, so the site flows in a way that will be obvious and easy to visitors.

(8)

4 Think, Plan, Build

4.1 Think

You need to know what your site should do before you can build it quickly and efficiently. It is recommended to start with a list of ideas and needs and then turn into “wireframes”–simple graphic mockups of the main pages of your website.

Seeing the pages laid out helps keep track of the details. However you do it, you’ll need to list all of the pages of your site and what you need on them. Group them into main and sub-pages to get a feeling for what your site navigation will need to look like.

For this document, let us take an example ice cream parlour website, as adopted by Acquia, the official sponsor of Drupal. Below is an example layout of the website.

4.2 Plan

Apply the Source Interaction Display “formula” to every element on every page of your site: Ask yourself the following questions:

Source:

Where does this come from? Some combination of user roles, permissions and module configuration usually answers these questions. A site administrator? A contributor? An automated feed A module Site visitors? Interaction:

Who interacts with this and how? These questions are very similar to the previous set (source) and can usually also be answered with a different combination of user roles, permissions and module configuration.

Who can see it? Who can change it? Who can add to it?

(9)

Display:

Where and how is this displayed? The answers to these questions lie in the configuration of blocks, selection and presentation of content in views, menu- and module configuration, and so on. Just to be clear, “display” means the functional aspects of your site like pages and block regions, not “200 pixels wide and blue”–setting the look and appearance of your site is called “theming” in Drupal.

Where on the page does this appear

Is it in a block? In which region and on which pages Is it a link? Is it a menu item?

Is it a teaser or a full node?

With more and more experience building sites, this formula should become second nature and make you feel confident you are covering all the relevant aspects of each page element on your site.

4.3 Build

Let’s look at wireframes and run through the practical application of Source-Interaction-Display on part of my overall site plan. As you go through the Source–Interaction–Display process on your own sites, you’ll start hitting more and more elements you’ve already covered. This should give you some peace of mind that you are covering all the bases.

(10)

This shows the main menu and how sub menus will look like.

4.4 Content Types & Choices

The really important part of the ice cream products page (see below) is the list of flavours. It is the result of two choices you need to understand to really be able to leverage Drupal’s power and flexibility:

1. When should I make new content types and why? 2. When should I make static versus dynamic pages?

(11)

4.4.1 Making Content Types Work

When should you create and use new content types? There are two strategies when planning a site: organization and access.

The organization strategy – Making content types that fit your data helps in collecting, organizing and presenting it. You could

use a simple content type like “Basic page”–which is only a title, and a body text–for everything on your site, but it’s like throwing a bunch of colored toy blocks into an open box:

The information might all be there, but it’s hard to sort the products from the staff members from anything else. If you tag your content, you can at least leverage Drupal to show things tagged “product” on one page, but it won’t be sortable.

One product might be described one way and another completely differently. You’ll lose sales if it’s difficult for visitors to sort and compare your products.

Custom-tailoring (new) content types by adding numerical, text or other fields to them means no matter who adds new products on your site, it will be done in a standardized format. This also lets you take advantage of views to make dynamic, sortable products pages, while still only having to enter each product a single time. Example: The “Ice cream” custom content type on my site includes a name and text body plus fields like: short description (text field), calories per serving (numerical field); photo (image field); popularity; ingredients list; allergens list; etc.

The access strategy – Limit content contributors’ access to only creating and changing content of one or more specific

content types. Site administrators retain full access to the back end, but restrict non-technical users, improving security and reducing administrative headaches. Example:

Three groups of users need to add and change content on a school website: the school administration, the PTA, and the after school program.

Make a user role for each

Make two simple content types (title and body text only), “PTA page” and “After School page”, along with anything else you need.

PTA and After School are only assigned permissions to create, edit and delete pages of their own content types. School administration users are permitted to create, edit and delete all content and blocks on the site.

4.4.2 Static and Dynamic

Understanding what static and dynamic pages (and blocks) are and when you should use each can help you plan and run your site.

Static pages and blocks - There are a few pages or blocks on most sites that don’t change much–like the welcome text on

my ice cream parlor’s front page. The Drupal “Basic page” content type is perfect for pages like this. Add menu links to the main or sub-menus where visitors should find them and you’re good to go.

A custom block is a great way to present short, important information–like the store hours block on the site.

Dynamic pages and blocks – Building and maintaining complex pages by hand is laborious. You should let Drupal assemble

them for you. As your site grows and changes, those pages change for you automatically. Some of these dynamic pages and blocks come with Drupal and its modules:

The Blog module lists all blog posts, newest first. If you have two blog authors, there’ll also be two other pages, each with a single author’s entries.

Drupal can display a page of all site content tagged with any given taxonomy term.

(12)

5 Website Functionalities

All best practices and guidelines to build the website functionalities can be found in the Drupal Official Documentation This gives a comprehensive receipe of different types of websites and its respective tutorials.

• Website Structure Guide - http://drupal.org/documentation/structure • Site Building Guide - http://drupal.org/documentation/build

o Building Your Website’s Functionalities - http://drupal.org/node/1241116 o Finding and Selecting Contributed Modules - http://drupal.org/node/340271 • Developing Modules - http://drupal.org/developing/modules

• Drupal Coding Standards - http://drupal.org/coding-standards • Multi Lingual Guide - http://drupal.org/documentation/multilingual • Theming Guide - http://drupal.org/documentation/theme

(13)

6 Working with Modules

Modules provide functionality beyond the Drupal “Core.” It is the underlying philosophy of the Drupal CMS that any installation will contain a variety of these modules to provide services beyond the basic items built-into the CMS. The main issue when selecting these modules is that they are maintained by individuals often with no real development plan. They may break, be withdrawn or be incompatible with future versions of the Drupal core. Even so, you must be sure to check the Drupal module availability prior to developing custom code.

6.1 Choosing Modules

There are thousands of Drupal modules available and it is hard to know which modules suit best for your website. You do not want too many modules installed. It will slow down your site.

http://drupal.org/project/Modules

When choosing a module, look at the releases. The more often and more recent, the better. If you choose something that is not or will not be maintained, you will run into trouble down the line. Check the Issue Queue for that module. Do the maintainer(s) answer questions in a timely manner? In the drupal modules website, there is a statistics section for each module which describes how often modules are downloaded. It is not the most perfect metric, but will help. For Example, let us take the module ‘CCK’ http://drupal.org/project/cck Here, at the bottom of the page, you will find a “Project Information” Section highlighting the status of the project

Project Information for the CCK module

• Maintenance status: Actively maintained

• Development status: Under active development

• Reported installs: 243320 sites currently report using this module. View usage statistics.

• Last modified: October 16, 2011



Maintenance Status of the module must be ‘Actively Maintained’



Development Status of the module must be ‘Under Active Development’



Last Modified date should be in within one calendar year

6.2 Installing Modules

For Drupal 7, module installation can be performed from within the Drupal interface itself. You can also choose to do it manually if you want to. In either case, follow the instructions given here

http://drupal.org/documentation/install/modules-themes/modules-7 For Drupal 6,

http://drupal.org/documentation/install/modules-themes/modules-5-6



Always read the README file that should come with each module



Enabling and Disabling modules simply means that Drupal will not load the file when running



Install and Uninstalling means that Drupal will set up data structures and destroy data respectively



Disable any modules you are not using



Be sure to uninstall modules you once installed and are not using (and do not want the data from). You can uninstall modules at admin/build/modules/uninstall.

6.2.1 Module Directory Structure



All modules should be in either of the following directories:

o sites/all/modules o sites/default/modules



(14)

7 Drupal Module Coding

A good starting point for building modules is the “Module Building Module” this is not part of the “Nestlé Drupal Platform” as it is a developer only module.

http://drupal.org/project/module_builder Additional interesting links:

 How to create a simple Drupal 6 module in three easy steps http://drupal.org/node/416986  Module developer's guide http://drupal.org/node/508

7.1 PHP Coding standards

Follow the PHP coding standards defined by the Nestlé in the PHP Coding Standards Document.

7.1.1 Exceptions

None, the guide doesn’t enforce much on the developer, it should be sufficiently flexible to build any type of module while maintaining good programming practices.

7.2 Database access

It is forbidden to bypass the drupal engine to access the database. This is especially regarding accessing nodes and other internal drupal.

Make no assumptions about the database structure! The format can change! The interface through the drupal api will not change.

7.2.1 Exceptions:

• Read Only Access to the database (this can be allowed without much impact, after updates you will have to test your code again if it still works)

• Access to your own tables, here you are quite free to do what you want.

7.3 Hooking mechanism

Remember hooks are sequentially executed, so the module shouldn’t assume anything about it’s predecessors and siblings. If you need to enforce a sequence on the hooks it’s best to hook into the previously called methods instead of trying to force yourself to be executed first.

None

7.4 Do not hack core

No matter how easy it is to modify core files to make Drupal do what you want it to do, resist the temptation. Doing so will complicate, make difficult or near impossible site updates due to Security and bug fixes You will make it difficult for those that come after to maintain the site

You could possibly leave your site vulnerable to exploits

The Drupal core has been designed to be modular, so there should be no reason to hack it. If there is a feature you want and it cannot be accomplished outside of modifying core, consider submitting your hack as a patch. Create an issue and tell the community the feature you want to accomplish. It will then be tested and your feature may become a part of the Drupal core.

Furthermore your core hacks will be overwritten when we update the drupal core, so your functionality will get lost!

(15)

7.5 Do not hack modules

The Nestle drupal platform comes with a collection of modules, these are maintained by Nestlé. If you hack into these your changes will be overwritten on the next update iteration.

Also do not hack into the self installed modules (from external source) this is a very dangerous practice and will very likely cause problems when these modules are updated.

None

7.6 Avoid hardcoding

The temptation to hardcode happens to the best of us - that's why even the best of us are at risk of being burned by it

http://drupal.org/node/1052556.

7.6.1 Hardcoding defined

Hardcoding is the practice of making code tailored to handle very specific cases. Here are some examples of hardcoding as applies to Drupal:

Inserting an SQL query into a .tpl file

Writing a script that queries the database to make some changes to nodes

Using a regular expression on the output of a theming function to change one HTML class into another

The above examples might work some or even all of the time. However, like hacking core, efficacy alone is not sufficient to make them compatible with the "Drupal Way". Even when hardcoding works - and it often doesn't work as expected - it comes at the cost of that code's ability to handle a more general set of situations.

7.6.2 Why you should avoid hardcoding

Nobody would hardcode their Drupal site if it seemed like a bad idea to them. However, there are a large number of posted fixes on Drupal.org that rely on hardcoding in some way. That's because hardcoding is often attractive to coders who are in a hurry or are just learning. They see a way to save a lot of time, and in the short run, they're right. The problem is that there are hidden costs to hardcoding that can cost a lot of time.

Comments like "don't put code into the theming layer" or "use the hook system" are common, and represent prescriptive

warnings against hardcoding. However, it can be hard for new Drupallers to find descriptive information about why hardcoding is usually a bad idea. So, here are some specific examples where practicing hardcoding might cause problems down the road:

• You're developing a theme.

You added a custom SQL query to retrieve and display information about the number of saved items a user has. Now you want to use that theme on a different Drupal install. What if the other install has a different set of table names, or is using a different module to store user information that requires a different sequence of joins? Your custom query is now useless.

• You design a hand-crafted function to retrieve and display user information.

This ends up being very processor intensive, and your client wants to cache their results. What happens if you didn't originally anticipate the need to work with existing Drupal caching mechanisms?

• You need to change the site theme based on what banner ad shows up on the site.

However, your code to choose a random banner ad is placed in the site's page.tpl file. This means that you won't know what banner ad is going to be shown until the page has already rendered to the point your function is called. What if the HTML before that needs to change?

• You have five variants on your site's theme, using different template files.

(16)

• Someone else starts working with your code.

If you used a hardcoded solution, do they have any idea what is going on, even if they're experienced in Drupal? Remember, if this is anything other than your personal blog, someone else may become involved with the project. Even if it is just your blog, how do you know how much you'll remember about your code a year from now? Remember, the primary way that hardcoding fails is by failure to anticipate factors. To go from a page request to a served Drupal page requires that your server execute hundreds of functions. By using existing Drupal hooks, you're existing within the normal, expected flow of those operations. Do you thoroughly understand all the ways in which those functions interact? If not, your choice to operate outside the Drupal framework poses some uncertain amount of risk to your site/yourself/your pets.

Despite all of the above, though, hardcoding is different from hacking core in one crucial way: there are many legitimate uses for it and most Drupal developers will have to do it from time to time. Sometimes, you know that you'll only ever need to pick out a handful of cases and it is an efficient way to do that. An example might be displaying a Halloween theme on a specific node ID that you'll only use once a year. Using a module to add a form option to choose a theme would be undesirable if you knew you'd almost never use it.

If you are going to hardcode, exercise caution, and always ask for advice if you're uncertain about whether to do it at all. Or if you're certain, because that's even more dangerous.

(17)

8 Theme building guidelines

Themes handle the branding of the drupal site. For this matter they tend to become very site specific, so the rules here are mostly for software maintainability and shouldn’t be considered mandatory unless stated as such.

8.1 Don’t use your theme as a module

Mandatory: Follow the principle of separation of concerns, themes should only be used to output already prepped data. If you

need to change your data in any way this should be accomplished by a module!

8.2 Start with an existing theme

The Zen Theme is a good starting point for creating a new theme.

8.3 Use the .tpl files

Overwrite/adapt the appropriate .tpl files to change the site’s look and feel. These expose a nice and clean mechanism to change parts of the interface.

It’s possible to do everything in your “template. php” but this is not a good practice and makes this file much more complex.

8.4 Test on multiple browsers

This seems to go without saying but it tends to get forgotten , then you end up with your site not displaying what you want on some browser.

The general rule to follow here is: Build for the most strict browser and adapt to the other ones afterward. (FF is more strict than IE). This tends to give you the least problems, and the least adaptations are needed than working the other way around In general the theme should be tested on the top 3 browsers at minimum, these take care of about 90% of the market. Browser adoption statistics:

2012 Internet Explorer Firefox Chrome Safari Opera

January 20.1 % 37.1 % 35.3 % 4.3 % 2.4 %

8.5 Screen Resolution

Develop your theme keeping in mind that the screen resolution for most customers . Today, most customers are using a screen resolution higher than 1024x768 pixels:

Date Higher 1024x768 800x600 640x480 Other

January 2012 85% 13% 1% 0% 1%

8.5.1 New technology

However with the rising popularity of handheld devices and netbooks, design to work on 800x600 is advisable.

8.6 Color Depth

The current trend is that most computers use 24 or 32 bits hardware to display 16,777,216 different colors. Older computers often use 16 bits display hardware, which gives a maximum of 65,536 different colors. So called true color is the norm here, even with the currently portable new technology this is the case.

(18)

8.7 Use the power of CSS

Carefully thinking about the layout and it’s dynamics can reduce the number of lines of code that you have to write drastically. As CSS’s can become quite complicated it’s best to divide them into sections by using comments. Also non trivial constructions should be well commented, as such that addition to the css doesn’t break the other functionalities herein.

Also try to be as specific as possible when using your selectors.

Ex. decorating <p /> is a very bad idea , because it will have site wide implications, be more specific by adding a class to it.

8.8 Assume low end clients

Although there are really funky features in the HTML5 and CSS 3 at this point the browser support for these is at best limited and only works on the newest browser releases.

You should take into account that not all customers have high end machines or have the latest version of their browser. Note: business clients tend to have less powerfull browsers than home users, this due to business adoption and upgrade strategies.

8.8.1 Minimal browser support:

 IE 6  FF 3.6  Chrome 11.0

(19)

9 SEO Best Practices

General Tips

It’s important to pick the right keywords. Don’t pick keywords that are too “hot" or you’ll never rank. Don’t pick “cold" keywords or you may rank but won’t generate traffic. Pick warm keywords that indicate people are interested in you. For example, “digital camera store" is probably a better choice than “camera".

Install the Drupal SEO Checklist Module (drupal.org/project/seo_checklist), which organizes what you’ll need to optimize your site. It also keeps track of the modules that you’ve installed and when you installed them.

As you go, configure all modules for maximum SEO benefit — and revisit their settings from time to time to be sure you’re getting the most out of them.

Links are the currency of the Web. Get as many sites to link to yours as possible!

Level 1: Strongly recommended modules

Page Title (drupal.org/project/page_title) gives you full control of your <title> tags throughout your site.

Pathauto (drupal.org/project/pathauto) automatically creates search engine friendly URLs based on the title of your content.

Global Redirect (drupal.org/project/globalredirect) Fixes some common URL problems when clean URLs and Pathauto are turned on.

Path Redirect (drupal.org/project/path_redirect) Google Analytics (drupal.org/project/google_analytics)

Meta Tags, formerly known as Nodewords (drupal.org/project/nodewords)

Level 2: “Should-have" modules

Scheduler (drupal.org/project/scheduler) HTML Purifier (drupal.org/project/htmlpurifier) Search 404 (drupal.org/project/search404) Related Links (drupal.org/project/relatedlinks)

Alinks (drupal.org/project/alinks) dynamically turns specific words on your site into links

XML Sitemap (drupal.org/project/xmlsitemap) creates a Sitemaps.org compliant, search engine readable, dynamic sitemap.

Site Map (drupal.org/project/site_map) creates a plain text sitemap

Digg This (drupal.org/project/diggthis) facilitates links to the popular social bookmarking site Digg. Service Links (drupal.org/project/service_links) adds links to several popular social bookmarking sites. TrackBack (drupal.org/project/trackback) adds TrackBack support.

(20)

Level 3: “Good-to-have" modules

Top Searches (drupal.org/project/top_searches) supplies a block with a list of the top site search phrases, to keep you informed of what people are searching for on your site.

Notify (drupal.org/project/notify) sends periodic emails with details of all changes to a site; useful for responding to comments as they happen.

RobotsTxt (drupal.org/project/robotstxt) dynamically generates the robots.txt file, which is especially helpful if you have multiple sites running off a single Drupal installation and need different robots.txt files for each site.

URL List (drupal.org/project/urllist) creates a plain text sitemap listing every URL on your Drupal site. It’s a good replacement for, or addition to, the XML Sitemap module (above).

Google News Sitemap Generator (drupal.org/project/googlenews) creates an XML sitemap that meets the specification for Google News.

(21)

10 Security

A. Files



Only your files directory should be writable by the webserver. Either of the two folders should be your files directory:

 sites/default/files  files

B. Securing Drupal User One

The Drupal account created during installation (user One) is a special account. Primarily, it bypasses all access callbacks - meaning it has all permissions by default. Failing to secure this account could result in potential security risks.

You can choose one of the following options to secure the Drupal User One Account

Rejecting Brute Force Login Attempts

For Drupal 6, install the Login Security Module - http://drupal.org/project/login_security For Drupal 7, this module is already part of the core

Disabling it entirely

Drupal does not need user #1 for administration. In Drupal 6, this account was required for running update.php and some other vital user functions. With the advent of drush and Drupal 7's creation of the administer software updates permission, this user is no longer required for day-to-day use.

http://drupal.org/project/drush

If this user is required temporarily, they may be disabled and re-enabled easily using drush or MySQL queries

Drush 4.0

drush user-block 1 drush user-unblock 1 MySQL (assuming no table prefix)

UPDATE users SET status = 0 WHERE uid = 1 UPDATE users SET status = 0 WHERE uid = 0

C. Enabling HTTPS

http://drupal.org/project/session443 D. User Data



All tables that end users can potentially modify must be separated from the drupal core tables. In other words, tables that are modifiable by web admins / content authors and tables that are modifiable by end users must be mutually exclusive.

E. Other Security Aspects

Enabling HTTPS http://drupal.org/node/382752

Preventing Execution of untrusted PHP http://drupal.org/node/615888 Preventing unsecure input formats http://drupal.org/node/224921

Using CAPTCHA http://drupal.org/project/captcha



You should set up a "developer" role and give it full access explicitly. Then create an account that is in this role. This adds a layer of security because you are not using the Drupal User One account often.

(22)

11 Performance

Current Drupal best practice is to generally build a site for its features and then allocate time to tune modules, queries, database setup, hardware, caching, etc. Overall this practice works well, but it does rely on the development team to be experienced and disciplined throughout the project so that any refactoring needed at the end of the project doesn’t become too onerous. A few things to watch out for along the way –

Choose contributed modules carefully – this means reading issue queues, reviewing code and particularly looking at database interaction (data model, query efficiency, etc.) for any modules with which you’re not familiar.

Configuring Apache, MySQL

http://drupal.org/node/36628

Caching

Because Drupal is, in the end, a database intenstive application the best way to improve performance is through aggressive caching. APC, memcache, CDNs, MySQL Proxy and static page caching all play a role in speeding up an enterprise Drupal deployment. Typical solutions include a master/slave database setup, optionally with MySQL proxy to split database reads and writes

Drupal 6 – Cache Router Module - http://drupal.org/project/cacherouter



Turn off all the modules that you are not using



Use the Admin Menu Module, which provides easy navigation for administrators



Turn simple caching on, when caching is needed



Turn Block caching on, when caching is needed



Optimize CSS

Other modules that can help enhance performance

• Views UI

• Imagecache UI

• Devel

• SEO Checklist

11.1 Basic Performance Analysis Tools



Use Yahoo’s YSlow extension (works best in Firefox)



Use Google’s PageSpeed extension (works best in Chrome )

Drupal Site Building Guide