This page will soon contain a review of the "Drupal Essential Training" video course from Lynda.com. The initial page will include the review portion, synopsis, recommendations, etc. The following pages (which are currently being written while I watch the course myself) will be an "add on guide" to accompany the video series, offering tips, advice, and several important corrections in various topics following along with the videos, with the goal in mind of creating a "complete" learning experience for getting started with Drupal.
The advice on When NOT to use Drupal is sound for the most part, however I want to note that Drupal "can" be used on a very high-traffic or mission critical site, and is used as such by many companies and organizations (a few examples, some of which were mentioned in the video, include Sony MyPlay, The New York Observer, and Popular Science magazine). The key is that Drupal core on its own cannot necessarily handle such a high amount of traffic "out of the box". If there will be a large number of logged-in users at all times on a Drupal site, a number of performance-enhancing modules such as Memcache, APC, and Advanced Cache are usually put into use.
On the other hand, if the site will mostly be used by "anonymous" visitors who don't log into and interact with the site, Drupal's "Performance caching" features (which are built in) can be enabled through Administer > Site configuration > Performance (admin/settings/performance), resulting in Drupal using only slightly more server resources to display the site to those visitors than a static HTML site would. Also, it should be noted that even with caching and performance enhancements, a site of the size/popularity mentioned would require at least one, if not several, or even a whole group of dedicated servers to operate (on any CMS, not just Drupal). Drupal is certainly "less" performance efficient due to its modular design than a custom-coded CMS tailored carefully for the exact needs of a specific site and nothing more, however it is still a viable option for large/popular websites, and its flexibility opens up substantial features and possibilities even for non-professional developers.
Though Drupal, with proper preparation, can run quite huge websites, Drupal would not be the ideal choice for a site on the massive scale of Yahoo, MySpace, Facebook, YouTube, etc (which in fact "no" PHP-based system would be ideal for, as according to PHP's original creator Rasmus Lerdorf, PHP is not the best language from a performance perspective at levels that high).
In Programs Needed on the Server it isn't quite clarified that Apache and MySQL are programs on a server, not separate "servers". In the case of Shared or "virtual" web hosting (which most people have), your web hosting company provides these for you; most often the only time you will need to install or configure these yourself is if you have a VPS or Dedicated server. One thing that was not mentioned though, is that you should choose a web hosting company that supports up-to-date versions of Apache, MySQL, and PHP (as many do not). As of version 7 and beyond, Drupal will no longer support any version of PHP below 5.2. See the GoPHP5.org site for further information.
Also in Programs Needed on the Server, Cron is mentioned as a requirement. Later in the video series alternatives are discussed if your host doesn't offer Cron. Although having Cron available is definitely ideal, the recommended alternative for those on a shared hosting plan that might not have the Cron feature, is called Poor Man's Cron.
Lastly in Programs Needed on the Server, it's important to clarify that neither MAMP or WAMP are meant for hosting a "live" website out on the internet. These all-in-one packages are terrific tools for quickly setting up a Drupal-compatible environment on your home computer, so that you can develop and test your Drupal site much more rapidly. However they should not be used to host a website "live" on the internet. Once "local development" is complete, you should migrate the files and database of the site to your hosting service.
This video gives a good "bird's eye view" of how Drupal works with its files and data, as compared to a static HTML site. One thing worth mentioning is that you should never use the default themes folder to store "your own" custom theme(s). As was alluded to but not yet thoroughly explained in this video, themes (and modules) that are specific to your site, should be installed into the sites folder. Storing your own themes, modules, and files all within the confines of the sites folder will make it much simpler to upgrade your Drupal site in the future. You can learn more about Drupal's sites folder.
One part of this video mentions that the currently supported versions of Drupal include 4.7 through the current major release, 6.x. However in Drupal only the current and preceding major releases are actively supported. This means that the currently supported versions of Drupal are 5 and 6. It's true that some websites still are running Drupal 4.x, however this is not advisable for the average user: no further security patches are released for version 4.7 and below, and if a person/company is still using this version or lower, it is their own responsibility to patch their version of Drupal manually by hand (if possible). This also applies to support/help from the community; although there are some community members who will be able to help with questions and problems with older versions, the majority will not.
The video covers a number of great ways you can jump in and contribute back to the community. One additional area where you can help where there is a significant degree of need in the Drupal community is "theming". If you are a graphic/web designer, and have learned to turn your designs into Drupal themes, your contribution of high-quality themes to the community will be appreciated beyond measure.
One additional important tip for using the Drupal.org website is to pay attention to the "version compatibility" tags at the top right corner of the majority of pages on Drupal.org. These tags inform you about which version(s) of Drupal are being referred to on the page you are reading. This is important to know, since often tips, code snippets, and definitely modules and themes are not compatible across different versions of Drupal.
The description of templates is good but needs a little more info to be complete. There are templates for Content Types, as mentioned, though there are also templates for many other areas of Drupal, such as Taxonomy (category) listings, User profiles, Blocks, Comments, Views, etc. Compared to previous versions, Drupal 6, in fact, has exponentially increased the number of quick and easy template files available to make it easy to theme just about every subtle aspect of your Drupal site without needing to resort to custom PHP coding. Even modules now are able to provide template files which you can copy into your theme directory to override the module's default output. Here's a listing of template suggestions Drupal is capable of (and many others are possible as well).
It should also be noted that although PHP-based templates (called PHPTemplate in Drupal) are the default and most supported "theme engine" in Drupal, other theme engines which might be familiar from other CMSes are also supported, such as Smarty and XTemplate.
The video course does a great job of demonstrating how to quickly and easily set up a local web server environment on your home computer (using WAMP for Windows and MAMP for Mac OS X), which is highly -highly- recommended.
It's as simple as downloading and installing a free program, and worth its weight in gold. It's always recommended to develop your website "offline" on your local computer using these tools, instead of "live" on the real web server. A local server environment allows you to work many times faster than you can on a remote server, and gives you an opportunity to easily back up your site's files/database as quickly and easily as copying a few directories, just like you would with any other files on your computer. This makes it easy to feel free to experiment with Drupal, installing modules, etc - if you make a mistake or a module you install somehow goes horribly wrong, it's a piece of cake to restore your site to how it was before. Even after you migrate your website to a live web server after it's complete, you should still keep one or more "test" copies of Drupal installed on your local server, where you can freely install modules and updates ahead of time, ensuring that they will work before you install them on your live website and risk causing downtime if things go wrong.
The videos in this section are chock-full of excellent and helpful information to help you get Drupal up and running on your computer. Below you'll find a few additional tips on how to get the most out of Drupal on your local installation, as well as one important tip regarding installing Drupal on Macs and other Unix systems.
There are a few pros and cons to weigh regarding setting MAMP's Apache and MySQL ports either to MAMP's custom values or the "standard" default values as used on the web (80 and 3306). In any case the ports will not show up when you upload your site to your hosting provider.
The benefit of changing the ports to the "standard" values (80 and 3306) is that they do not need to be entered in your URLs when you type them in your browser. The downside is that you will need to type in your account password when you start or restart MAMP's Apache and MySQL services. This is because OS X, being a Unix-based system under the hood, actually already has its "own" copy of Apache and MySQL installed and thus reserves those ports by default; however Apple's versions are not as up to date, full-featured, and easy to configure as MAMP's, so for web development it is best to use MAMP's versions. In either case, the port numbers will have no effect on your "live" website when you publish it online. If you already use OS X features such as "Web Sharing", then changing from MAMP's custom ports can cause those features to malfunction, so in that case you might want to leave MAMP's port setting alone.
This sounds scary and complex, but it's actually quite simple and worth doing since it will make Drupal run much much faster - all you have to do is switch on an option in MAMP. While configuring MAMP, go to Preferences, and choose the PHP section. Choose one of the options listed under Cache (it doesn't matter which you choose, though I personally prefer APC or eAccelerator).
In case you're curious, these three options are called PHP opcode caches... you can read about and view some Drupal-specific graphs/statistics on how an opcode cache can help Drupal perform faster, and using considerably less server resources. Most hosting providers/servers will be running one of the three listed here, but you can select whichever you prefer or find to perform best on your own system.
If you're using WAMP, it does not come with an opcode cache by default, but if you'd like to install one check Google for instructions (alternately, you can opt to use XAMPP instead of WAMP, which comes with eAccelerator).
In the video it is recommended that you set MAMP's Document Root to /Users/yourname/Sites/drupal. To keep it simple to follow along with the videos, go ahead and set it this way as recommended.
However, in the future you may want/need to change this if you plan to have any more than one website (which even if you don't have more than one "website" you may still want to have extra copies of Drupal to test with, other CMSes to try out, etc). MAMP's Document Root is a place where "multiple" websites can exist, not just one (each folder within the Document Root can be a separate website). So later after you finish the video course and begin working on "your own" website, I suggest changing MAMP's Document Root to be only /Users/yourname/Sites. In the Sites folder you will still have a sub-folder called drupal (where the video course's Drupal installation is located), but you can also add as many other websites as you wish as well. You'll be able to access any local website with an address like this: http://localhost/drupal or http://localhost/another-site.
If you're installing Drupal on MAMP, then the default MySQL user is root and the password is root as well.
On a Mac/Unix-based system, you should not drag and drop Drupal's files into another folder in the way shown in the video. There is a hidden .htaccess file included in Drupal's root directory when you extract it, which gets left out if you copy the contents of the folder this way. On Unix systems (including OS X) files that start with a period are hidden by default (on Windows however, the .htaccess file will show up like a normal file and not be hidden, as that is not how Windows hides files). In the video, the files/folders are manually dragged and dropped out of the extracted drupal-6.3 directory on the Desktop and into another "drupal" folder that was prepared in MAMP's Document Root. Unfortunately, the hidden .htaccess file does "not" get copied along with everything else, since it's not visible to be selected.
This won't affect you if you're working with Windows to develop your Drupal site, however it is still a very important concept to understand, since when you upload Drupal to your hosting service online, it will in all likelihood be on a Unix-based server, and the .htaccess file will disappear as soon as you upload it. It's still there however and is crucially important to Drupal. Many FTP and SFTP programs have a feature available to "show hidden files", which I strongly suggest you turn on. This is important to understand in general, regarding all web development on Unix-based servers, including all CMSes not just Drupal.
So, if you are installing Drupal on a Mac or any Unix system, then the best way to ensure that the .htaccess file does not get lost during installation is to place Drupal's tar.gz archive file which you downloaded into the parent directory of where you want Drupal to be installed, and then double click to extract the archive right there and do not move or copy the folder's contents. You can also move the whole folder to any other location, but do not move only the "contents" of the folder, or the hidden .htaccess file will not come along for the ride. When Drupal's folder is extracted, feel free to rename it however you prefer (e.g. from drupal-6.3 to drupal, YourSiteName, or whatever you like). You can most easily check to ensure that the .htacccess file is present by using a code editor that supports viewing hidden files, such as the amazing, cross platform, (and free) Komodo Edit.
How to fix your .htaccess file if you already dragged and dropped files to install Drupal:
If you did drag and drop the files and folders while installing Drupal on OS X (or another Unix-based system), and have found your .htaccess file to be missing, the easiest way to replace it is to extract another temporary copy of Drupal, open its directory in Komodo Edit (or similar), open the .htaccess file you see, copy and paste its contents into a new blank file, and then save that file with the name .htaccess in the root of your Drupal website.
(Need to double-check) The video mentions that you can simply rename default.settings.php instead of making a copy and naming it settings.php. My experience has been that default.settings.php has to remain, so making a copy and renaming that is advised.
While setting a memory limit in php.ini, I recommend that you set this to a higher value, so long as your hosting provider supports a higher value; some more memory-intensive modules you may want to use might tip you past 16M, so if possible, set this higher to something like 24M or 32M. Don't set the value in your local server higher than your hosting provider supports, or you may find your Drupal site will not run when you move it online (when Drupal exceeds the memory limit, this is often jokingly referred to as the "white screen of death"). To find out the memory limit that your hosting provider supports, create a new called phpinfo.php and add the following line into it: <?php phpinfo(); ?>. Upload the file anywhere on your online web server, and when you visit that address you'll be presented with your host's PHP configuration settings. Search for "memory" and you should be able to find out the top limit they have set. If it is too low, you might want to consider contacting your host to see if it can be raised, or else consider seeking out a new hosting provider. Be sure to delete the phpinfo.php file from your server right away, as it is insecure to leave it lying around.
Both the Windows and Mac videos cover how to install Drupal under each respective operating system. If you're a Windows user, I'd still encourage you to watch the Mac videos, as they offer a bit more detail in various steps compared to the single Windows/WAMP video. If you skip the Mac videos you may miss some important and helpful tips. Overall these videos answer a great majority of the questions Drupal newbies often run into while installing Drupal.
While I recommend watching the video about Cron to get a more advanced look at how Cron works, don't sweat it if Cron leaves your head spinning.
First, you should decide whether you actually "want" to run automated Cron jobs on your local server (you definitely want to run them on your online server, but you can decide with your local server). For one, they will only work while the local server program is running (MAMP, WAMP, etc), which may not be all the time. Also, some tasks Cron can perform in Drupal can potentially be CPU-intensive depending on the modules you have installed in Drupal (such as converting videos, etc), which could cause a slowdown for your system at an inopportune time. Instead you might prefer to run Cron manually on an as-needed basis while you're working on your site, instead of having it suddenly run at other times while you're not working on your site. If you'd rather just run Cron manually on your local server, you can do so at Administer > Reports > Status report, and clicking on the "run cron manually" link.
If you decide that you "do" want to set up Cron to run automatically on your local server, there are some programs available that make it easier to configure than by dealing with the command line:
When it comes time to publish your Drupal site online to your hosting provider's server, there's a good chance that your web host offers a simple tool within your hosting control panel (such as with cPanel) to allow you to specify the command to run, and then choose the time(s) to run it using a more friendly interface. In more rare instances you may have to configure Cron using the command line, and if so, then this video should prove very helpful.
The steps outlined in the video for enabling mod_rewrite (which is the Apache program that makes "Clean URLs" otherwise known as "search engine friendly URLs" possible), are not generally necessary (though handy to know, if you do need to troubleshoot). The steps outlined in the video were necessary due to the .htaccess file being missing from earlier in the installation. Please ensure you read and follow the advice in the previous section of this guide regarding properly installing Drupal's files on a Mac or other Unix-based operating system.
So long as your database is relatively small, phpMyAdmin will suffice for backing up. However a larger database has the potential for causing phpMyAdmin to time out before completing the backup, causing the backup to fail. If this happens, you can run the mysqldump command using the OS X Terminal, or Windows command prompt, which will not time out with large databases. Also, while you cannot do this on your "live" Drupal site once it is uploaded to your hosting company's server, while working on your local server Drupal's database is stored in a directory on your computer, which can be copied and pasted to backup whenever you want (in MAMP, the location is /Applications/MAMP/db/mysql/yourdatabasename).
If you're using a Mac as in the video, in order to ensure that all hidden files (such as .htaccess) are properly included when you backup your site, I'd encourage you to right click (control click) on your Drupal installation's folder and choose Compress "yoursitename". That will immediately make a compressed copy of your site, including the hidden files. You won't need to make a copy of the files first.
It's important to note that you should never "test" your database backup by removing your real database and importing the backup in its place. Learn more about how to safely test the integrity of your backup "without" risking your real data: (add link to article)
This video outlines how to update Drupal core from one version to another, as well as how to update a module. As with originally installing Drupal, the .htaccess file was left out accidentally, so you will want to keep that in mind.
Through it is recommended in the UPGRADE.txt file that comes with Drupal, in practice it is not actually necessary to disable all contributed modules and themes before running a "minor upgrade", for example 6.3 to 6.4 (and on a complex Drupal site would become an significant hassle to do every time if it were required). When you upgrade to a new "major" version of Drupal (for instance 5 to 6) however, then you should definitely disable all contributed modules and themes before upgrading.
Regarding updating a module, one step was left out, which was to run update.php after copying the new module's files (update.php is responsible for updating the database tables of modules as well as Drupal core). Not all modules require database updates every time you upgrade them, but many often do. It is a good habit to always run update.php after installing a new update for a module.