Mar 16th, 2012 | Google, Libraries, Web Design | 993 Comments
Canton Public Library's Catalog uses a large library application called Millennium ILS from Innovative Interfaces, Inc. Recently, I undertook to spruce up the images, styles, and JavaScript for our catalog, and in doing so realized substantial speed increases catalog-wide.
Note: The speed enhancements below are mostly about optimizing files and client-side stuff. You can also speed up your catalog on the server side with hardware and database optimization, though doing so is likely to require assistance from Innovative.
Why
Faster-loading pages make users happier. Some speed-enhancing techniques also increase server performance and decrease the amount of bandwidth used. Page speed also factors into search engine rankings, though that is less of a concern for our catalog than our website.
How
Most of the improvements came from Google Page Speed recommendations.
Sprites
Fact I found interesting: Before I applied the catalog changes, the directory contained 682 files. It now has 49. Having fewer files doesn't inherently speed up the app, but it does speak to the nature of the changes.
There are two types of images in a Millennium "example set": icons (or whole buttons as images) and media type indicators. A typical setup, until recently, had 145 or so button images. The most recent example set available from Innovative has 45 icons and a couple support images for making buttons. These images are coupled with some crufty markup to make the buttons work. The latest set also ships with 39 media indicators (in fairness, we'd use maybe 13 of those for our library).
CPL now has one image for all the icons and one image for all the media indicators. In total, the catalog screens have 8 images: one is required but never used, another never seen, and two others used infrequently. Yes, we grab book jackets from an external service, but that's the extent of the catalog graphics.
An individual example icon weighs in between 600 bytes and 1.3K. Our icon sprite is 5.44K. It can be loaded once and cached on the user's machine. For pages with many buttons, this results in far fewer HTTP requests and a smaller total payload. The same goes for media indicators.
How do we pull this off? We use two spriting techniques: 'traditional' sprites and pseudo sprites. The styles to makes these work can be found in the catalog stylesheet. What's novel, and how you can pull this off in Millennium, is in carefully crafting what're called 'wwwoptions':
# pseudo sprite example
ICON_BUT_REQUEST=<span class="but icon request">Request</span>
# traditional sprite example
IMAGE_MATTYPE3=/screens/spacer.gif" class="media-icon bookmp3
As you can see, in both cases activating sprites involves appending classes to a particular HTML element. In the case of the pseudo sprites, there's a class that makes anything look like a button, one that pads the left-hand side and loads the icon sprite image into the space, and one ['request' above] that stipulates where in the sprite image the request icon appears. In the traditional sprite, the "IMAGE_MATTYPE3" option must be an image. Since there's no getting around that, I used a spacer gif. It's 43 bytes — the smallest practical image for the web. I then circumvented the wwwoption to add the classes to the image. Those classes set the background size and position the sprite image.
Be advised that pseudo sprites only work in standards-compliant browsers and IE8+. If a substantial number of your users are on IE7-, you may want to wait. Users with non-supporting browsers can still see the button style we use, but the icons won't appear. Sites that work for everyone but look better for modern browsers are considered progressively-enhanced; that's what you can consider these buttons.
Distrusting Bowker
We use Syndetics Plus, Librarything for Libraries, and Google Books previews on our bibliographic record pages. That's a lot of stuff to load. As part of an overall improvement in JavaScript performance, we changed the way we pull in those resources.
Syndetics Plus, by default, loads onto a page something like this
- Page calls widget.js directly, via a script tag
- widget.js loads jQuery from Google's CDN
- After jQuery is loaded, widget.js loads widget_connector.js
- widget_connector.js gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.js
- widget_response.js writes to the page and asks widget_connector.js to do stuff
This is a mess. It's a long chain of serialized resources that aren't well-cached by the browser, aren't served minified and/or gzipped, can't be served over SSL, and that block full page rendering until they're complete (whether or not there's a result). Total payload for this process is 49K.
Librarything for Libraries is even worse (here I go again). It goes:
- Page calls widget.php (served as javascript) directly, via a script tag
- widget.php loads connector.php
- connector.php pulls in connector_LB.css
- connector.php gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.php
- widget_response.php writes to the page and asks connector.php to do stuff
What makes this process so awful is connector.php. It's over 150K all by itself, and it includes the sizzle selector library and a bunch of other utilities. Which makes one wonder — why not just use jQuery? Moreover, why does a file that loads a comprehensive selector engine need to define getElementsByClassName()? connector.php's JavaScript is a Frankenstein's monster of code that pollutes the global namespace. I'm afraid that some people might be having nightmares over it. This file also includes all functionality for all different ILSes (not just Millennium, the one we're using) and all LTfL features (a small fraction of which we're using). This massive file is unminified and uncompressed and is part of a call chain that doesn't support HTTP keep-alive. Minifying the file wouldn't solve all the problems, but it would be less than half the size (mostly because their variable names are massive). Ditto on gzip compression, which could make it less than a quarter of its heft over the wire (without minification!).
We pull in jQuery from Google (the old-fashioned way, so it client-side caches for just about ever) and use it for almost all the (CPL-made) JavaScript on the page. The code for us to replace Syndetics Plus's payload (25K without jQuery) is 150 bytes before compression. The nearly 200K for LTfL? Less than 1K, and I could probably optimize further.
CPL-specific code pulls the primary ISBN from bib record pages, validates it, then makes sure the page is served as regular HTTP. All of this occurs after the page has already loaded. If the conditions are met, we then feed the ISBN to the widget_response files from the two services, getting back just the results specific to the bib record. The widget_response files handle writing to the page all by themselves, so the service-specific code just adds things those scripts expect to find and handles certain on-page actions. Since we do this all asynchronously, the page loads (and feels like it loads) as quickly as Millennium allows.
Being careful with the three widget services provided the biggest overall improvement to payload size and page rendering speed. Google Page Speed eliminated the warnings about redirects, uncompressed resources, request serialization, unminified javascript, and undeferred scripts.
What's funny about the terribleness coming from Bowker's servers is that a big part of improving the situation is both easy and a big sack of win. Users would get faster pages and Bowker'd save on bandwidth and hardware specs. Some quick apache config of mod_expires and mod_deflate is all that's required to pay dividends. A deployment scheme involving minification and/or a refactor of the connector scripts would be more time-consuming, but could make the widgets substantially faster. Serving out static scripts without query strings would be a huge help, for instance.
More JavaScript Optimization
I was more diligent about jQuery best practices like using fast selectors, caching selected objects, and delegating events to their appropriate containers.
Millennium has its own JavaScript library. It's ordinarily served out as 3 files, but we weren't having any of that. Our Millennium setup prevents the default files from loading, and instead serves a single file with all three components minified. iii.js is just under 20K before compression, and 5.2 over the wire. That's 2 fewer HTTP requests and 4.4K less payload on every page.
Image Optimization
I ran all the catalog images through PNGGauntlet, which uses PNGOUT to reduce file size — sometimes by 25% or more. For high-use files, I also weighed the quality reduction of making them 8-bit PNGs; the sprites, for instance, get served out as 8-bit files, making them substantially smaller.
Web Server
I also rolled out a sprite for the site's layout and theme, optimized the chat widget, and combined and minified CSS files for use by the catalog. Our web server, in contrast to the catalog, is pretty aggressive about caching. Files are served with far-future expires headers. APC for PHP caches the opcode to minimize file reads; this results in faster execution speed across the board, but not necessarily faster serving to the end user. We have drupal caching set up, which benefits from MySQL query caching. Apache gets some love from the OS's buffer cache. Altogether, the website is a layer of caches.
What's Next
I'd like to reduce the payload of every page on our site by rolling out a new theme. There's a lot of extraneous markup and styling that can get cut out pretty easily. Other possibilities:
For the catalog, a few squeaks of extra speed could come from moving static files to our web server (which has longer cache lifetimes), combining the [minified] catalog CSS into the site CSS, and working with Syndetics to get book jackets from URLs without query parameters.
tl;dr
Google Page Speed.
Dec 9th, 2011 | Web Design | 1,085 Comments
I'm honored to have been selected to present at the first-ever DrupalCamp Michigan. The local Drupal community is super strong: they opened registration for 50 people and it sold out so quickly they expanded to 100. Not being a good public speaker at all, you'd think this might be daunting. However, a combination of under-preparedness and lack of sleep really put me in the right mindset. So, without further ado, here are the slides and a video of the presentation:
Notes
You've got the wrong guy
I originally proposed this session not because I have a ton of experience on the topic and all the answers, but because I wanted to use presenting as an excuse to learn about git.
If you've been using git for a long time and/or have memorized large portions of the Drupal APIs, chances are you won't be able to learn much from me.
WTF is a git!?
The word git was first a British slang word for an annoying or stupid person. The software was named self-deprecatingly from that word. I like to think git stands for something else though: good shit.
Git is a fast, distributed version control system.
It was originally developed by Linus Torvalds in 2005 to be used for developing the Linux kernel
If you've used another version control system, you might wonder what sets git apart.
From what I've gathered, the most important differences between git and other systems are:
- Git is distributed — this is important, because having a local copy of a repo lets you access the version history easily, commit whenever it makes sense, and push it to one or more repositories, or remotes, based on the structure of your project
- Git reduces the pain of merging, which means that you can make lots of branches without worry
Other systems, like CVS, subversion, and others, are also considered slow for accomplishing certain tasks. While I don't have a great means of comparison, git seems pretty quick to do most everything.
Drupal and Git
The Drupal project switched from CVS to git in February 2011. The changeover is a 3-phase process, of which they're on phase 2.
- Phase 1 was a git mirror, so that people could test and develop in git without affecting the project
- Phase 2 is a centralized model based entirely in git
- Phase 3 will be a decentralized, GitHub-like model that will change the Drupal.org contribution workflow. Details are still being hashed out on that front
Local Tools
Locally, there are a few tools that can make routine tasks fast and can integrate with the tools you already use.
I'm a visual, GUI guy, especially for menial tasks. So I like TortoiseGit on Windows, along with a Git plugin for Notepad++. TortoiseGit makes pushing changes a job of a few clicks. The Notepad++ plugin lets me press Ctrl+Alt+C, type a commit message, and click a button to commit changes to one or more files. If you think vi is a pain in the butt, tools like these are for you.
Remote Tools
It's probably not just you doing development. Even if it is, there's a compelling reason to have at least one central place for your repositories, which I'll explain later.
But a side reason to have bare remote repositories is that you can use tools intended for remotes, like redmine. Tools like this add another layer for project management. You can do project planning, bug tracking, wiki documentation, and other such tasks from a web interface, letting either you or your team keep track of things. And if your project is out in the open, you can leverage a much larger community using sites like GitHub, Google Code, or SourceForge.
Your First Repo
Let's say you have a directory of files that you want to put under version control at that path. You'd go there in your terminal, then initiate a new repository. Next you'd add all the files. Those files are queued up and ready for the first commit, which you then perform.
If you don't use the 'm' option to add a commit message, the commit command will show the log entry for the commit in vi, and you put the commit message at the top. It's at this point that I'd like to reiterate that vi is a pain in the butt.
So that's how you create a new repo from bash
Commands
These are the git commands you might use in day-to-day work
*Point at commands and explain what they do*
^ Learn what the commands do
These commands are used less frequently (in general), but it's good to know about them
bisect lets you determine where a bug began in the revision history, using a binary search to split the possibilities in half each time.
These are also git commands, though you might not use them very often or ever.
stash is commit for wusses
Workflow
So let's talk workflow.
At my job I've got two Drupal sites: "Beta," which isn't really the right name for it, since at times it's a dev box and at others it's a beta-slash-QA machine.
And the live site.
The design and development parts of my job revolve around creating modules and themes to add functionality and enhance the design of just those two properties.
I'm guessing that's NOT what your jobs are like. I'm guessing you make lots of sites. And those sites in various states exist in multiple places, like your local dev machine, an internal server for testing, and external hosting that you don't necessarily control. I don't envy you.
Wherein I Tell You Not To Hack the Core
A site is Drupal core, plus contrib, plus the data in your database.
Since Drupal is modular and nearly everything can be changed via hooks, it's really pretty rare that you have to change anything in core. And if you do, I've found from experience that it's usually for temporary debugging rather than for permanent changes.
Do not hack core.
Avoiding Temptation
So from Do Not Hack Core we can take away that all the things on the left are things you shouldn't mess with, and the thing on the right is the only place that customizations go (unless you have a weird multisite setup, which is cool, but your workflow's going to be different).
A repo at the whole site level is redundant, and reinforces the opposite of the number 1 best practice of the Drupal site-building community.
Drilling Down
What about at the 'sites' level?
This is workable, but you might notice something immediately.
Look at the sites/all/modules directory.
You're probably not going to be hacking contrib either! All of those modules are version tracked in git on the drupal.org site. The vast majority of those modules require zero coding to work exactly as expected. Putting them under version control doesn't accomplish much.
Then there's sites/default
sites/default/files contains uploaded and attached files. Those files are site-specific and are subject to database dependencies. The files also tend to be images and other files that are unlikely to change. There are a number of reasons why version controlling those files is impractical.
On the other hand, sites/default/settings.php is a good candidate for revision control individually, as it's something that you have to work on in the development process, and some of the settings will likely have to change depending on where the site lives. The branching model of git could be really useful for this purpose.
.gitignore Files
One way to wrangle sites/default/files and streamline the process is with .gitignore files. With a well-made, well-placed .gitignore file or two, you can continue using git add . and git commit -a without adding stuff you don't want to your project.
.gitignore files let you choose files to omit from the versioning index, based on wildcard notation. So instead of omitting /sites/default/files wholesale, for instance, you could just selectively ignore boring images and junk while preserving the directory structure wherever the repo might end up.
What You're Controlling
Conceptually, the two components that you're likely to work on that can most benefit from version control are:
- Customizing the theme to the client's needs
- Developing custom modules or modifying one or more contrib modules
If you start with a working theme, like Zen, you can clone down a repo from Drupal.org and use the history of that particular part of the project if you need it. You can create your own branch for your theme and develop from there.
If you code up a custom module, it might only be useful for a single site a single time. But maybe the functionality you add is something that other clients might want, or that can be contributed back to the Drupal community. Modules are reusable pieces, so structuring your repository environment to make them accessible for all sorts of projects is a plus.
Hypothetical Model
Here's an example of what repositories on a central server might look like.
I made the directory structure here very flat, putting core, modules, themes, and the site_projects repositories all within a single folder. This would work well if you always use the same base theme along with a limited number of custom modules. This particular setup plays nice with management software like redmine, which is one reason a flat structure is attractive.
If you're going to have lots of distinct themes and modules, it might be helpful to create big repos called modules and themes, then use git's submodules functionality to manage the individual drupal modules contained within. Thanks Ben for the submodules tip!
Now that we have a central place for all the things we're working on related to building our sites, we can optimize our workflow to play nice with version control.
Leveraging Synergy
One way to do that is to set up pushing and pulling.
If you don't already have ssh keys set up between your development box and your repository server, setting that up will make it a lot quicker to push and pull from git. If you want to deploy via git from the repo server to other machines like your site testing server or even live web server, you'll also want to set up ssh keys between the those boxes.
On your local dev box, use the clone command to make a local version of the repo on your server. When you do that, the source repo becomes a 'remote' called origin.
Make some changes to the local copy (you can branch if you want to, you can leave master behind). When you're done making changes and they're ready for other people in your shop to see/use them, use the push command to send them back to the origin.
Drush Make and Install Profiles
Once the changes are on the server, you can pull them to your deployment boxes, or...
You can get fancy.
It's a common use case: you end up using the same base theme, modules, configurations, and other tweaks on most of your projects. You might already have an "install profile" informally; Drupal with all the stuff you use all in one place.
The "drush make" command lets you generate makefiles that turn your informal install profiles into the real deal. In Drupal 7 it's easier to make profiles that configure things on install, but technically it should be possible in D6 too. Some combination of the features, strongarm, context, and other helper modules could let you automate some impressive stuff — like pre-built views.
Hint: it might be manual coding work, but if you install a whole bunch of similar sites, writing a [profile name].install file could be a time-saver in the long run. Especially if you swipe one from an existing public profile and suit it to your needs.
You can use the drush make command to import all the dependencies for your profile wherever you need them. Then just run the installer (which if you're super fancy you could get working with drush site-install) to have a functional site in the time it takes to make a pot of coffee because your junior dev doesn't know proper coffee machine etiquette.
The makefiles are really flexible, so you can choose particular version numbers of modules for compatibility, apply patch files to change modules or core code, or grab external libraries from tarballs.
Nailing down a "holy grail" workflow for this sort of development takes time and effort, and I certainly don't have all the answers.
Over the next few weeks, Alex Fisher and I will be working on drush make and workflows, and will report useful findings to our respective blogs.
You may also ask about how to go from local dev to testing to quality assurance to live, all while easily managing your databases. You may ask that, but I don't have an answer. Sorry.
Pay it Forward
If you'd like to become a core developer or get involved in a contrib project, a working knowledge of git will help.
I'm fighting the urge to give nitty-gritty details here, as the instructions are both technical and well-documented. If you're not a project maintainer, contributing code involves creating patch files based on numbers from the issue queue. If you are a project maintainer, you can interact directly with the remote repo (albeit while following the guidelines).
One reason I'm avoiding an in-depth explanation is that the Phase 3 git migration could very well change how things get developed on Drupal.org.
But here's how to create a patch file, just in case.
Just one commit is the easiest for contributing back patches.
The Version Control tab on project pages gives really good instructions for grabbing source repos and other contibution tasks, including the specific clone command you need to grab a local copy of the repository.
So now that you're a git expert, go out there and contribute back to the Drupal community!
Thanks for putting up with me!
Apr 27th, 2011 | General, Web Design | 794 Comments
Chris Coyier posted a nice, working solution to a real problem over at CSS-Tricks. Basically, CSS lets you style your website to look and work well on mobile devices by over-writing the styles of your full-size website. There are performance drawbacks to this approach, but for the most part it's the best-of-all-possible-worlds solution.
One thorny problem, though, is over-riding the style of certain elements that use the width of the screen liberally by default. One such element is the venerable data table.
Coyier's solution is great in that each table cell is labeled. However, doing this requires either writing CSS manually for every data table on the site (which is near-impossible for large sites) or having the same thing done with scripting on either the server or client side:
I propose a generalized solution that requires no scripting whatsoever. The drawback of this method, though, is that the cells are not individually labeled. The example is also more compact, but this aspect can be tweaked by marrying the two methods:
@media screen and (max-width:720px){
table{display:block;}
td,thead th{border-color:#444;border-style:solid;border-width:0 2px 0 0;display:inline;float:left;}
td:last-child,th:last-child{border-right:0 none;}
thead th{background:transparent;font-size:1.1em;}
tr{display:block;float:left;clear:left;padding:6px 0;width:100%;}
thead tr{border-bottom:4px solid #444;margin:0 0 .3em 0;padding:0 0 .2em 0;}
tbody tr:nth-child(even){background:#ddd;}
td:nth-child(5n+1),th:nth-child(5n+1){background:#FFD8D8;}
td:nth-child(5n+2),th:nth-child(5n+2){background:#FFE8D8;}
td:nth-child(5n+3),th:nth-child(5n+3){background:#FFF8D8;}
td:nth-child(5n+4),th:nth-child(5n+4){background:#D8FFD8;}
td:nth-child(5n+5),th:nth-child(5n+5){background:#D8D8FF;}
}
Open the working demo and resize your window to under 720 pixels wide to see the effect. I call this approach the "Rainbow Tables" method 
Thanks to Chris Coyier for posting a thoughtful working solution, and thereby motivating me to post about my approach after sitting on it (in production no less!) for almost a year.
Mar 3rd, 2011 | Libraries, Web Design | 842 Comments
I'd like to touch briefly on a widely-circulated LJ post by Aaron Schmidt entitled Resist That Redesign. It is generally good advice – using iterative website design rather than relying on complete redesigns. However, I think the advice needs better context.
For one thing, most library websites are really outdated and bad. Comparing the design/development workflows of Apple and Google (nice!) or Amazon and Netflix (not exactly gems of design) to how libraries maintain their sites is apples-to-oranges. If a library has a flat-file website (Not a straw man: this is common in libraries!), performing a complete redesign/redevelopment is probably advisable. A "slowly evolved" CMS developed in-house at a library is likely to be slapdash, and there are tons of available CMSes that are well-designed, secure, free, and supported.
What's not mentioned in the original post is that redesigns don't have to be long, painstaking processes. Bad redesign processes are that way, but a sufficiently-experienced and talented designer can ease those woes. The solution for doing a good redesign is to have a good designer.
Likewise, iterative design isn't always a breezy process, and it often isn't design. Design needs control; website creative control is often lacking in library environments. What often ends up happening under the guise of "iterative design" is actually a patchwork; sometimes from having too many cooks in the kitchen, sometimes from having one crummy cook. We've all seen these websites; they start out clean and freshly-designed. Then someone pastes in a widget and it clashes with the design. Then comes more widgets ad nauseum until the site looks and works awful. As such, the solution for doing good iterative design is to have a good designer.
Library folks: don't resist redesigns. If a well-designed website is important to you, hire a good web designer. Trust their judgment to decide whether the best course of action is to iteratively improve your site or to do a full redesign.
Jun 23rd, 2010 | Web Design | 1,069 Comments
Here are the slides and notes from my June 16th presentation for Refresh Detroit. I was fortunate enough to be joined by Alex Fisher and Stephen Colson, who really brought everything together and luckily had all the answers. Thanks again, guys.
The following notes do not reflect the actual presentation. If video evidence comes along to prove this, I will add it to the bottom of the post.
Slide 1 - Welcome
Hey, I'm Brad Czerniak. I'm the web guy at Canton Public Library.
Thank you very much for coming to see this presentation today. And especially thank you to Deborah, for inviting us to speak. I hope that what we're talking about will be useful.
My presentation is decidedly impractical - I'm gonna try to explain what Drupal is and some of how it works.
I'll be followed by two really energetic and talented guys: Alex Fisher from Commercial Progression, and Stephen Colson from Switchback CMS. They will put the rest of the puzzle together with real world sites and practical demos.
Before moving on, I'd like to thank all the people who contributed to this crowdsourced presentation, and all the local Drupal user groups for their support and advice.
Slide 2 - Drupal is a free & open source content management system the answer
So, right off the bat:
Drupal is free and open source. It's released under the GNU Public License, which is the same license used for the Linux kernel and around 60% of open source software.
You may have heard of LAMP. I love lamp. It stands for
While Drupal could be considered a typical LAMP application, you should note that only the P is strictly necessary. It can run on Windows or Mac, with various web servers, and with a few different database systems. It is written in the PHP programming language, so you're kinda stuck with that requirement.
It's been around for nearly 10 years and a whole new version is set to be released soon.
Drupal is the answer, but what's the question?:
- Do you want a powerful website?
- Do you want to add more features later?
- Do you need support?
- Do you want different users to do different stuff?
- Do you want options? There's an easy way and a hard way for everything in Drupal*
I have to admit something now.
Slide 3 - Drupal kinda sucks (right out of the box)
If I have learned anything in the last two years, it's that Drupal is not a Ronco Showtime Rotisserie
It's not "Set it and forget it"
This out-of-the-box unimpressiveness is by design, though. The use case for Drupal is for a site more sophisticated than a small personal blog. It's assumed that you'll customize the site to some degree before unleashing it on the public. It's not strictly necessary, but a site based on a basic Drupal install won't turn any heads.
Drupal also has a notorious learning curve, partly due to an administrative interface that tends to scare away beginners. Luckily, one of the big features for the upcoming version is a big improvement in usability.
Let's take a look at what you get out of the box.
Slide 4 - Your New Site
It's like this.
A blue-and-gray theme called "Garland" is set by default, and you have two content types - page and story.
If you install Drupal for the first time, this can be an incredibly scary sight.
Content types are important: They range from "blog post" to page to a form to external content from RSS feeds to whatever you can dream up. Each content type has a bunch of options:
- Whether or not you want them to take user comments
- Which users you want to be able to create, edit, or delete content of that type
- Whether you want new posts of that type to show up on the homepage
Stuff like that. You can set all of that on your website if you're an administrator. No coding necessary. Once you get the hang of it, It's really easy and flexible.
Slide 5 - The Happy Middle
And it's that flexibility and ability to do complex things without code that sets Drupal apart from other solutions.
Here on the left we have Rails, Django, and CodeIgniter. The basic idea behind all three of them is that they're frameworks - tools for building web applications that help you do it quicker than starting from scratch and using some basic guidelines to make sure they don't suck.
But, when you install them, you have to write code before you even have a basic webpage.
On the right we have WordPress and MediaWiki. WordPress powers almost every personal blog on the web. It has like 200 million installs.
MediaWiki is the software that powers Wikipedia and a ton of other sites.
When you install them you're up and running. You don't need to worry about the particulars - just add content. These applications are great if you want a blog or a wiki, but they take a lot of work and aren't really intended to do much custom stuff with them.
Drupal sits in the middle. It gives you the flexibility of coding a site yourself and the beginnings of common website use cases right when you install it.
Slide 6 - Sweet, Sweet Nodes
So that's sweet, right?
One of the scary words that's really important to understanding Drupal and talking shop with other Drupalistas is 'node.'
A node is an individual page or blog post or whatever you've dreamed up.
All the real content of your site is made up of nodes. Everything is a node.
Node node node.
It might help to think of a node as a note. Or it might not. But a note or a memo has a subject line or title and some content. All Drupal nodes have those things too.
If you want to organize your notes you might put them in folders or attach Post-Its to them. This is kind of how Taxonomy works.
Taxonomy is another one of the scary words.
Here's the skinny. A taxonomy is a list of descriptive terms. Each term is like one tag in a tag cloud. You can stick these tags to any node and use them to organize your content.
Down here we have the tape dispenser, labeled CCK. That stands for Content Construction Kit. I'll talk about Modules in the next slide and Steve will demonstrate CCK specifically, but the general idea is that CCK lets you attach all kinds of funky things to your notes - like photos and even whole other notes.
Slide 7 - Modulez, Drupal Enhancement
There are 5703 total modules. That's a lot.
A module extends (extenze, get it?) what Drupal does. In fact, Drupal is made up almost entirely of modules. Each one performs some small role.
So there's a module called node that does stuff for the nodes from the last slide.
There's a module called menu. Confusingly, it mostly has to do with URLs, but kinda not really. It's one of the things you only have to learn at 1:00AM on a weekend while wired on Mountain Dew. So we'll skip over that for now.
Those are modules that come pre-packed when you download Drupal core.
Then there (contributed) modules nicknamed contrib modules. These are written by the community to make Drupal awesomer.
CCK from the last slide is a contrib module lets you add more stuff to your nodes.
Pathauto lets you make friendly URLs with tons of options
Rules lets make things happen on your site. It's a good example of the "easy way" of working in Drupal.
There are modules to give you fancy calendars, Word-like rich text editors, and 5700 other cool things.
Slide 8 - Umbday Exampleway
So here's a rich text editor. You can pick which one you want to use from a bunch of different cool options, then install the module and set it up.
Boom! Now you have WYSIWYG capability. And you have options, just like the Drupal gods intended.
Here in the text box we have some pig latin. If you aren't fluent, it says "This is a really dumb example."
It's a dumb example because --
Well... let's say you want to make a node and you want that node to appear in pig latin to your users.
You can type it out in plain English and let Drupal do the translation for you.
There are many modules that let you type in wiki syntax or markdown or plain URLs or ISBN numbers and the module turns it into something cool for your users when they view the page. At the library, for instance, we use double square brackets and links to books in our catalog to import book cover images and the title and author and stuff. This is a real time saver and it's all automatic.
And you can mix and match these filters. If you want to strip out certain html tags from the text AND put the text in Pirate-speak, no problem!
This particular example is dumb because when you're creating or editing that node, you'd just see English. So silly.
Drupal also has non-ridiculous translation built right in. You can put your menus and other site text in other languages and switch it for different users and all kinds of stuff. If that's an important part of your project then you'll be stumbling into a funky corner of Drupal's learning curve.
Slide 9 - Users
One of the most powerful features of Drupal lies with User management.
Out of the box it handles sessions and cookies and usernames and passwords and all the stuff that's a big pain in the butt to get right yourself.
On top of that, you can assign permissions to users in a really common sense way.
You can create roles. Roles are containers for much more specific permissions. An example of a permission is "User can edit their own blog posts."
So an admin is free to do anything on the site. A signed-in user can do some things, but is restricted depending on what roles on the site they've been assigned.
A visitor CAN have permissions, but generally can just view stuff through their binoculars.
When you install modules, they often give you new permissions that you can assign, so it's really easy to make sure that the right people can see and do the right things.
Slide 10 - API
This ability for modules to tie into what Drupal does is because of the API.
API stands for Application Programming Interface. It's the way that programmers can interact with the code and data in an application.
Drupal's API is full of these things called hooks. These hooks let you add stuff to Drupal in a standard way.
For instance, when writing a module you might want to use hook_user. Your code might say - when a user signs in, redirect them to a different page.
When one things happens, do other stuff.
Once you get the hang of it, writing code for Drupal makes a lot of sense.
Slide 11 - Page Theming
Along with coding modules, you can also code themes.
You can hard-code HTML into your theme, or put little bits of PHP in there to display the content from the database exactly how you want it.
If you use the default template language, called PHPTemplate, you can specify regions on your page to hold blocks of dynamic content stored in your database.
You can move these blocks around from your browser. Once your theme is coded it's really easy to put stuff where you want it.
Your theme consists of a bunch of template files. This one is for an entire page.
Slide 12 - Node Theming
This one is for a single node. A page can have more than one node displayed at a time, and those nodes can be of many different content types.
Does that make any sense?
Think of a bag of jelly beans. The page itself is like the bag. It wraps around all the good stuff.
Each node is like a jelly bean. All the buttered popcorn flavored beans are from the product content type.
But the bag also has black licorice beans. These could be wiki entries.
The one page could show products and wiki entries in one listing.
And the cool part is that you can make them display however you'd like using template files.
This doesn't speak to how gross a bag of popcorn and licorice jelly beans would be, but this is America so you're free to fill that bag however you'd like.
Slide 13 - jQuery is Money
Nothing's better than esoteric programming double entendres.
If you know jQuery, you know that the shorthand for the base function is the dollar sign.
But I also mean that jQuery is money. jQuery is so money and it doesn't even know it!
jQuery is baked in to Drupal's core. You can even code up your JavaScript is a very Drupal-ish way using Drupal's concepts of behaviors, settings, and locales.
But that's not all!
You can use all the same web standards that everyone else uses, or go your own way.
If you want to use a particular CSS Framework, there's probably a pre-existing theme to do it, or you can roll your own.
If you want to do everything in HTML5, Drupal won't complain.
If you want some visitors of your site to view your pages in full size and others to get a mobile page, that's very doable.
Drupal lets you do what you already know and gets out of your way.
Slide 14 - All the cool kids are doing it
What else can I say to convince you that Drupal will work for your site at the scale you need?
Argumentum ad Populum. Translated from the Latin it means "All the cool kids are doing it."
There are a lot more prominent sites and organizations using Drupal, but these sites are notable because you're in Drupal when you get to the home page and most if not all of the content is in Drupal.
That's a powerful indication of the trust organizations place in Drupal and the ability of it to suit complex needs.
Slide 15 - Support
Another great selling point is the available support.
You can get help directly from the Community via IRC, Forums,and other avenues.
You can get materials ranging from books to videos and more from Lullabot, Apress, and other publishers
The creator of Drupal has a company called Acquia that also lends support.
The documentation for every aspect of Drupal is amazing. If you want a quick how-to for a beginner it's on the Drupal site. If you need in-depth documentation of the API, it's there too.
Each module has an issue queue. These are really handy for seeing if the issue you run into is a known bug or a picnic error.
Most any problem you run in to likely has a forum post or page on the Drupal site. The site search is arguably the best tool for getting the support you need.
There are also plentiful user and developer groups. There are at least three in Metro Detroit.
You can also hire a firm to develop, design, consult, or for individual bounties to develop a particular feature.
Options. Drupal gives you options.
One more thing...
Slide 16 - One More Thing... (Views)
Views makes a Developer's life so much easier.
I'm not ashamed to admit that I frequently take the lazy route. Views is the lazy route in a very real and very cool way.
Remember the jelly beans? Let's say all the content on your site is a big tub of jelly beans.
Views lets you put whichever beans from the tub you want in whichever bag you want.
If you want an RSS feed with just the images from your products in order by the date they were last edited, you can do that by playing around in Views for a couple minutes.
If you want a block in the sidebar with the latest posts from one user's blog, that's a cinch.
If you want a page of all the posts tagged chicken in reverse-title order, you can do that.
With Views. Views is a miracle wrapped in a magic trick.
Views makes learning Drupal SO worth it.
