Drupal-based website

Content is the primary building block

of any website, whether it is constructed using Drupal or any other
tool in the marketplace. Content is what visitors come to a website to find, and a lack of content is often
the reason visitors fail to return to a website after the first time. In its most basic form, content is any

combination of text, pictures, video, audio, and graphics. An individual piece of content may take a
variety of different forms:
•  news story
•  blog post
•  product description
•  company overview
•  forum post
•  photograph
•  wiki entry
Content on a Drupal-based website often starts with a title followed by body text. In Chapter 1, we
created a basic page, which consisted of content with just a title and body. Drupal provides the ability to
expand on this with a custom content type. A custom content type enables you to create additional fields
that can be used to capture other relevant and related information.

Read More

Drupal's SEO tips

Tthe default SEO options in Drupal provide
you with basic features you need, such as search engine friendly URLs.


1.Configuring your Site Details
2. Creating basic search engine friendly URLs
3. Optimizing URL aliases
4. Controlling taxonomy and tagging
5. Setting up your site's RSS feed


To add a slogan to your site:
1. Access the admin dashboard of your Drupal site.
2. Click on the Configuration link on the admin navigation menu at the top of
the page.
3. In the System section of the page, click on the link labeled Site information.
4. Enter the text you want to use in the field marked Slogan.
5. Click on the Save configuration button.

RSS feeds are an effective way of exposing your site's content both to users and to
the various indexing services. Drupal comes with RSS capabilities; you don't need to
add any extensions to publish your site's content via RSS. You do, however, need to
configure the feed and add the subscription link to your site.

Read More

Drupal-Optimizations

While most optimizations to Drupal are done within other layers of the software stack, there are a few
buttons and levers within Drupal itself that yield significant performance gains.

Page Caching
Sometimes it’s the easy things that are overlooked, which is why they’re worth mentioning again. Drupal
has a built-in way to reduce the load on the database by storing and sending compressed cached pages
requested by anonymous users. By enabling the cache, you are effectively reducing pages to a single
database query rather than the many queries that might have been executed otherwise. Drupal caching
is disabled by default and can be configured at Configuration -> Performance.

Bandwidth Optimization
There is another performance optimization on the Configuration -> Performance page to reduce the
number of requests made to the server. By enabling the “Aggregate and compress CSS files into one”
feature, Drupal takes the CSS files created by modules, compresses them, and rolls them into a single file
inside a css directory in your “File system path.” The “Aggregate JavaScript files into one file” feature
concatenates multiple JavaScript files into one and places that file inside a js directory in your “File
system path.” This reduces the number of HTTP requests per page and the overall size of the
downloaded page.

Read More

Dedicated Servers vs. Virtual Servers

Dedicated physical servers are going to outperform virtual servers when it comes to network I/O, disk
I/O, and memory I/O, even in situations where the virtual server supposedly has been allocated more
resources (CPU, disk, and memory) than a dedicated server of similar specs. An important factor to
consider is that in a virtualized server environment, the CPU, disk I/O, memory I/O, and network I/O
have added I/O routing layers between the server OS and the actual hardware. And, therefore, all I/O
operations are subject to task scheduling whims of the host hypervisor as well as the demands of
neighboring virtual machines on the same physical host.

As a real example, a virtual server hosting a database server may have twice as much CPU power as a
cheaper physical dedicated server; however, the virtual server may also have an added 1ms network
latency (a very real example from an actual Xen virtualized environment), even between neighboring
virtual machines. Now, 1ms network latency doesn’t seem like enough latency to care about, until you
consider that a logged-in Drupal page request may involve hundreds of serialized MySQL queries; thus
the total network latency overhead can amount to a full second of your page load time. An added latency
of just one second per page request may also seem affordable; however, also consider the rate of
incoming page requests and whether this one-second delay will cause PHP processes to pile up in heavy
traffic, thus driving up your server load. Adding more and bigger virtual servers to your stack does not
make this I/O latency factor disappear either. The same can be said for disk I/O: virtual disks will always
be slower than physical local physical disks, no matter how much CPU and memory the virtual server
has been allocated.

Read More

Apache Pool Size

When using Apache prefork, you want to size your Apache child process pool to avoid process pool
churning. In other words, when the Apache server starts, you want to immediately prefork a large pool of
Apache processes (as many as your web server memory can support) and have that entire pool of child
processes present and waiting for requests, even if they are idle most of the time, rather than constantly
incurring the performance overhead of killing and re-spawning Apache child processes in response to
the traffic level of the moment.
Here are example Apache prefork settings for a Drupal web server running mod_php.
StartServers 40
MinSpareServers 40
MaxSpareServers 40
MaxClients 80
MaxRequestsPerChild 20000
This is telling Apache to start 40 child processes immediately, and always leave it at 40 processes
even if traffic is low, but if traffic is really heavy, then burst up to 80 child processes. (You can raise the 40
and 80 limits according to your own server dimensions.)
You may look at this and ask, “Well, isn’t that a waste of memory to have big fat idle Apache
processes hanging about?” But remember this: the goal is to have fast page delivery, and there is no prize
for having a lot of free memory.

Read More

Moving Directives from .htaccess to httpd.conf

Drupal ships with two .htaccess files: one is at the Drupal root, and the other is automatically generated
after you create your directory to store uploaded files and visit Configuration -> File system to tell Drupal
where the directory is. Any .htaccess files are searched for, read, and parsed on every request. In
contrast, httpd.conf is read only when Apache is started. Apache directives can live in either file. If you
have control of your own server, you should move the contents of the .htaccess files to the main Apache
configuration file (httpd.conf) and disable .htaccess lookups within your web server root by setting
AllowOverride to None:

<Directory />
AllowOverride None
...
</Directory>
This prevents Apache from traversing up the directory tree of every request looking for the
.htaccess file to execute. Apache will then have to do less work for each request, giving it more time to
serve more requests.

Read More

Defining a Block

Blocks are defined within modules by using hook_block_info(), and a module can implement multiple
blocks within this single hook. Once a block is defined, it will be shown on the block administration
page. Additionally, a site administrator can manually create custom blocks through the web interface. In
this section, we’ll mostly focus on programmatically creating blocks.

The following properties are defined within the columns of the block table:
bid: This is the unique ID of each block.

module: This column contains the name of the module that defined the block.
The user login block was created by the user module, and so on. Custom blocks
created by the administrator at Structure -> Blocks -> Add Blocks are
considered to have been created by the block module.

delta: Because modules can define multiple blocks within hook_block_info(),
the delta column stores a key for each block that’s unique only for each
implementation of hook_block_info(), and not for all blocks across the board. A
delta should be a string.

theme: Blocks can be defined for multiple themes. Drupal therefore needs to
store the name of the theme for which the block is enabled. Every theme for
which the block is enabled will have its own row in the database. Configuration
options are not shared across themes.

status: This tracks whether the block is enabled. A value of 1 means that it’s
enabled, while 0 means it’s disabled. When a block doesn’t have a region
associated with it, Drupal sets the status flag to 0.

weight: The weight of the block determines its position relative to other blocks
within a region.

region: This is the name of the region in which the block will appear, for
example, footer.

Read More

XML-RPC

A remote procedure call is when one program asks another program to execute a function. XML-RPC is a
standard for remote procedure calls where the call is encoded with XML and sent over HTTP. The XMLRPC
protocol was created by Dave Winer of UserLand Software in collaboration with Microsoft (see
www.xmlrpc.com/spec). It’s specifically targeted at distributed web-based systems talking to each other,
as when one Drupal site asks another Drupal site for some information.
There are two players when XML-RPC happens. One is the site from which the request originates,
known as the client. The site that receives the request is the server.

If your site will be acting only as a server, there’s nothing to worry about because incoming XML-RPC
requests use the standard web port (usually port 80). The file xmlrpc.php in your Drupal installation
contains the code that’s run for an incoming XML-RPC request. It’s known as the XML-RPC endpoint.


XML-RPC Clients
The client is the computer that will be sending the request. It sends a standard HTTP POST request to
the server. The body of this request is composed of XML and contains a single tag named <methodCall>.
Two tags, <methodName> and <params>, are nested inside the <methodCall> tag.

Read More

Create the Other Pages

Now that I have my basic page structure down, it’s time to start looking at the other
pages in my site. Working with the styles I’ve already created (and creating new ones
as I need to), I’ll create the following pages in my layout:
• Blog listing, with the sidebars as used in my two-sidebar layout
• Category page, based on the blog listing page
• Project page, with associated images and text
• Project listing, with images and a brief project description
• Contact page
• A 404 (page not found) and 403 (access denied) page
• The home page, with associated blocks and callout areas
This should cover most of the pages that I will be setting up in the Drupal implementation,
and give me more than enough to work with. Many of the pages will feed each
other—for example, my blog listing page will start with my two-sidebar layout, and
change the listing, and then the category page will follow from that. However, the
project pages, being highly image/case study focused, will require special treatment,
including putting some thought into how I’m going to organize the projects,

Read More

Single Node Pages with Sidebars

The point of starting off your template with a node page that doesn’t have sidebars is
this: you will inevitably have a page like this somewhere on your site. And many designers,
well-meaning as they are, end up forgetting this and assume there will be 1–2 sidebars
on the page. As Drupal’s default behavior reflows the text to fill the entire page when
there are no sidebars, this results in these pages having long and drastically uncomfortable
line lengths.
That said, it’s safe to assume that most pages will have at least one sidebar, and that
the sidebars will contain different types of blocks, for example:
• A list of node titles or categories
• Static text or images
• A tag cloud or something similar
• Callout boxes, like a contact form or customer testimonial
Therefore, while I’m working on my node pages, I should also take a look at how these
different types of sidebar blocks will be styled, and how I’ll set up both one- and twosidebar
layouts.

Read More

Install Drupal

Now that you’ve created your database, go back into your favorite browser (I use
Chrome: http://www.google.com/chrome) and go to localhost:8888/d7-demo/install.
php. Choose the “standard” installation profile for now (see Figure 1-8); it will
take care of some basic configurations for you. On the next page, select English as the
installation language. If you need to install it in another language, there’s a handy link
on that screen that will show you how to do it.

Read More