One of the best things about Drupal is the number of 3rd party modules available. Just browse over to http://drupal.org/project/Modules and you'll find literally hundreds of modules you can install right now to expand the functionality of the popular CMS. True, the core Drupal install does give you everything you need to start posting content right out of the gate, but it's this outside support that really makes Drupal worth considering.
No matter how you're using Drupal, there are a few modules you'll want to download right away. Over the next few days, we'll talk about three such modules that are so useful and popular I'm constantly surprised they haven't simply been added to the core. Who knows? Maybe there are plans to add their functionality to a future release. One can always hope. In the meantime, considering downloading and activating these three modules a permanent part of your new Drupal installation process.
Pathauto
After installing Drupal, the first step we always do is to enable Clean URLs (http://drupal.org/node/15365). In a nutshell, the out-of-the-box Drupal install uses URLs that look something like "http://www.example.com/?q=node/15". Ugly, and the search engines don't like them. Enabling Clean URLs takes that and turns it into something friendlier: "http://www.example.com/node/15."
Now, if you're like me, you're looking at that and thinking "hokey religions and Clean URLs are no match for a good blaster at your side, kid."
Ok, maybe that's just me... Still, though, Clean URLs only get you half way there. The "/node/15" URL might look better and be more search engine friendly than the "?q=node/15" version, but there's still a lot of room for improvement, both from a search engine and user standpoint. Enter Pathauto (http://drupal.org/project/pathauto).
With Pathauto installed and configured, you can tell Drupal to automatically create URLs for new content that fit whatever pattern you decide. Yeah, you can always manually change the URLs while editing your posts by typing something in the URL path settings field, but why would you want to do something by hand when you can have it done automatically for you?
Take a look at the URL for this page. Should look something like http://www.nerdliness.com/article/2007/08/23/drupal-modules-you-need. Much easier on the eyes than http://www.nerdliness.com/node/30, isn't it? Google likes it a hell of a lot more, too, and what use is writing your wonderful content if nobody can find it?
Don't like the pattern we used (type/year/month/day/title)? No problem. Pathauto lets you easily change it to fit your taste and needs. Even better, you can specify a different pattern for every different content type you have, if you like. You can even specify which words in a title Pathauto will strip out of your URL (like common articles: a, the, of, etc.).
Before you do anything with Pathauto, though, take some time to figure out exactly how you'd like your URLs to appear. Do some research on SEO, etc. and implement the best strategy possible from the beginning. Pathauto does make it easy to change your patterns in the future (and automatically update existing URLs, if you like), but doing so can have a negative effect on the ability for potential visitors to find your content.
Happened to us recently. We initially started out using a pattern that looked like "/article/title," but after a couple of weeks decided that it would be better to use our current "/article/year/month/date/title" structure. Pathauto handled the change instantly. Google? Not so quick.
The first several times Google indexed our site, we were using the old patterns. And because it can take some time for Google to reindex a particular site, a lot of would-be visitors are hitting our custom 404 error page rather than the content they were looking for. Sure, they could use the search box or our archives to find what they were looking for, but how many do you think actually try that? Yeah.
So Pathauto is essentially, but use it wisely. Download it now, but put the time in up front to come up with a URL strategy that will last for the life of you site. Either that, or get ready to see your 404 page become the most popular thing on your site.
Comments
Pathauto
Actually, if you change any pathauto pattern, there's a little tick box to "bulk update" the URLs that would be affected by the new policy. Once you do that, all prior URLs take on the new form.
However, planning your URL scheme should be done very carefully before deployment, especially where Drupal and Pathauto give a bewildering array of options. Changing it later is going to result in broken links and/or duplicated content, because I believe Drupal keeps both references in its database.
Here's yer problem...
I was just getting ready to call shenanigans on your post about existing URLs being "affected by the new policy"... Glad I did some more research first.
See, we just recently changed the pattern for our articles from "/article/title" to "/article/year/month/day/title," and the change wasn't retroactive to previous posts (even though I'd checked the "Bulk update node paths" box you mentioned).
Just figured out the problem, though. Under the General Settings heading in the Pathauto configuration (Administer->Site Configuration->Pathauto), there's a radio button labeled "Update action:" that allows you to determine how Pathauto will handle said changes.
In our case, it was set to "Do nothing, leaving the old alias intact." And, of course, that's exactly what it did. There's an option to set Pathauto to do what you suggested ("Create a new alias in addition to the old alias") as well as one that will simply wipe out existing aliases and replace them with the new pattern (oddly titled "Create a new alias, replacing the old one").
Like you mentioned, though, the best bet is to just spend a few extra minutes planning in the beginning. Had we done so, we wouldn't be in the position we're in now, with Google, et al sending people to the old (now missing) pages instead of the new one.
Good thing Drupal makes it easy to create custom 404 error pages, too...
Shenanigans indeed!
Heh. I always feel self-conscious giving advice about Drupal because I'm still learning the platform myself. Of course, I've made those mistakes as well - funny how you forget to plan in your fervour to experiment with the technology!
Edited...
Ok, I've gone back and fixed my erroneous post. Would hate for some poor sap to take my initial words to heart without reading these comments... Thanks for calling me on that.
core
Modules that are popular and necessary for your sites and the types you develop are not necessarily the same modules for others. Some things are in Drupal core because they have been there since the beginning, others are added as the base level functionality makes sense to include.
Path Auto has had historical performance problems (may have been solved in D5). So has been unfit for Drupal core inclusion. Recently Jeff Eaton has hit upon a new idea in pulling out a certain type of function into an API called Token module. This has a lot of implications for pattern matching with a lot of programs. As a base level API, it has a better chance of getting into core.
Note, I say 'better chance'. Some things... Does it make sense? Can other modules/developers leverage and use the exposed APIs, how/what is the performance impact.... And most importantly, will someone actually work on the code/patch to include this feature in the next version of Drupal? Will someone begin, deal with the feedback revise and re-submit.
For all of Drupal's speed of change, there are features that are currenlty in Drupal that took 2-3 versions to get in. There are some which are only partially implemented currenlty and are not more feature rich becuase people didn't have time to work on them.
An excellent example is PHPTemplate theme engine now default. It was first proposed and there was a lot of work to abstract the theme engines so that it would work properly. It was hoped for 4.6 core but just didn't make it. A lot of the ground work however, did. As a result, it more fully made it into 4.7. It lived life originally as a contrib module for 4.6.
A lot was learned in that time period that made the 4.7 and 5.0 implementaiton betterthough there was still some awkwardness. Drupal 6 had a tremendous amount of work to make theming easier.
So, why aren't some things in core?
Lots of reasons. Have fun with Drupal
Steven Peck :: www.blkmtn.org
Agreed, but...
Obviously, our needs are going to be different from others. I don't think I implied that ours were the same as others or that everyone should bow to our whims (though the world would probably be a better place if more people did...). However, if 99% of the people who use Drupal end up downloading a specific module (Pathauto, CCK, and Views, for example), then taking steps to add them to core seems like a logical idea.
Again, using Pathauto as an example, it seems that every major CMS and/or blogging software has the capability this module provides natively. I don't need to download a plugin for Wordpress, for instance. It's just one of the built-in options. I would think that a function that seems to be so commonly used and requested would be a perfect candidate for core-o-rama.
That said, though, I understand what you're saying. If a module has performance issues, it probably shouldn't be included. But... if the functionality that module provides IS something that most people would/do use, it's functionality should be pretty high on the list for a future update.
By the way, none of this criticism should be taken as a slap in the face to Drupal. On the contrary, we're big fans. I'm just a glass-is-half-empty kinda guy... not that I'm a pessimist, just that I really like the half we have and see the potential that empty half represents. Nonetheless, we use Drupal here, Jeremy uses it on like 99.9999% of the sites he designs in his freelance gig, and we're going to continue to recommend it to others.
Along with these other modules. :)
Justin
merely an explanation - not concerned
I was merely answering that off hand comment you made, not knocking your choice of modules. Everyone has those tools without which they will not build with. Drupal is not WordPress (as you well know :) and it's base capabilities and history are different, so it's core features are different. So, where does that leave us?
One of the really important things that Drupal core has to take into account is that it's used by a broad spectrum of sites and that base level functionality is important as a base starting point, not necessarily a complete solution. It is a base, but one you can complete to your needs with contrib or custom modules.
Path module is in core and works very well for a lot of sites, including mine. I've already covered all the other stuff about PathAuto... If no one works on it, then nothing happens. If it's inclusion in core is important to you, then it's something that you or others should involve yourself with in testing and writing patches for. This is not a 'do it yourself' speech ( I know you already understand Open Source), this is explaining why some people are confused about some features they feel Drupal should or shouldn't have for the rest of your readers. The mythical 'someone' hasn't worked on it.
Drupal doesn't have roadmaps. It doesn't have designated and assigned 'teams' that are told to work on specific things. The closest it has to 'teams' are the maintainers listed in the maintainers.txt file in your download (yes, I am in it). The closest it has to 'roadmaps' are the 'Planning to work on it' threads that Dries starts when he opens core for a new development cycle. So as I said before, Jeff Eaton has plans for this. This is good for people. What would be better is if people work on and test his could and provide feedback. More people working collaboratively on this means it has a better chance of getting in and less for Jeff getting to busy to work on it and it not getting in Drupal 7. Make sense?
You also wondered about two other modules. CCK is already in core, it was added in Drupal 5. This is one of those let's migrate features in over several versions type paths. Why isn't more of it in core? The lead contributor for CCK module had an illness and death in the family, so much she planned on did not get done. Real life obligations and events often have an impact on a given contributors involvement in a development cycle and if no one steps up to cover the gap, then things don't get done. Why isn't more of Views in core? The developer for the Views module says it's not ready. Views in Drupal land is still a realitively young module and is still undergoing improvements and change.
With Drupal, anyone can submit a patch against core. Anyone. No garuntee that it will get in, just it's that open and doesn't even require CVS access.
These types of posts about experiences with modules and building sites are important. Something also important and valuable along with these types of recommendations is the perspective and assumptions for the types of sites and markets that you build sites for. Understanding those intial assumptions can help the reader effectively evaluate if those recomendations match their needs. Does that make sense?
You using Drupal and are doing good write ups. I'm not worried about critiques, merely trying to answer some of your comments with the 'why' of some things. By the way, I added you to Drupal/Planet
Steven Peck
This is what I love about Drupal and Open Source...
Man, I'm getting giddy.
I love this kind of discussion. It's so refreshing for people to be able to express their opinions in an intelligent and respectful manner. Thank you.
That's one of the things I both love and hate. On the one hand, I love that Drupal development is nimble enough to adjust to changes in culture, technology, trends, etc. On the other hand, it can be a little frustrating not knowing if a specific module (core or not) will be maintained, supported, etc. But, as you mentioned, that's part of open source. If enough people find something important and useful, odds are that it's going to be sustained.
Totally understood and, frankly, a do-it-yourself speech would also be acceptable. After all, what right do any of us really have to complain about something that we're using at zero cost? If there's something I want, I should do something to contribute towards that goal... if I don't code, then a bounty. Still, though, it's fun to complain. :) And honestly, I wouldn't take the time to complain about the things I'd like to see if I didn't already like what I do see. If Drupal were crap, I'd just drop it and move on to something else.
Seriously, Steven, thanks for taking the time to write about this here. Like you mentioned, I think it's a good discussion to have.
pathauto - really usefull
pathauto - really usefull plugin. i use it for search engine optimization on all my projects.
Post new comment