Drupal 6 Content Administration 50
Trevor James writes "Finally, here's a Drupal book specifically for Drupal content editors and site managers, those folks responsible for posting new content and editing existing content on a Drupal site. While many of the Packt series of Drupal books focuses on code, development and are written for Drupal developers, this title is for anyone who is dealing with management of Drupal based content and any individuals or teams responsible for the management of Drupal sites on a daily and hourly basis. This book is also perfect for introductory Drupal classes and I will not hesitate to use it in my Drupal 101 classes in the near future." Read on for the rest of Trevor's review.
In Chapter 1, the author gives a concise and streamlined introduction to the Drupal CMS and the elements of a Drupal Web site from both the frontend and backend perspectives. I liked seeing the detailed explanations of a Drupal powered front end layout — explaining the differences between the site header, navigation areas, and content areas. I'd recommend this first chapter to anyone who is just starting to use Drupal and wants a basic introduction to the Drupal framework. It's hard to emphasize how important it is to understand the basic intro level concepts and functionality of the Drupal CMS and its all here in this intro section. To any of my intro Drupal users I would hand this chapter out and ask them to read it.
| Drupal 6 Content Administration | |
| author | J. Ayen Green |
| pages | 179 |
| publisher | Packt Publishing |
| rating | 9/10 |
| reviewer | Trevor james |
| ISBN | 1847198562 |
| summary | A fun, informative, hands-on learning guide that uses an actual case study |
Chapter 2 moves into a detailed discussion of Drupal-based content and asks the simple question (but important one), what is content? In Drupal we know that content includes nodes and node types, node IDs (nid), comments, Blocks, and Views. The author defines the core node types including Story and Page. Note here to Drupal 7 users ... the story type is renamed "Article" and the Page type is "Basic Page" in the new D7 release. I also love the fact that Green defines what the Drupal front page or home page is and what that home page contains. I am asked this question all the time by new Drupal users — how do I post content to my home page and how do I customize the home page. Read the definition on p. 19 of this book.
At this point I'd encourage those readers who are using the book to go ahead and start creating content on their Drupal site following the author's instructions. It's a great book of examples of tutorials to follow along with hands-on. The author gets you creating story content and editing it quickly. He also spends a good deal of time discussing integrating a WYSIWYG text editor to your content node form so you can use the text editor buttons to format content.
Chapter 3 continues the content discussion by showing you a bunch of enhancements you can do to your posted content. The author aptly calls these "seasonings". This includes creating teasers, creating links to other node content using the text editor, uploading images using the text editors and manually via the Drupal node editor, linking your images, embedding audio content, and linking to downloadable files such as PDFs. My only concern here is that the author shows you how to link to PDF files via the text editor but there's actually simpler methods of doing this in Drupal using Drupal's default file attachments module (part of core). This is the preferred method since it easily opens up the attached file to be used in other areas of your site via the Views module for instance. I always encourage Drupal users to add attached files using the core Drupal file attachments since I think it's simpler and more streamlined and it's the "Drupal" way of attaching files. I would add this method first and then show the text editor option second.
The author shows us how to upload and embed video content using SWF Tools module. I would have spent a bit more time in this chapter showing the user more details about uploading Flash based content using a combination of the Flash node and the SWF tools modules and integrating various player options in SWF Tools such as the Flowplayer utility. But again these are technicalities. The information the author presents is great and detailed. It's a good starting point for more beginning Drupal users.
Chapter 4 moves into more advanced content editing topics. The author shows you how to use HTML and CSS to create table based layouts (without using table code) in your text editor and in a Drupal node. So for everyone who needs an introduction to CSS this is a great place to start. The author spends time showing us how to add the CSS files so they are recognized by our Drupal theme — this is going to be a bit more advanced for the new Drupal user but its good stuff to learn. He even shows us how to create a CSS file from scratch and how to build the table layout without using table code. Sticking to CSS is going to give you cleaner code and work better with Drupal so it's great that he emphasizes this here. For dealing with more table based code Green shows us some tricks to injecting this code using PHP. Again this is more advanced but good tips and tricks for those involved with code. He also shows us how revisions and workflow work in our Drupal site.
Chapter 5 deals with how to use tagging, tag clouds and how to re-name our URLs with human friendly path aliases using Drupal's core Path module. This will help our site become more searchable, browser and user friendly. Tagging is the focus here and he gives a nice walkthrough of Drupal's taxonomy system. Anyone interested in setting up tagging on their Drupal site should read this chapter. Chapter 6 moves into using Blocks, Views and setting up Blogs on your site. This chapter is the one to read if you're managing blocks and Views and want a good introduction to the Views module. Packt has published books specifically on using Drupal Views but I would start here first if you're just using Views for the first time.
The section on blogging is good too. Often I hear folks report that Drupal is only a fancy blogging tool or blogging application. This book actually shows that Drupal is a full scale and robust CMS and that blogging is only one minuscule part of the entire framework. If you're just going to be blogging on your site Drupal may actually be overkill. The author shows this by spending a smaller amount of time showing you how to set up your Drupal site for blogs, but of course it also shows you that Drupal does blogs too and you can easily use a Drupal site to just blog. I would argue that this is a great book to look at the overall impact of Drupal on building Web sites and how we can leverage it to build powerful, rich and robust content management driven sites. We can add a blog if we want to but it's not just a blogging-based piece of software.
Chapter 7 deals with setting up users, roles and permissions on your site. It's good to leave this chapter towards the end of the book since Drupal permissions can be a bit tricky and time consuming to set up. We moved through a bunch of fun material earlier in the book and now we have a chapter on permissions. I like the attention the author placed on how to organize this section into the overall book's theme and layout. Chapter 8 shows you some tricks for dealing with issues like pasting Word content into a Drupal node; and using the Blog API module to work on blog posts in remote software and then post those blog entries to your Drupal site via a Web service. A nice touch here to add a small section on using Web services to post content. Finally the Appendix shows you how to install Drupal.
This is definitely one of the best books I've read on Drupal from an introductory standpoint. It's up there with O'Reilly's Using Drupal book and I would recommend it to anyone who is installing Drupal for the first time. I'll use it in my introductory Drupal classes for sure. It will be nice to see this book revised for Drupal 7 soon. Excellent work again from J. Ayen Green.
You can purchase Drupal 6 Content Administration from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Drupal 6 or 7? (Score:1)
Re: (Score:1)
Re: (Score:2)
...neither of which would satisfy the users that are still happy with Drupal 5.
They will be less happy when Drupal 7 comes out, because typically, only two versions are supported at once. Once D7 comes out, D5 support will most likely be dropped, meaning no more security updates.
This is, in fact, one of my biggest complaints about Drupal: lack of backwards compatibility between versions. I just finished developing a site in Drupal 6 and it involved writing a lot of code. I am disappointed to see that many of the functions I call in the code are changed or eliminated in Drupal 7.
Re: (Score:2)
Permanent backwards compatibility leads to the cruft that is Windows. Sometimes you need to cut loose old APIs and compatibility and move forward.
Didn't someone estimate that they spent more than 1/2 of their development time trying to support IE6? Sometimes you need to break things.
If you don't want to change. Don't. If 6 works for you, then keep using 6.
just imagine if M$ had (Score:2)
Re: (Score:1)
First, Drupal 7 has been in development for a *long* time, so I wouldn't worry about when Drupal 8 is going to be released.
Secondly, many projects have rolling support options. Where features have a two version rolling window of support. If you were programming for Drupal 6 you probably should have been keeping an eye on Drupal 7 to see which calls/apis/etc were being discarded. This would have limited the amount of rework to move to Drupal 7.
Re: (Score:2)
Secondly, many projects have rolling support options. Where features have a two version rolling window of support. If you were programming for Drupal 6 you probably should have been keeping an eye on Drupal 7 to see which calls/apis/etc were being discarded. This would have limited the amount of rework to move to Drupal 7.
The entire database abstraction layer is changing. I know of no way to write code that would be compatible with both Drupal 6 and Drupal 7 at the same time. For instance, db_fetch_object() is being dropped from Drupal 7, but the replacements aren't in Drupal 6. And it looks like the new way of doing things will require more code. Ditto for db_query()s that use SQL UPDATE or INSERT statements. Done in an entirely different way in Drupal 7 that wouldn't work in Drupal 6. That's the gist of my complaint.
Re: (Score:2)
My 4.5 modules worked with 4.6 with no changes. My 4.6 modules worked with 4.7 with no changes. My 4.7 modules worked with 5 with very minor changes. My 5 modules worked with 6 with very small changes. I haven't tried porting any 6 modules to 7 yet, but looking at the list of modules that already support 7, I'm not quivering with fright at the prospect.
The API is not guaranteed not to change, but a lot of people work hard to make sure that the change is evolutionary and the thousands of automated tests help
Re: (Score:2)
My 4.5 modules worked with 4.6 with no changes. My 4.6 modules worked with 4.7 with no changes. My 4.7 modules worked with 5 with very minor changes. My 5 modules worked with 6 with very small changes. I haven't tried porting any 6 modules to 7 yet, but looking at the list of modules that already support 7, I'm not quivering with fright at the prospect.
The API is not guaranteed not to change, but a lot of people work hard to make sure that the change is evolutionary and the thousands of automated tests help to make sure that
First of all, it isn't surprising that changes from 4.5->4.6->4.7 didn't require any rewriting of modules. Only major version number change break backward compatibility. I think the change to Drupal 7 will be bigger than the previous changes. The changes to the code I've written will be anything but minor. The entire database abstraction layer is changing. No more db_fetch_object for instance, and my code has about 50 calls to that function. Also, INSERT and UPDATE db_queries will need to change
*tears* (Score:1, Troll)
Re: (Score:1)
I know. That's why I write all my webpages in x86 assembly [viksoe.dk].
Re: (Score:1)
Re: (Score:1, Flamebait)
My post wasn't being serious. Maybe you need to lighten up a fuckton if you take my posts that personally?
Re: (Score:2)
I didn't say all my posts were me joking. I was only referring to the post above. Either way, the fact that you take what I post so personally means you really need to get a life.
Re: (Score:2)
Kinda why I always hated being referred to as a programmer / IT / geek whatever.
Seriously can't we do a little bit more to refine our public image a little bit more?
I'd like to have a little bit more pride about saying what I'm doing when I go out with the girlfriend and have to talk about what I do.
It's been 20 years now and we still can't make our profession cool? We practically make the fucking civilization go and programming is basically the next form of communication for the next 100 years.
We generally
Re: (Score:2)
We generally make good money and we can fuck up even the best of most businesses.
This is where the term "consultant" is appropriate.
Re: (Score:1)
Your comment was funny and appreciated.
Re: (Score:2)
Yeah, that's a good slogan to improve the public image of any profession.
Tears of joy (Score:5, Insightful)
I think I can claim to be a real programmer having designed & written shrinkwrap software, built in-house corporate software, developed embedded control software, made web apps used by thousands of users daily, written several frameworks, all for software running on a diverse range of hardware, from microcontrollers through to mainframes and most things in between, in a pretty wide variety of languages, from systems languages like C, through to dynamic languages like PHP and Ruby, and all the usual suspects in between.
In my opinion Drupal core is well written. Tons of thought goes into it, with lots of smart, experienced people weighing in on the architectures and reviewing the code. It's (far) better than most closed source apps I've had the pleasure of working with.
This is also true of the top, say 10 to 20% of non-core modules. The ones that no serious site is without. The quality of the rest varies hugely, from bad, through to awesomely good.
Re: (Score:2)
Re: (Score:2)
Thus reinforcing the stereotype that Drupal is for coders only. If I had known what a festering ball of crap the user side of it was, I would never have started using it.
Have you tried any of other other Free/free CMSes that do everything Drupal does? Wait, they don't exist. Further, they are just as frustrating, if not moreso. What would stop me from starting to use Drupal today is that Drupal 7 is pretty majorly different, and it's going to be some time after its release before all the important modules are stabilized... and it's not out yet. I'm holding back three different projects until D7 drops... which means they've already been pushed back. D7 is supposed to provide
Re: (Score:1)
Re: (Score:1)
Why do you think the boost front end module and css and js aggregation options are so popular? They may not help with registered user content, but really help with anonymous users.
Serious problem with most CMSs (Score:2)
Drupal is not alone here. This is a problem with almost all except the simplest CMSs.
The problem is one of complexity: when you are doing one thing, it's easy to optimize it into one SQL query. But when you have a modular system, you want each module to work independently as much as possible because you want to avoid dependency hell, and you want to minimize module interaction because that will lead to side-effect bugs which are difficult to track down. The architecture choice that most CMSs make in order t
sweet, send one to France (Score:2)
(disclaimer: I'm French, I just can't help it if my country's been a complete joke lately)
And send one to BC (Score:2)
Great timing! (Score:2)
Right in time for Drupal 7!!
A book for content administration? (Score:3, Insightful)
There is something *seriously* wrong with a Content Management System if it prompts someone to write a book on how to use it for editing content.
Never mind the nightmarish coding practices that developers have to deal with, the always-one-version-behind modules, views in the database, or all the other things that make Drupal a pain to work with. The first thing a CMS should do is make content administration simple.
Hopefully Drupal 7 will solve some of these problems...
Re: (Score:1, Insightful)
I disagree. It's really interesting to see how many people don't know how to properly convey, organize, and administrate content...ESPECIALLY on websites. I've even seen some very intelligent people do it incorrectly. I think a lot of people underestimate this task. Programming is NOT the same as content administration. In my opinion, they require different skill sets.
A complex tool needs a manual (Score:2)
There is something *seriously* wrong with a Content Management System if it prompts someone to write a book on how to use it for editing content.
I do not agree. I think someone taking the time to lay out clearly exactly what all the parts are makes a lot of sense for any CMS, so that a content producer can lay out data and pages in ways that make sense for that CMS.
The thing open source software is worst at is writing manuals, so it makes sense that a very popular CMS would have that documentation vacuum