With Drupal being an open source software and having such a great set of features right out-of-the-box, people may wonder what they pay for when going to an expert Drupal developer or shop for their Drupal install.
A good Drupal site may cost thousands of dollars. For an enterprise level site the budget may be in the hundreds of thousands of dollars. What’s that all about? I thought Drupal was “free”. The following is a bit of explanation.
Most web site features are already built into Drupal and ready to be configured. With professional Drupal development you are not paying for features, but rather expertise. What expertise?
Professional Drupal developers and shops offer expertise in Drupal site:
Just read, “Everything You Know About CSS Is Wrong!” http://www.sitepoint.com/books/csswrong1/
Less a book, it’s more a combo essay and tutorial on why we must design for the latest browser standards rather than still using old IE hacks, and a how to use CSS tables to do it. Most of the content may be easily found on the net.
However, it’s a good single source of the necessary information in a brief read.
The following post is an answer I wrote to a question submitted to Tree House Agency in preparation for Do It With Drupal (New Orleans 2008). Tree House has kindly given me permission to post this material on my own website.
Q: One node, varied displays?
BH asks:
What are the best practices for rendering different types of node displays?
Short Answer
Three methods immediately come to mind. These are:
I built a Drupal theme I call “chi”. It is based on the Yahoo! YUI Grids CSS foundation. Like the excellent “Zen” theme already written for Drupal, a Drupal theme based on Yahoo! grids CSS can offer an excellent starter theme for Drupal developers and themers.
I recently posted a summary on the benefits of YUI Grids CSS for Drupal theme developers on my blog. You can view it as a screencast, PowerPoint presentation, read a text summary, or download a PDF from this URL:
I have included a zip file of the theme code at the end of this post for you to review.
I’ll highlight a few sections of the code and features in the screen shots below.
First, this is a Drupal 6 theme, which utilizes an .info files for themes. A number of theme elements can now be defined within a simple text based .info file rather than within the code of a template.php file. Here’s a screenshot of the included chi.info file.
Note that regions and theme style sheets may be defined in the theme.info file. One important catch is to define the CSS files in the order in which you would like them to load. They are like defining an array in PHP or Java. So, when including a file sheet which resets all fonts and html elements to a base starting point, and then including a style sheet which builds upon that base reset, the load order needs to be considered.
Let’s look at the file titled, “page.tpl.php” to see how created the Drupal theme from an existing pre-defined grids template. Besides a review of knowing how to place Drupal template variables in the appropriate places to create a theme, there are few things I’d like to point out within this file.
First, at the top, you’ll see this code snippet:
I have made use of the theme settings api to pull a few options into this theme, so that in the section below, the actual doc id which defines the page width, and the main div class which defines the present template (affecting what side the sidebar appears), may all be defined dynamically.
Then in the file titled, “theme-settings.php”, I define the theme settings UI elements for the end user to change their theme settings. Note the theme API options are set by using part of the form API. Below is a small sample of the code.
The total code in the file results in the following settings UI for the end user:
If you look over some of the other tpl files, you’ll notice where I have tweaked the default html or template here and there to move some of the Drupal elements around.
For example, in the node.tpl.php file, I changed the default Drupal node display as follows:
Moved the meta info, such as “Submitted by:” to the bottom of the content instead of the top.
I moved the vocab terms and links to the bottom of the page/node
I added my feed burner JavaScript, along with some PHP, to have my feed flare display at the bottom of each post. See the second image below.
The following are samples of database work I have done. I have attached a sql file as a sample. It is a dev snapshot of a CMS I wrote.
So you don’t have to just stare at sql statements, I have highlighted some points in this post. I will paste sections of the sql statements and then comment on them.
An important patch if you find your vocabulary terms fail to be listed within your external client: Category Fix Patch
Forums thread discussing issues with setting up Windows Live Writer with Drupal 6. Following the steps outlined above, you will avoid these issues: Windows Live Writer and Drupal 6
Rapid application and web site development. Increasing demand for web standards. New standards and technologies appear, grow, and morph together within shorter and shorter cycles. Webmasters must be more productive than ever.
These seven tips will help you become a more productive webmaster:
(Modified slightly from the version on Web Worker)
Quick compose tip:
The Task: Set up a quick compose bookmarklet in Firefox to send an email within Gmail.
From within your Gmail account,
1) Click on "Compose Mail" in Gmail, and then click on the "New window" pop-out button on the right hand side of the compose area to bring it to a new window;
2) Once the new window has opened right-click on any part of the blue space within the opened window. In the drop down menu that opens, select "Bookmark This Page" and save it in your Bookmarks Toolbar folder.
3) Minimize the compose window. On the Firefox bookmark toolbar, right-click on the new bookmarklet you've just created, select Properties and check "Load this bookmark in the sidebar".
Now just click on this bookmarklet at any time when you want to send yourself a new task, or send someone else a quick email.
The Archdiocese Orthodox Christian Archdiocese of North America (Archdiocese) wanted to use its Antiochian.org web site to promote awareness and understanding of the Orthodox Faith and the work of the Archdiocese. They needed a web site to serve as a tool for effective communication to various audiences, including persons within the Archdiocese, other churches, the general public, and the press.
The site had to be easy to use for site visitors and for those who added content and administered the site. The site’s appearance and user experience needed to be pleasing, as well as serve to further communicate who the Archdiocese is as an organization and as a church.
Sections of the site needed a cohesive look and user experience, to communicate unity across its many departments and organizations.
Web site accessibility was also an important consideration when developing the organization’s site.
The Results
Successful migration of the organization’s main web site from a large static html site to a Drupal powered CMS, realizing the following benefits:
A web site based on a system and standards that are widely supported in the business and non-profit communities, providing many new support options
A standardized system to make updates in a timely fashion and provide better support
Improved search capabilities for visitors to easily find content relative to their interests and needs
A better audio system, improved video postings, an easier way to syndicate content and to enable users to subscribe to the site content
Significant Growth
87% growth in the number of unique visitors to the site each month, for a number of consecutive months, with steady growth continuing
375% increase in the number of pages the visitors are reading on the site each month
In other words significantly more visitors reading significantly more pages on the site.
The Old Site
Today's Site
More Pages with Better Content Resulting in Better Search Engine Ranking
Antiochian.org now has over 4,000 pages of quality content, indexed and searchable for visitors.
The site has gone from not being in the top one hundred search results for its key terms on any search engine, to being number 4 on Google, number 4 on MSN, and number 1 on Yahoo.
Proper Configuration Checks for External Applications to Use Taxonomy Terms
If you want your users to be able to assign terms to their content when they are using an external blogging application, like Windows Live Writer, make sure you have the Taxonomy module enabled, and that you have selected the appropriate content types, those available to the Blog API. I have forgotten to do this a few times when adding a new content type to use with the Blogging API. Each time a new content type is created, taxonomy requires you to go back and specify whether your new content type can use a vocabulary.
If you have Drupal’s Path Module enabled to allow users to rename URLs (custom URLs), I recommend using the “Pathauto” module in combination with your external blogging client. You can set it to give the content a URL based on the post title.
