The Drupal handbooks is only for the 5.0 version of Drupal. Each page is carefully edited and controlled to make sure that the information presented only applies to the version listed in the title. Though most of the information comes from the Drupal.org website you will see that it is much better organized. This new way of delivering the information serves two purposes. The first is to make it easier to find the right information, the Drupla.org website is chaos incarnate. The second is to make it easier to create an offline version of the documentation.
Installation
Configuration
Content Building
Coding
Administration
Information contained here is © copyright 2000-2008 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.5.
The beginning is the most important part of the work - Plato
Drupal is a content management system. It is one component of a website architecture and relies on several other components to work properly and perform at its best. If you are looking for a web host carefully review the requirements section when evaluating their services.
Drupal 7 will be developed for PHP 5.2. While this does not apply to Drupal 5 or 6 it would reduce later complication to build new sites using PHP 5.2 if possible.
Drupal is part of a technology stack. Its performance depends on a lot of factors.
| Server - A server is a computer/device which provides information or services to computers on a network. |
| Operating System - The software that the rest of the computer depends on to work. Unix, Linux, BDSD and Windows. |
| Database - A structured collection of records. Drupal uses a database to store most content for your site. |
| Webserver - The software component responsible for serving web pages. Examples are Apache and Microsoft IIS. |
| PHP - The PHP Hypertext Preprocessor is a programming language that allows web developers to create dynamic content that interacts with databases. |
| Drupal - An open-source platform and content management system for building dynamic web sites offering a broad range of features and services including user administration, publishing workflow, discussion capabilities, news aggregation, metadata functionalities using controlled vocabularies and XML publishing for content sharing purposes. Drupal is generally comprised of a mix of core and contributed modules. |
Note: if you meet these requirements but still have problems with your site, be sure to read through the Webhosting Troubleshooting FAQ.
Recommended: Apache
Drupal is being developed to be web server independent but we have limited or no reports of successful use on web servers not listed here.
Recommended: PHP 5.2 or higher
Required: PHP version 4.3.5 or higher
Recommended: MySQL 4.1 or MySQL 5.0
SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES
As of 6.x, Drupal core no longer requires CREATE TEMPORARY TABLES or LOCK TABLES, and can be installed without them. However some contributed modules may still rely on them.
Note: If your system/host is running MySQL 4.1 or newer and you receive the error "Client does not support authentication protocol requested by server", address the problem by following the instructions provided by MySQL AB. There is a minor OS issue with some MySQL 5+ installations primarily on Windows but affecting some versions of Unix/Linux as well.
PostgreSQL 7.4 or higher
Currently MS SQL and Oracle are not supported but various efforts are underway to supply schema. Please see discussions in the Enterprise Group if you are interested in working on this.
The interface for a default Drupal installation is compatible with all modern browsers that support CSS and JavaScript. However, browsers have varying levels of compliance with Internet standards such as CSS 2, so there may be minor variations in appearance.
Here is an incomplete list of browsers that are known to work well with Drupal core:
Some contributed modules and themes may not be compatible with all browsers. If you find a problem with browser compatibility, please submit an issue.
Drupal is a web-based content management system. Text and pointers to other kinds of content are stored in a database and are dynamically retrieved, composed, and presented to a user in response to a request sent via a web-browser.
Content in Drupal is created in individual "nodes". For nodes of type "story", users can add comments to the node (comments themselves are not considered nodes). Depending on site settings, adding new nodes and/or posting comments might or might not be allowed. Also, nodes or comments might require approval from the moderators before the node or comment is displayed. Blog entries are another type of Drupal node.
The default Drupal layout ("Theme") consists of three columns. The center column is referred to as the "Content Column". It typically displays summaries of the most recently posted nodes in date order. If you click on a node summary, the full content of the node is displayed in the center column.
The left and right side columns are referred to as the sidebars. The sidebars can display blocks of related information. Blocks often contain links for navigating to other nodes. For example, there can be blocks displaying the most recently posted stories, or the most popular stories. For new installations, the login block displays, along with a navigation block containing a menu of available actions. Different menu items can display in the navigation block depending on what you're doing and what privileges ("roles") you have.
Blocks may or may not display depending on what you're doing and what privileges ("roles") you have, as well. For example, the login block will not display if you're already logged in, or the "most recent stories" block may not display if there are no story nodes available. The administrator can enable/disable different blocks under the Administer >> Site building >> Blocks menu item.
Nodes can be organized into categories, also called taxonomies. Forums are an example of content nodes organized by category. Categories can be hierarchical, where one parent category contains multiple child categories.
New features in Drupal are often implemented as "modules". Once an administrator adds a module file to the "modules" subdirectory, the option to use the module appears in the Administer >> Site building >> Modules section. If the administrator enables that module in Administer >> Site building >> Modules, the features associated with that module become active. A module may define new node types, new menu items may appear in the navigation block, and new types of blocks may become available for display in the sidebars.
There are many words and terms used in the handbook and the forums that have specific meaning and understanding them will help you use Drupal and communicate more effectively when asking questions in the forums.
This page provides a simplified overview of Drupal. For more technical information, see the Drupal Handbooks
Drupal is a content management system. In other words, it is software that organizes and displays web pages like articles and blog postings (along with other content such as videos, images and music).
Drupal stores your content in a database which is organized into tables and the tables are made of rows. Each row is a collection of related fields. For example, in a table used for storing contacts, the row might have fields called user_name, address and phone_number.
When you install Drupal you create a database that holds the content and the administration information for your website. Unless you are a real systems administrator you will probably never need (or want!) to interact directly with the database. Fortunately Drupal provides you with a simple but powerful web interface for managing your site.
The appearance of your content (in other words, the colors, fonts, placement of elements etc.) is controlled by the "theme". You can use one of the default themes or download a theme from the Internet. If you need a different design, you can modify an existing theme (relatively easy) or create a theme from scratch (relatively challenging). You can also allow your visitors to select the theme they like.
The default Drupal installation provides several "content types" such as blog and story. You can also define your own content types, perhaps adding new fields where your authors can provide additional information about an article.
You can modify the theme so that different content types will display differently and you can restrict access to certain content types. For example, you might have some content which should only be displayed to registered users.
Although the default Drupal installation provides many options for creating, organizing and displaying content you will probably find that there are other features that you would like to add to your site. The chances are very good that the capability you need is available in a "module" contributed by another Drupal user. Some of the contributed modules have been refined over a number of years to become very powerful and useful. For example, many Drupal sites make use of the Content Construction Kit (CCK) module (for creating custom content types) and Views module (for displaying lists of content).
Traditional websites are static, meaning the content doesn't change. You create a Home page and you put that file into your directory tree as index.html. You may also create an Article and put that file into your directory tree as article1.html. Then you add a link to your home page for people to access the Article. For someone to find the article they will need to be on a page that contains a link to that article and the only links to that article will be ones you create. The appearance of the content is defined in the HTML or CSS, each difference must either be hard coded into the content file or linked to an individual CSS sheet.
Drupal, on the other hand, is dynamic, meaning your content is stored in a database and presented to the user when the web server receives a request from a browser. This means that a Drupal site won't have these individual HTML files. If you looked in your directory there won't be an index.html or article1.html file, the article content is contained in the database and the appearance is controlled by the theme (which is a separate collection of template and CSS files). You can create a static Home page, or make only a portion of the Home page static (sticky), or have the Home page change as often as you add content. You create the information once, and then have various possibilities on how you want it to look, and where and when someone will or won't see it.
Suggested Reading:
General concepts
Terminology
This topic assumes you have Drupal installed and created some content successfully. You now want to build the website you have in mind but don't know where to start. At this point it may help to know more about some central concepts.
What is a Node?
The main building block of Drupal is a node. The word 'node' does not suggest that it is a part of some network. On the contrary, you should think of a node as a single puzzle piece that is placed onto the site by one of your users, or even yourself. A node can be part of a forum, a blog or a book, and by using the Content Construction Kit, you can create as many custom node types as you want. Remember that each node has a type, referred to as a Content Type. It also has a Node ID, a Title, a Body, a creation date, an author and some other properties. It is stored together with all other nodes in one big "shoe-box" known as a "table" in your database.
Drupal has many tables, I think the core has some 50 of them. You may want to explore them on your own site to get a better idea.
Users have their own table too, and some of them are authors of nodes. So nodes do have relations. The only way to find those relations is by searching the whole table until you find all matching items. Luckily the database server is very fast.
Each node can have an unlimited number of comments. Comments are stored in a separate table. To find all comments on one node the server will search the entire comments table.
How do Nodes work?
Look at the address bar of your browser. It probably says http://drupal.org/node/19828. This is the Drupal way of saying "Load all pertinent information for node 19828, including whatever relations (comments, users etc.) are to be shown". This is called a database query.
Most queries in Drupal are hard-coded in modules. /tracker searches all nodes and sorts the result by date. This also works for your site, as long as you enabled the tracker module.
When you hover over the menu and meanwhile read the links in the status bar you get a quick idea of possible queries. Because Drupal mimics a directory structure you maybe didn't know it was a query until now!
Drupal modules perform a lot of operation on the data. For instance when you open a page which you have written yourself you see a view/edit tab on top of the page. This tab is not shown on other pages. This is automated behavior defined by the user privilege settings.
Menus and Blocks
Menus are displayed in blocks. Blocks are the columns at the left and/or right site of your web page. First be sure to enable the menu module (blocks module is always enabled). You will get a menu item in the admin menu. As of 6.1, menu module is enabled by default.
All modules come with default menu items. Often you only will need to enable them. You can change its location in the menu tree by setting its parent and you can change its title if you wish. In all cases it will only show up when you have rights to view the content. E.g. the admin item is not shown to visitors.
You can also create custom items (add menu item tab). You will need to provide a path to the content. Go to the page you want to link to (e.g. via recent posts) and look at the address bar. By default the address next to the domain name will begin with '?q='. When 'clean URLs' is enabled you will see a directory structure. Anyway, you need to copy-paste the right part of the address without the domain name and without the "?q=". This is called the local or relative path. (But as I mentioned, it's a database query mimicking a directory structure.)
By the way, if you change your settings to 'clean URLs' you may also want to change the "default front page". That can be your forum main page 'forum' or a custom made page 'node/15'.
'Navigation' is the default menu, but you can create more as you like. You will need to activate a menu in the blocks settings to tell if, and also where, you want those menu to be displayed. Next you can move menu items to it by changing the item's parent property.
You also can create custom blocks. You can type the html code yourself so you have complete freedom.
You will soon discover the menus and blocks will not give you all you need. The main problem is that a menu item can point to a single node or to a list of nodes of one type, organized by date. In other words, you only can create links that have a fixed meaning, defined by the modules. And you want more of course! For that reason you will need modules that create structure. Examples are:
- books
- stories
- search
- taxonomy
- archive
See also
Drupal stores all of its content in nodes. Drupal's basic set of node types is relatively short, but quite flexible.
As of Drupal 5.x node types are now called 'Content types'
Additional types of nodes are provided by contributed modules.
Note: A common question is "What is the difference between page and story?" The answer is not much. There was more difference originally but they are merely different node types now and how you use them is up to you.
This document describes the vocabulary used by Drupal and the Drupal community.
2) Unix/Linux/Windows - Permissions are security settings restricting or allowing users to access information of perform certain functions at the Operating System level. In the case of files on Unix or Linux systems, there are three types of permissions: read, write, and execute.
For alternative explanations of Drupal terms, these external sites may be useful:
Examples of Drupal paths
How to find Drupal paths
To find the Drupal path of a certain page, go to admin>>content. You will see a list of all the pages you have created. Mouse over one of the titles and you will see something like this in your browser's status bar (usually on the bottom left, or click on the title and read the address bar when viewing the page):
http://www.example.com/?q=node/54
The last bit after the /?q= is the Drupal path, i.e. node/54.
Keep an eye on your status bar as you mouse over links and you will discover more Drupal paths. And when you go to different pages check out the address in your browser's address bar.
Some other places to find Drupal paths
administer >> categories. Roll the mouse on top of the "edit term" link next to the category (for example, taxonomy/term/6).
So, a contributed module you like has not been updated to the latest version of Drupal. What now?
The best place to start is the project page for the module to see if there is a more current version packaged and ready to go.
You can also check the pending patches list for your module. Look to see if there are any patches that are labeled for the version of Drupal you are using. If there are:
If no patch exists, check the Issues queue for the module.
A consideration is also that the features in that module have been rolled into another module. As Drupal core advances things become possible that may not have been in the past. Contributed module developers may have joined forces to collaborate on a better module api that helps reduce the work on one person. If this happens it is usually noted inthe modules project page description.
On a last note, if you are currently using Drupal, you may consider staying with the version of Drupal you are on. As long as there are security releases for it and it is supported by the community. The downside to this is that upgrading multiple versions may be more difficult, but that is something that needs to be evaluated on a site by site basis.
Everyone considering Drupal should understand that Drupal development is always about improvement and staying on the cutting edge. Each major release of Drupal offers vast, often radical new improvements. (For more information on what Drupal version numbers mean, please see: http://drupal.org/handbook/version-info.) However, while each new major release of Drupal contains the means for stable and reliable upgrade paths that preserves your data from previous releases, each new release of Drupal code provides little or no backward compatibility.
Drupal founder Dries Buytaert explains:
When I first released Drupal, I chose not to preserve backward compatibility, because I was mainly interested in getting the technology right. Preserving backward compatibility often requires that you drag historical baggage along, and in interpreted languages like PHP, this comes at a significant performance cost. So it was decided that we can break people's code, but not people's data. Our mission was to make Drupal fast, small, clean and on the bleeding-edge of technology. In the early days I focused, completely and utterly, on the aesthetics of Drupal's code. I spent days trying to do something better, with fewer lines of code and more elegant than elsewhere. And with me, many others.
It was the right thing to do. Over the years, we've seen a lot of innovations happen that would not likely have happened while preserving backward compatibility (the node system being one of the most prominent examples). Developers always had free reign to implement their ideas in the best possible way. It is something that Drupal has in its favor compared to many other content management systems. It's been interesting to see how Drupal has spread and how it has grown to be more flexible and cover more niches than many other systems. If anything, this needs to be attributed to the fact that we haven't cared much about backward compatibility, and our single-mindedness to get the technology right....
...Given the fact that Drupal's main strengths have always been the agility with which it can respond to the ever-changing landscape of web development, and the almost infinite amount of flexibility and expansion it affords developers, I feel that preserving the ability to constantly innovate is of higher importance, at the present time at least, than preserving backward compatibility. None of us would be here now using Drupal were it not for this core value, and I strongly believe that it is fundamental to our future. It always has been.
This philosophy and approach to ongoing development has been embraced by the Drupal development community.
It is recommended that you run the most current stable release. This can always be found at the Drupal Project page. However, if there are no compelling features in the latest version, a contrib module that is important to you isn't ready or you don't have time, there is no need to rush your upgrade as long as security updates are available for the version you are running.
The current stable release is Drupal 6.2. The next version will be Drupal 7. It is in early development. If previous patterns continue, Drupal 7 will likely be released in early 2009. Drupal 5 is still supported; the current version is 5.7.
If you are just starting your site you need to do a needs assessment (both functionality and launch date requirements) in advance of deciding whether to begin building with Drupal 6 or Drupal 5. There may be some contributed modules that would be key to your design that have not yet been ported to Drupal 6.
Per the Open Source tradition, when it's ready. When sufficient testing of fixes of bug reports is complete. More attention is given to a rapid release of security issues. The more people involved in fixing and testing reported issues, the faster a release is likely to come out.
If it's available, go to Administer >> Logs >> Status report. This will list your version number if you have Drupal 5.0 or later.
Failing that, look for a file called CHANGELOG.txt in the root of your Drupal directory and open it up to find the version you are running.
If CHANGELOG.txt is missing, you can also check in system.module for a line at the top like:
define('VERSION', '5.5');
If this is present, it will tell you which version of 5.x you are running. If not, you have a version earlier than 4.7.0.
Supported versions for security patches and availability for download are the current stable release and one version previous. Running unsupported versions may expose you to unknown security risks and you are strongly urged to remain updated to a supported version and sign up with the security notification list.
For more details read this overview of the Drupal's philosophy on backwards compatibility.
In Drupal 4.7.x and previous, the first two numbers indicated the Drupal version number, while the last indicated a "point" or bug-fix release with a specific "patch level". For example, "4.7.3" means "the third bug-fix release (patch level 3) of the 4.7 version of Drupal."
This was frequently confusing for people who expected 4.7.x to be a minor update of 4.6.x, when in fact this was far from the case. Different versions of Drupal often break API compatibility with one another, and require contributed modules to be upgraded.
Starting with Drupal 5.x, the "5" indicates the major version of Drupal, and the .x is the bug-fix release or patch level. That means that 5.0, 5.1, and 5.2 all have the same underlying structure and modules for 5.x are all compatible with each other. However, modules written for Drupal 6.x will not work with 5.x and vice-versa.
A release with "-dev" at the end of the version indicates a development snapshot from the end of a CVS branch (as opposed to an official release from a CVS tag). These snapshots, by their nature, include changing code. It is therefore hard to know exactly what revisions of each file they contain, even if it is a snapshot of a stable branch where only bug fixes and security enhancements are being made (such as the 6.x-dev snapshot release of Drupal core). This makes them more difficult to debug, and they should generally be avoided for production sites. Development snapshots also use "x" for the patch level to further indicate the variable nature of the code they contain. Both Drupal core and the contributions can have development snapshots.
Now that the new system for releasing Drupal contributions has been installed, contributions have a more elaborate version string. The new strings indicate the version of Drupal core the contribution is compatible with, whether it is a stable or development release, and what specific "patch level" of the code it represents. These strings have the form:
CoreCompatibility-Major.PatchLevel[-Extra]
Versions with extra tend to be less stable (development snapshots in particular are inherently unstable) so they should be avoided for production sites. Official releases uniquely identify an exact set of revisions of each file in a contribution. This identifier can be used in many places: the issue queue, the CVS repository, in forum posts, emails, and so on.
Some example version strings and what they mean should help clarify:
If you happen to have an older "release" of a contributed module, the version numbers are different. Prior to 2006-11-11, the version numbers for contributions where of the form "X.Y.0".
Due to code changes in major Drupal core versions, modules are not expected to work with newer Drupal versions. If you wish to test, please do so on a test system. Otherwise, feel free to help the maintainer by submitting patches to update the module. If a maintainer is unavailable, you can apply to become the maintainer. (See the developers guide for more information).
Before every official "x.0" stable release of a new major version of Drupal core, there are usually a handful of beta releases and release candidates that are made available. These releases are not yet stable enough for production use, but are essential milestones on the way towards the official release. They allow a much wider pool of users to test the latest code and provide feedback before the official stable release. These releases should only be downloaded and used by developers very familiar with Drupal or those wishing to help find bugs in the software.
Some maintainers might choose to provide beta releases or release candidates of their contributed modules and themes (though this is not required). You should read the release notes carefully in these cases, since the details might vary across projects, though the basics explained here should hold (a "beta" is less stable than an "RC", etc).
Once a feature freeze is announced, no new features will be added to that version of Drupal. That version of Drupal's feature set is locked and any new features or change of behavior will need to go into the next release version.
In the forums you will see references to Drupal HEAD or just HEAD. You will also see references to Drupal CVS which is often the same thing. The name comes from the fact that Drupal uses the CVS version control system to track changes to the code, and in CVS, "HEAD" refers to the main development area (also known as "the trunk").
In Drupal core, HEAD is the name given to the version of Drupal core being worked on by developers right now. Of course, now that core is only using two digits for the version number (starting with the 5.0 release), there's no longer any ambiguity about what the next version of core will be called, so the use of "HEAD" to identify a release is no longer necessary. For example, now that the official 5.0 release of Drupal core is out, everyone knows that the next version of core under development will eventually become the 6.x release series, so the nightly snapshot releases are more properly called "6.x-dev", not "HEAD".
HEAD versions of Drupal core are not meant for use on production sites and should only be downloaded and used by developers who are very familiar with Drupal, or by testers who are helping to find bugs. HEAD is a moving target, and is prone to serious bugs and security holes.
When a contributed module or theme is tagged with HEAD, that means that it is the latest version on the main development branch. But "latest" can be any age -- perhaps over a year old! When a file was made for Drupal 4.3.x, it is HEAD of its own branch, but that does not mean you can run it with Drupal 4.7.x, or 5.5, or that it is necessarily compatible with any other module or core code that's tagged with HEAD.
In general, production sites should never use HEAD versions of any module or theme; they should always use official releases with real version numbers. Under the new release system, even the HEAD releases of contributed projects are required to include version information and to indicate which versions of Drupal core they are compatible with. A contribution without any official releases indicates that the contribution maintainer is not being very responsible, and you should use these contributions at your own risk.
There is no site that is so small that it is not important to someone. - Steven Peck
If you are going to invest the time to set up a CMS, then you should protect your investment by following some simple best practices. These guidelines are only suggestions. It is up to you to decide what is appropriate for your site.
The following list contains some quick pointers (for more detailed information, see the list of articles at the bottom of this page):
These are some simple guidlines for setting up Drupal on a classic Linux-Apache-MySQL-PHP (LAMP) stack that provides a fair amount of security for the rest of your system.
To start, some common PHP configuration options can be optimized. On some systems, these settings may already be set, but it never hurts to add them yourself just in case.
PHP settings can be controlled in a number of ways. If you have access to the php.ini configuration file (usually found at /etc/php.ini), you can simply edit this file to cause system-wide changes. If you'd prefer to make these changes just for your Drupal installation, however, the best place to do so is in your Drupal installation's settings.php file.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 30720 bytes) in /path/to/drupal/modules/system/system.module on line 1022
If you have access to your system's Apache configuration files (typically /etc/httpd/httpd.conf or /etc/apache2/httpd.conf), you can also make some simple changes to simplify Drupal's multisite configuration for subdomains.
Tweaking the configurations for your MySQL database server can give you a boost in performance. The MySQL configuration file is typically /etc/my.cnf.
These are general guidelines.
For example: a module named foo.module would go in a sub directory of modules; modules/foo Be sure not to include the space if the module name is multiple words.
There are many programs (XAMMP, MAMP, Apache2Triad) that help you setup a local test system easily. You should set one up to play with your site and to test backups and restores of your production site. Set up a test site using a copy of your live data. You do not want to have to ask in the forums how to save your site. You have worked hard to build it, it would be a shame to lose it.
For more information on installing test sites, please see the setting up a development environment and getting started sections. There are some specific examples of copying a production site to a test/development environment in the Special cases subsection under Installation.
There are several approaches to updating your site and the instructions are in the INSTALL.txt file of the Drupal download. Unless you do this often however, you may miss a few other considerations when updating from one release to the next.
Read the upgrade portion of the INSTALL.txt file
You can restore this to your live site.
- or -
Follow the steps on your live site now that you are confident it will work.
Start working on your theme updates and other and stuff.
Do not modify Drupal core files.
Are there exceptions to this rule? Sure, but this is generally for specific sites or implementations by people who are extremely familiar with the Drupal code base, development practices and security model. Those who properly document their changes and practice proper revision control with their code. If you have to ask, chances are you shouldn't.
Security is an important consideration when running your web site. If you maintain your own server you should be aware of any announced vulnerabilities for your operating system, php, and web server. Be sure to follow up with the appropriate patches or updates as needed. Sign up for the security mailing list so that you can be aware of any announced vulnerabilities and how to correct them.
I am one of the many Drupal "newbies" who seemed overwhelmed at first. Well, I still am. But I have learned a lot in my first month with Drupal. I'm even answering questions in the forums (actually, I think it's fora.)
With some encouragement from other newbies, I decided to write down what I'm doing to build my sites. (Shoot, at my age, I can't rely on my memory, I have to write it down.) Yes, that's plural. As of this writing I have three sites in production, plus a test site for playing around.
The basis of this book is going to be my efforts to build new test sites on my PC, running Windows. Hopefully by the time I get to that point in this book, I'll have figured out how to transfer the developed sites onto the remote production servers. Pretty much all of this is directly applicable to building a site directly on a web server.
It is a pure myth that you have to know how to program (especially in PHP) to use Drupal. It doesn't hurt to have some basic knowledge of PHP, HTML, and CSS, but it is not required. Here are some good resources for you:
Now, to be honest, I have used HTML in this book, and tweaked the CSS on my site a little bit. But I have not used one line of PHP code.
Another common myth is that your learning curve for Drupal is going to be steep and it will take you months, or even years, to get a web site up and running. Hogwash! I had my first, largely static, web site with 36 pages up in less than a week after I installed my first copy of Drupal. Then, because my hosting provider pulled the plug, I got my group's site up in the time it took to get the domain name transferred (about 5 days). That was after about 16 days from starting with Drupal. That site had a lot of static content, but also required a taxonomy-based access control module, a fancier theme, meta tags, photo albums, and a calendar - and it all had to work right away!
You can do it! Yes, YOU.
There are a few things you need to know before you post anything on the Drupal web site:
Throughout this site, as well as the Drupal site, you will see things like Administer>>Access control>>User management>>Roles. This means click on "Administer" in the navigation menu, then "Access control," then "User management," and then "Roles."
I will occasionally refer to "production" or "live" sites. These terms are pretty much interchangeable. The latter term is more modern and accepted in reference to web sites and means the site that your end-users interact with. The former term is largely synonymous but is a more "traditional" data processing term.
This is from a post by ebrad on March 26, 2007, with some minor editing.
I don't know if I could call my sites "great;" it's taken about 9 months to really get a good understanding of how to use Drupal and its modules. This doesn't include learning the API or writing my own modules.
These are some recommendations I would have given myself before I began with Drupal:
Good Luck!
Drupal is very powerful and flexible. That means it must have a significant degree of complexity. Do you think the folks at Myspace don't have their terminology or managed to roll out that site in a day? I don't know who told you Drupal was easy, but many people make it harder than it has to be by thinking they need to understand everything at once.
Terminology is necessary in order to properly convey what one is trying to say or ask. If you talk about "that box-like thingy on the right side of my screen" you could be referring to many things. Contrast that with "the Author Information block in the right sidebar" - now you are precise and everyone knows exactly what you mean. You've told them what it is, where it is, and even how it got there and part of how you've styled it.
Start by trying to understand the basic parts of Drupal, don't try to understand everything at once. For example, it is imperative that you know what a node is (look in my book). Then understand what content types are. Learn the basic parts of the rendered page (header, footer, left and right sidebars, and the center, or content areas). Check out the administration pages so you have some idea where things are, even if you don't understand them all today.
It's all fine and good to have "MySpace" as your target, but you are one person with a new tool. The people that put that together are many and using tools that they already were familiar with. (BTW, I find MySpace to be rather illogical.)
Just start by getting something up and visible. Then celebrate that you've done that. Now you're ready to move on to more wonderful things, but do it one step at a time. Don't add tons of modules right away; get comfortable with what you have. Add modules one at a time and get familiar with them - one at a time.
As for making Drupal easier and more logical, you're welcome to submit feature requests or explain why something is not done in the most logical manner. But don't demand it, or threaten to abandon Drupal if you don't get it your way. And certainly don't resort to name calling or derogatory comments.
There are a number of ways to set up a test environment on your own local computer. Numerous applications and tutorials for a variety of operating systems are located in the Setting up a development environment section of the handbook.
Reasons to run a local development server:
This tutorial uses the example of building a site on a PC with Windows using the DeveloperSide.net package.
This package has already integrated the following things:
Do note that any package, like the DeveloperSide one, that includes Drupal for you may not always have the latest secure version of Drupal. It is, therefore, recommended that you check the version immediately and upgrade Drupal if needed when using these packages.
I followed their instructions, which built me a working system! For more instructions see the Web.Developer page in the development environment section. I don't remember if it was automatic or not, but you will find it useful to have the "Web-Developer Controller" icon on your desk top.
The only "fly in the ointment" was that when I went to the Drupal web site to start pulling my modules and themes, there was a big announcement on the front page saying that a new security release for Drupal 5 had been released and was highly recommended.
I downloaded the latest stable release. I then unzipped it (using WinZip).
Of course, that created a directory called "Drupal-5.1," (the latest version at the time this was written) but the other software I had installed was looking for a directory called "Drupal." Well, by getting Apache and its services shut down, I managed to rename the two directories so that 5.1 was now called "Drupal." It worked! I now had a running 5.1 system!
If you have not set up your site using a package that includes Drupal, it is still very easy to install in a few minutes. You can find complete instructions in the handbook Getting Started section under the version number you are installing. Here are the directions for Drupal 5.
Whether you run one site or several, there are some basic things you should do right now. Here's what I do right off the bat; the advantage to doing it in the "root" database is that when I make copies for my other sites this has already been done. I'd give you a link to something on the Drupal site, but I never found anything like this.
I do recommend turning on (enabling) the "Path" core module so you can use "normal" names for your pages.
If you want to use the contact form to email anyone from the site, be sure to enable the "Contact" module.
There are a few things I recommend that you do in all your databases, so this is a good time to do it:
Need another test site? Here's how to do it the "easy" way. [Hint: if creating multiple sites is desirable make a list of the desired sites before reading through these instructions completely. Some steps can be done in bulk to save time.]
Why create extra sites? In addition to my having several sites running already, I had some ideas in the back of my head, not the least of which being a site where I could document everything I do (like this book). I also had some idea for other sites that I might put up in the future. So before you totally pooh-pooh the idea, give it a few minute's thought. And you can always change your mind later; it just might be a bit messier then.
At the very least, I would create a "working" site other than my "root" site. This makes it easier to start all over again if you get totally out of control later on.
This may look like a long process, but it's deceiving because I spell it out in detail. It is expanded and updated from the post "Running multiple sites on a local PC (localhost) from a single codebase, using Windows." For more details on the "official" stance on the sites directories, read Setup of /sites directory for multi-site.
If you want to get deeper into creating multiple sites either locally or on your server, you can search the forums at drupal.org with the term "multi-site"; there is also a group devoted to this subject at http://groups.drupal.org/multisite. Within the Handbooks, there is a good section: Multi-site installation and set-up.
start bulk loop 1
end bulk loop 1
start bulk loop 2
end bulk loop 2
I did notice that my version of Apache sets index.html ahead of index.php, so don't have an index.html in your directory.
start bulk loop 3
end bulk loop 3
start bulk loop 4
end bulk loop 4
Go for it. You can now start the browser and enter http://databasename.
For more details on directories for multiple sites, see Setup of /sites directory for multi-site.
Occasionally, a user may do something that confuses Drupal, such as typing a wrong page name or trying to access content they shouldn't. These will generate 404 and 403 errors, respectively.
A recent SEO newsletter, they mentioned the value of letting Drupal handle these errors:
Your unique 404 error page should look like a regular page of your site. It should include your site's header, footer and navigation bar so that the site visitor can easily click on another area of your site. The content of this unique 404 error page should contain text explaining that the page selected is no longer available along with contact information so the site visitor has the option of emailing or calling your company.
This was one of those "Duh" moments for me. How obvious it is that you should make it easy for the user to get "back into" your site.
The same more or less goes for the "access denied" (403) error message. Let them know they did a no-no and try to explain why.
Just go to "Create content" and select "Page." I title them "Access Denied" and "Page Not Found" but you can call them whatever makes sense to you and your users. When you submit them, note the node ids. Then go to Administer >> Site Configuration >> Error Handling and enter "node/nnn" in the appropriate boxes.
Here's the HTML for my 404 page:
Sorry! The page you were looking for no longer exists. We redesigned our site and many of the pages have changed.
If you are unable to find something on our new site or have a question about our site or services feel free to contact us.
--Webmistress
Here's the HTML for my 403 page:
We're sorry, but you must have permission to view the page you requested.
If you are already a registered member of this site, please try logging in.
If you are not a member, you need to join us.
If you have any questions about our site or group, please feel free to contact us.
--Webmistress
Don't worry that you haven't created the "join_us" page yet. This is an advantage to having URL Alias support (the Path module) enabled. Just add to your to-do list to create this page when you get to the "Creating Content" step a few chapters later in this book.
Okay, great, now we have all that software installed. But how do we use it?
First, open the "Web-Developer Controller" that you put on the desk top. Look at the top left. You want to see, and should, if Apache and MySQL are running. If they are, you're just about ready. If not, select Apache, then click on the "Start Service" button. Within a few seconds it should change to "Running." Now select "MySQL" and start it.
Fabulous, we have the software ready for us. Now let's get us ready.
Fire up your favorite browser. In the Address field type in http://localhost/drupal/ to access your "root" database. Since you've done everything right, you're now into your Drupal database.
Congratulations! Now the work begins.
Let me first say that a newbie shouldn't worry a lot about adding modules and themes at first. Work on the basics of your site first, then worry about add-ons.
Themes are largely a matter of taste. For example, I have no idea why anyone would use a "fixed width" theme, but lots of people do. One nice thing about themes are they are pretty much independent of your content (later on you can look at the many submissions that are dependent on content).
Contributed modules are ways to add or extend functionality of your site. The only module I, personally, consider necessary is the Nodewords (a.k.a Meta Tags) module; in my opinion, it should be promoted to "core" status. This one allows you to add the "content," "keywords," and "robots" meta tags to your pages. This is useful if you're interested in your search engine rankings. You will also find that many contributed modules also require the Views module; I go ahead and make that a standard one for my sites.
Now, if you experiment with different themes and modules, as I know you will, despite my suggestions, you should also look at the Update Status (core in D6) and Site Documentation modules to make sure you are current and to document and clean up the mess your experimentation will make. Here are some suggestions on choosing the release: Strong stomach?
Installing a module or theme is pretty much the same until you get to enabling them. Now keep in mind that I use a Windows based PC (development) and Linux servers (on my live sites).
You enable a module at Administer>>Site building>>Modules. The non-core modules are listed farther down. With 5.x, they now show you some of the inter-module dependencies. I turn them on and "Save configuration" in order of the dependencies. For example, "Views UI" requires "Views", so I turn on "Views" first, save the configuration, then turn on "Views UI." and save again.
Most modules introduce some kind of menu items. Those will generally appear automatically when the modules is enabled. A few menu items will not show up until the permissions are set (the next step). And even fewer require you to take action to add the menu items, but the module will have instructions on how to do that.
Ah, now the real work begins. Go to Administer>>User management>>Access control to select who can use the features of the new module.
If the module introduced new content types, go to Administer>>Content management>>Content types and configure them. Don't forget this may also affect your "Input formats" (Administer>>Site configuration>>Input formats) and "Categories" (or taxonomy, Administer>>Content management>>Categories); you'll have to check those too.
Okay, now you can start using the new module.
My documentation site is a relatively "vanilla" implementation of Drupal.
| Core Modules Enabled | Contributed Modules in Use |
|---|---|
|
|
To get some idea of what modules are available, check these links: module handbook and contributed modules handbook.
You enable a theme at Administer>>Site building>>Themes
If it has never been enabled on this site, you will have to check the "enable" box and then click the "Save configuration" button at the bottom.
To set up how the theme works, click on the "Configure" link (not the tab at the top).
Fill in the fields.
Save the configuration.
Don't leave the page yet.
Now use that "Configure" tab
I prefer to do this part under the "Global Settings" but it can be done theme-by-theme if you prefer.
The "Default Logo" is that little picture (usually) in the upper left corner of the page. For example, on the "Bluemarine" theme, it's the Drupal logo.
If you want to change it, here's how:
| Theme Name | Width | Height |
|---|---|---|
| Bluemarine | 48 | 55 |
| Chameleon | 49 | 57 |
| Garland | 64 | 73 |
| Minelli | 64 | 73 |
| Pushbutton | 144 | 63 |
| Fancy | 80 | 80 |
Now you click the "Save configuration" button. If you did this in "Global settings" it affects all themes (assuming they behave properly); if you did it for a single theme, then only that theme is changed.
For a list of all available themes, check Themes.
HINT: Going to make a few (or a lot) of changes to a standard theme? Think about copying it over to your /sites/sitename/themes/ folder and renaming it. Then you can do anything you want and still be able to undo it easily by recopying. If the changes ae a bit bigger, think about contributing it back to the community (with your name, of course).
"Wow, I've done all this and I still don't have any content on my site!" Well, let's fix that.
First, let me explain that the page your visitor sees first upon entering your site is usually called the "home" page. Drupal calls this the "front" page, much like a newspaper. This page is special to Drupal. I know you're in a hurry, but read about both "pages" and "stories" before you decide which to use to create your front (home) page.
Drupal says, "If you want to add a static page, like a contact page or an about page, use a page." If you're used to building web sites with HTML, this is what you've done in the past. In general a "page" is going to stand on its own and will probably have a menu entry. You may also later add it into a book. When I created my first two sites (based on former static HTML sites, I made the front page a "page;" I have since changed to a "story."
Drupal says, "Stories are articles in their simplest form: they have a title, a teaser and a body, but can be extended by other modules. The teaser is part of the body too. Stories may be used as a personal blog or for news articles."
Okay, you've seen the Drupal site and noticed that there are "pieces" all over the place. Look at the front page; you'll see several announcements with space between them - those are "stories."
I have now switched my sites to use stories on the front page. The "welcome" message is one story. I have an announcement story node that any of my admins can edit. If you want to have weather or cartoons, a story is a good idea. Another use is if you are on a net ring - put the ring links into a story.
Drupal says, "A book is a collaborative writing effort: users can collaborate writing the pages of the book, positioning the pages in the right order, and reviewing or modifying pages previously written. So when you have some information to share or when you read a page of the book and you didn't like it, or if you think a certain page could have been written better, you can do something about it."
Another way to use a book is to collect related information together. A book has its own navigation, so it can also be used to de-clutter your menu.
You probably already know what a blog is, but just in case: A blog is a diary, collection of thoughts, or other time-ordered content. The Blog Entry content type is added by the blog module. The blog module allows you to have a multi-user blog, meaning that every user can have their own personal blog. This adds titles and breadcrumbs to indicate the blog authors' names. Generally if you only have a single blog for a site then it is best to use the Story node for blog entries.
So have you decided what kind of content you want? No, okay, just start with a page; it's easy. As you go create your content, be thinking about the menu as well.
NOTE: If you want to set your front page (Administer >> Site configuration >> Site information) as "node," then you need to have at least one piece of content marked as "promoted to front page." If you don't do this, you will keep getting that "Welcome to your new Drupal site" message.
Another Handbook section you may find useful is Creating new content.
There is a choice of facilities for adding images to text items, with pros and cons of each.
1. The Image module, and associated features. Makes each image into a Drupal node, which ads a lot of capability.
· Image_Attach, which adds a separate image field to the target node, pointing at the image node. Provides simple image upload, but little other control.
· Image_Assist which embeds the image in a text field. Provides visual image selector, upload, and control over size and left/right float. Adds necessary HTML to text field.
· drupalimage plug-in to TinyMCE editor which makes Image Assist work with a TinyMCE field, which displays the result as a WYSIWYG image (though not styled fully according to your theme).
Also untested further features, including:
· Bulk upload facility
· Interface with the Drupal Gallery support module.
· Similar interface to the Acidfree support module.
2. The CCK ImageField. Very similar to Image Attach, but just uploads image into a filestore file, and again contains little extra control over e.g. sizes or styles. It is almost invariably used with Imagecache to give fine control for resizing.
3. IMCE( demo at http://ufku.com/drupal/imce/demo). Provides facilities to upload and search for images on the server. Functionally similar to the Image_Assist/drupalimage combination, but the integration with TinyMCE is neater for inserting images, and there is more control over the attributes of the image once inserted. BUT the image filing and select window does not look so nice – to the point of affecting usability, and there are bad things on the Blogs about the associated gallery function.
4. Or go to FCK Editor. From the demo seems as good an editor as TinyMCE, and has its own image upload and filing mechanism. But:
· No automatic creation of thumbnails etc. (cf Drupal Image)
· Images are simple separate filestore files – may be a benefit depending on what one wants?
I have oscillated quite a bit, but (at the moment) am going with the Image module:
· Install the Image module as normal.
· Do the stuff in http://mybesinformatik.com/tinymce-and-drupal5 to add the drupalimage plugin to TinyMCE.
· Tune the settings in the TinyMCE Profile to show the features required.
· Create a Taxonomy to allow tagging of images for easier retrieval.
After following the next few steps, you will be able to easily add / change your front page anytime in the future.
After logging in as Administrator, select
Create content > Page
from the left menubar, and create your own content that you would like to publish as a front page. If you are done, hit „Submit” to see the results. Notice that the current URL (the path to your newly created page) looks like this
http://www.example.com/?q=node/# (normal)
http://www.example.com/node/# (using clean URLs)
where # means a number. We will need that number, so write that down somewhere or just try to remember that.
Now you can either choose to
After creating your custom page, select
Administer > Site Configuration > Site Information
At the bottom of this page where it says „Default front page” you will have something like this
http://www.example.com/?q= (normal)
http://www.example.com/ (using clean URLs)
and an input field next to it. That is where you have to enter
node/#
where # is the node number that you previously wrote down. By pressing „Save configuration” your front page automatically becomes the previously created page. You can reset that any time you want, by entering only
node
into the input field. (That is the default value).
If you want to promote your page to the front page, you should go back to step 1. but now don't press "Submit", or edit your newly created page (navigate to this address)
http://www.example.com/?q=node/#/edit (normal)
http://www.example.com/node/#/edit (using clean URLs)
where # is the node number.
Either way, at the bottom you will find a drop down menu called „Publishing options”, there you will have to check the „Promoted to front page” checkbox and that’s it. Press „Submit”.
If you really need more control over your front page, you can use the Front module to
You can find the Front module at: http://drupal.org/project/front
After installing the Front module, select
Administer > Site configuration > Advanced front page settings
There the drop down menus are pretty self-explaining. If you click on any of the „Front page for _user role_” you will find
If you are satisfied with your settings, press „Save configuration” and you are done.
Click on "Create content" in the menu, then select what kind.
The title and body are pretty self-explanatory. Below these are a number of collapsible fields. "Input format" controls what you can put into the page; I'm assuming you are the "super-user" (user/1), so give yourself the priviledge of "Full HTML."
If you have Nodewords installed, the next section is "Meta Tags." It's pretty well documented.
Use the log message to provide information that might be useful to other authors who may edit your document later, or provide your rationale for making edits to your own or other people's content. The log message is not visible to users without the appropriate content editing rights.
As logs are recorded on a per-revision basis, each time you revise your content and make a log, the log message is stored with that particular revision of the article only. If you are have editing rights over a page you can see a list of revisions (if you selected the option to make a revision when you edited the document) and their associated log messages by clicking on the revisions tab.
Hopefully, you already set your default "Comment settings" but the front page rarely deserves comments, so you can disable them.
If you turned on the "Path" core module, you'll have URL path settings next. You can enter a "normal" name here rather than being required to use "node/2" when you refer to it later on. Hint: if you are converting a site that was static pages, you might want to go ahead and add ".htm" or ".html" to the name so that the search engines will continue to find the page.
"Menu settings" is the next section. "Title" is what will show in the menu normally. "Description" will show when the user hovers the cursor over the menu item. "Parent item" allows you to create multi-level menus that collapse and expand. "Weight" allows you to set a relative position within the menu; unfortunately, some Drupal core items are hard-coded at 0.
Chances are you won't need "Authoring information" unless you want to attribute the page to someone else. The other use for this section is to control the page or story order when they are based on the time and date it was created.
Finally, "Publishing options," which you set defaults for earlier, right? You want the page "Published" so it will show up. If this is your "Welcome" page, you'll want it "Promoted to front page."
"Submit" it.
Congratulations, you now have some content on your site!
Most of what goes for a page is also true for a story. You can largely consider the two types to be interchangeable, and it is goodness to have at least two content types because conflicts can arise in the way content types are used (for example, taxonomy "collisions").
Stories have a "teaser" or opening statement intended to grab the reader's attention. The length of the teaser is set in one of two ways:
Note: You may see some places that tell you to use
A story probably shouldn't have a menu entry. If you use the general "convention" that a "page" is for static or generated content that stands alone, and "story" is for collections of related content (e.g. RSS feeds, newsletter articles, press releases, etc.), then a story is usually going to be displayed with other stories, so which one would be the menu item? Generally the menu for a set of stories will be a description of how they are selected for display.
You may want to promote the story to the front page. For your "Welcome" message, you probably also want to make it "Sticky at top of lists." Unfortunately, there is no core "weight" feature, so you have to play with the dates and times in the "Authoring" section to control the order. (Or you can use the Weight module.)
This is from a post by zoon_unit on January 10, 2007.
A "teaser" is essentially a snippet of text designed to tell the user the content of a post without reading the entire post. Since most writers have embraced the common journalistic style of explaining the nature of an article in the first paragraph, teasers work well for most articles.
Here's what happens: