Clean up The Drupal Cookbook (for beginners)

Rather than an "additional tips & tricks" section, which by its very nature sounds miscellaneous, maybe this would be better as a numbered set of steps, with the guiding theme being "So you've just got a new Drupal site? Now what?"

if you want to take that on, power to you! just keep it basic if it's in the cookbook, anything more advanced should go in other sections of the handbook. if you want a review, post here when you've got some written and myself or others who watch the queue will have a look.

Sounds good. I'll let you know when I've edited the relevant pages.

adding tags

Haven't had time to work on docs tasks lately, sorry. Anyone can pick this up.

This sounds like one of many tutorials that I've written for several clients. I can probably knock this out.

As I was starting on this, I noticed that some of the items seemed a little out of place. For example the "User login FAQs" seem as though they should be under "Users, roles and permissions" not a miscellaneous list of additional tricks. So, I think that this hierarchy would help with the overall flow of the cookbook, but I wanted to get more opinions in case something else needs to be moved / added / changed:

Welcome to Your New Drupal Site!

• Common First Steps (Formerly “Additional Tips and Tricks”)
  • URL Aliases
  • Setting up the homepage
  • Adding a contact form
• Adding Modules and themes
• Modules
• Themes
• Getting Your Site’s Content Set up
• Taxonomy (Categories)
• Moving Stuff to your site
• Migrating content from another site
• Creating Content
• “Teasers” – Short summaries of node content
• Yet another solution for editing media content on a Drupal site
• Links and Images
• Blocks – adding extra information
• Users, roles and permissions
• User login FAQs
• How to redirect users after login in Drupal?
• Error pages
• Working with menus
• Primary and Secondary links
• How to display sub menus (children) of primary links in Drupal
• Setting up Maintenance tasks
• Browser tips for accessing your site maintenance tools
• Setting up CRON
• Checking for Available updates
• Common Problems
• Glossary
• Recommended reading and helpful resources

Just changing the status so I can get some input regarding my new outline suggestion before venturing too far into it.

I agree that the Cookbook could use an overhaul. I did a quick 30 minute introductory session based on it at the Drupal Camp here and saw that it could reorganized into something more resembling an upside-down funnel. That is, start with the real basics, then add more specifics in later chapters to expand on the basics. I just haven't had time to work on it again. (http://techtv.mit.edu/genres/24-how-to/videos/7860-drupal-cookbook-for-n...)

Please keep in mind who the audience is: absolute beginners, many of whom don't have a site up yet and certainly don't know the jargon yet. Being very technical - and even 100% correct - is going to turn people away.

I have argued with some of the changes that have already been made, and I think some of your outline shows them being repeated. Menus is one example. Menus are simple, unless you start talking about more advanced techniques. The beginner doesn't need primary and secondary links (which I have used only once), nor how to build whole new menu blocks. Another example: I've been doing Drupal for 4 years now, and have yet to "redirect users after login." A beginner doesn't need that. And aliases before the home page - I don't think so.

I do find it quite a turnaround that so many people are now interested in working on this when I had to fight to get it published to start with.

:) Okie...

Some of this is based on questions that clients end up asking me once I have their site set up. I'm iffy on the redirect; I've never used it but I have had clients ask for it.

So, also taking in your suggestions, maybe something more like this:

Welcome to Your New Drupal Site!

• Common First Steps (Formerly “Additional Tips and Tricks”)
• Setting up the homepage
• Adding a contact form
• URL Aliases
• Adding Modules and themes
• Modules
• Themes
• Getting Your Site’s Content Set up
• Categories (Taxonomy)
• Moving Stuff to your site
• Migrating content from another site
• Creating Content
• “Teasers” – Short summaries of node content
• Post Settings
• Links and Images
• Blocks – adding extra information
• Placing Blocks in the layout
• Adding New Blocks
• Users, roles and permissions
• User login FAQs
• Error pages
• Working with menus
• Primary and Secondary links
• Setting up Maintenance tasks
• Browser tips for accessing your site maintenance tools
• Setting up CRON
• Checking for Available updates
• Common Problems
• Glossary
• Recommended reading and helpful resources

Thanks for the input Nancy, and for the proposal Fanaile. I think it does indeed need some restructuring, but also am keeping in mind the need for this to be geared towards total beginners (and leave out complexity, maybe only linking out to other sections when needed - there's not quite sufficient linking to more complex content outside of the cookbook at the moment). I think that there is more focus and interest on this section now because it has a direct link from the main /documentation page and also because a lot of the docs have been going through a D7 upgrade and we haven't gone through the cookbook in detail.

Now as for the proposed outline... I've made a couple adjustments to the order and titles (though the hierarchies look pretty good). And for what it's worth, I think that the basics of how to set up more than one menu or menu blocks is really something pretty basic and commonly done, so I've got nothing against keeping that in the plan. "How to display sub menus (children) of primary links in Drupal" on the other hand, I think should be moved out of here, it's complex and as far as I know, not a usual method to use for configuring menus. I also think the "How to redirect users after login in drupal?" page could be moved out of here.

This can probably still be improved a bit more, but I think something close to this would make sense for rearranging, and then we can fill in any blanks with a few additional pages. Also, another thing that needs to be done is doing a full sweep through for updating with D7 info, and applying the style guide (but we can open new issues for those if needs be!).

• Welcome to your new Drupal website!
• Managing your content
• Creating content
• “Teasers” or node summaries
• Rich text editors
• Working with menus
• Primary and Secondary links
• Links and Images
• Categorizing content with taxonomy
• Moving content to your site
• Migrating content from another site
• Basic customizations
  • Basic layouts with blocks
  • URL aliases
  • Setting up the homepage
  • Adding a contact form
• Modules and themes
• Adding functionality with modules
• Customizing design with themes
• Users, roles and permissions
• User login FAQs
• Error pages
• Setting up Maintenance tasks
• Browser tips for accessing your site maintenance tools
• Setting up CRON
• Checking for Available updates
• Common Problems
• Glossary
• Recommended reading and helpful resources

I like this :) But, I think that Basic Customizations should come before Managing your Content.

My reason being is that the homepage and contact forms are almost always the first things that a client will ask me about to set up - even before they have anything else ready to go. And with the latest craze for SEO, a lot of clients ask me about URLs. While I know that setting up a URL alias is second-fiddle to creating the content, it's just so much easier to have the aliases set up before you start posting content.

Plus, the context of "Basic Customization" sounds like a first steps type of heading, while "Managing Your Content" sounds more like a second or third step - like you've gotten past your set up and are working your way up?

Make sense?

If not I'll just go ahead and work with yours.

I haven't had a lot of time to play with Drupal 7 yet; I started to because one client wanted to get upgraded, but not enough of his modules have been upgraded yet, so he placed it on hold. I will upgrade my local server and place in the Drupal 7 updated terms/links etc. sometime later this week so we can get this updated for D7.

I'm still on the fence on moving Basic Customization up - maybe we can get a tie-breaker opinion or two from others on the thread? ;)

That'd be great if you want to help add D7 content too, we usually make the page structure (unless there are only small discrepancies between versions, then it can just go in brackets):

- general info that applies to all versions
- D7 specific info under h2 "[Topic name] in Drupal 7"
- D6 specific info under h2 "[Topic name] in Drupal 6"

It's always a great learning experience documenting D7 stuff, don't hesitate to ask for help in #drupal-docs or #drupal-contribute if there's anything you're not sure of!

@all:

Glad to see some people taking this on. Here's an outline I would propose, similar to arianek's from #12, but with a few tweaks. Basically what I'm trying to do is mirror in the top-level headings the Information Architecture of Drupal's menu system, covering the main topics that people new to Drupal & CMS's in general would need or want to do. I added some additional pages in brackets, as well as comments on some changes I made.

I think "Managing Your Content" should come first from a pedagogical standpoint, since people should understand a bit about how a CMS works for adding content, even if they don't have content to add yet.

Some minor things (I can do these if no one objects):

The sub-menu links code (http://drupal.org/node/685664) should be in a PHP snippets section, not the Cookbook. But it should also be marked "deprecated", I think, since using PHP snippets is not usually a recommended technique. I think Menu Block would be the preferred technique.

"CRON" should be "Cron".

Whichever outline you want to work with is okay because it's easy enough to move things around. I would suggest that setting up a basic homepage be early on so that the new user doesn't see what looks like an error. I would definitely say that most of what you have under "Creating content" belongs farther down. Basic terminology must be first. I am much happier with my explanation of a "node" on the video than I was when I originally wrote the Cookbook.

Remember that the new user needs to see something early on in order to keep feeling good about doing this. Give them small steps and then expand, even if that is not necessarily the most efficient way to build a site.

Also, one of the most common questions I get is "How can I build this on my computer?" So there should be at least a basic description of *AMP and some pointers on how/where to find something to do that. I may have put more detail into that when I first wrote this, but there were fewer options then. The environment 4 years ago was quite different than it is now.

As for URL aliases, it is a common myth that "nice" URLs help much with SEO, other than providing another place to stuff a keyword. That's why I downplay the value of aliases. And the contract I'm on now has been running just peachy for over 3 years without aliases. True the client thinks the current "node/1234" is pretty ugly (still better than Wordpress though), but they've never made any effort to fix it. It will be fixed now.

@Ariane: more focus and interest on this section now because it has a direct link from the main /documentation page -- Yeah, that was another big fight.

BTW, I strongly recommend that all changes be run by a bunch of people who have used Drupal less than a year.

Okie... I had a thought last night, but it was late so I decided to wait until morning before I brought it out, and it matches a lot of what EvanDonovan says in #15. Except that I think we are interpreting "Error pages" differently. Under the current heading "Error Pages" I take this to mean things like Access Denied (403) or Page not found (404) etc. Not the error logs in the admin. So I'm thinking something like this:

Welcome to Your New Drupal Site!

• Managing your content
• Deciding on how to set up your URLs
• Changing your pages URLs manually
• Setting your site to change URLs automatically
• Moving content to your site
• Migrating content from another site
• Creating New Content
• Setting up your Homepage
• Adding your contact form
• “Teasers” or node summaries
• Adding links
• Rich text editors
• Adding images
• Adding rich media (audio & video)
• Adding other fields to your content (brief introduction to the Content Construction Kit)
• Editing existing content
• Making changes from the page
• Navigating the Content List in your Administrative panel
• Making mass changes
• Structuring Your Site's Content
• Working with menus
• Primary and Secondary links
• Using the Book module
• Categorizing content with taxonomy
• Displaying lists of content with views
• Changing Your Site's Appearance
• Basic Layouts with blocks
• Customizing design with themes
• Introduction to panels
• Adding functionality with modules
• Core Modules
• Contributed Modules
• Users, roles and permissions
• User login FAQs
• How to handle error messages
• Setting up maintenance tasks
• Browser tips for accessing your site maintenance tools
• Setting up Cron (scheduled tasks)
• Checking for available updates
• Common Problems
• Glossary
• Recommended reading and helpful resources

I think probably both kinds of error pages can be covered. Maybe NancyDru is right about setting up home page coming before Managing Content, but I think a lot of that should be covered soon, since that's what people come to a CMS to do, most basically.

@Nancy

LOL, I wish I had some of your clients ;) With my clients, SEO is almost always a first question. I've got a couple clients that hired an "SEO expert" before hiring me... which was really kind of awkward. And this expert had my client convinced that if I didn't have aliases set up no one would ever find his site.

I think I'm just going to go ahead and stick with this latest outline. I really just needed an idea of how to go through everything and I tend to work with lists a little better. I'll make sure that I separate each step into it's own page so if we want to move things around later it'll be easier to do that.

Thanks :)

i actually think Evan Donovan pretty much nailed it in #15 - the order and the structure of the managing your content section is spot on. i think they're pretty similar, but his might be slightly more approachable for very new users. just my 2 cents. ;)

i'm ambivalent about putting the homepage first but agree that adding links could probably be merged into the text editor page so it's not its own page.

thanks so much again for taking this on. there should be enough people following this thread to get reviews pretty quickly. setting back to needs work, and you can put it to needs review again when reviews are needed!

@Fanaile: You are right, the original deals with 403/404 pages. I wouldn't want a newbie anywhere near the server logs, or you will never see him/her again. ;-)

Frankly, I think rich text editors are a blight on the web. I've built sites for the most computer-illiterate and they did fine without one. But they seem to be popular for a lot of people. I would move that to the added functionality section. I still fumble with setting up some of them, I'd hate to see what a total newbie could do.

Under menus, I'd like to see the basic, standard menu discussed with the other stuff clearly identified as "you may not need this now." As I said, I have used secondary links once, primary links a bit more often, but nowadays, I mostly use a theme that has Superfish running right off the Navigation menu.

I think rich text editors can cause issues also, but many people want them, so they should be addressed, at least in the context of input formats.

I don't think much detail needs to be given about primary/secondary links, but it should be included and clearly marked as optional. Some of what John Albin said at Drupalcon about Information Architecture in Drupal would be great to include in the menu section, as he identified modules that are really useful, even for newbies, in extending Drupal's menuing capabilities.

Superfish/Nice Menus should be at least mentioned as well.

403/404 pages should be mentioned, I agree - but I am not sure where in the hierarchy that would go.

I do think that the Dblog should be mentioned as well, though, since newbies will often eventually have to go there to debug issues, even if they have someone from #drupal-support or the forums/issue queue walking them through it.

I do agree with all that. And I alter my stance on primary links as a result of an email I received last night. Themes, notably Garland, may use primary links to make certain functions move to the header region to be more visible. (Okay, the same with secondary links, but I rarely see them used.)

Evan, keep thinking of the upside down funnel, or even a spreading tree. Give them a small opening to start, with ever expanding facilities. It's just like when you were in school; you learned 2 + 2, then 2 x 2, and many years later y = 2x + a. Let them see something, even if it's nothing more than "Oh, wow, I created my first Drupal site." Then they can put that into a menu (block), then add tags. Then create another piece of content with some of the same tags that they can click on to see why tags are useful....

Hmmm. I think I'm either going to just find a random newbie and ask him/her in what order they build a site and follow that? Or just follow the flow that's already established by the actual welcome screen:

Welcome to your new Drupal website!

Please follow these steps to set up and start using your website:

1. Configure your website Once logged in, visit the administration section, where you can customize and configure all aspects of your website.
2. Enable additional functionality Next, visit the module list and enable features which suit your specific needs. You can find additional modules in the Drupal modules download section.
3. Customize your website design To change the "look and feel" of your website, visit the themes section. You may choose from one of the included themes or download additional themes from the Drupal themes download section.
4. Start posting content Finally, you can create content for your website. This message will disappear once you have promoted a post to the front page.

Naomi, asking newbies is a great idea, although they don't know what they're doing, which is why we have the Cookbook. Remember those "instructions" were written by core developers who are about as far removed from newbie status as possible. You and I might be able to create a site by that list, but not a newbie who has no clue what that even means.

Also, Fanaile, you should bear in mind that the welcome screen text was removed in D7 because it was not helpful. Looking at the D7 new user flow would be much more informative, I think, in seeing what might be a good entry point.

NancyDru, I hear you about the expanding funnel. It's just that I don't really know how to represent that in a hierarchy. So grouping by major task/topic seemed to make more sense. Still, I tried to put the more advanced stuff at the end/further down the tree. My assumption is that people wouldn't read the whole Cookbook sequentially, but jump around based on what they wanted to do, as long as the headings had logical names.

Okie, I've completed the first (or, what could possibly be the first) section of the cookbook.

It's not very technical, but I think that was sort of the point, right?

Anyway, this idea came to me from a newbie. I had installed Drupal for him, and he said he could go from there... So I emailed him and asked him if he had any questions, and his first question was "what the ^%$*^@! is a node?" LOL. So that's where I came up with this order. We can always move the section around if people don't like it :)

I've attached it as a PDF file.

Would it be possible to add anchors to the topics within the documentation pages. I just sent a user to http://drupal.org/node/120632 and had to tell them to scroll about a quarter of the way down the page to learn how to add a link to an existing menu.

It would be great if I could send a link to a user such as http://drupal.org/node/120632#newLinkExistingMenu

I can do it on this page if it is allowed.

Cheers

Ha ha, Fanaile. At the Drupal Camp I got to speak in the last session of the day and I don't know how many of the attendees said they wished I had been up first so they would have known what a node is. All day long at a Drupal Camp, and they didn't know what a node is until they saw my pictures. If you want my slides from that (see the link in #10), they could be helpful.

We're on a good track here, but I just wanted to put a quick reminder out that we want to avoid duplicating content as well. So things like basic descriptions of what things are should actually go on... the terminology page! http://drupal.org/node/937 and then put a link to the description's anchor there.

If there's more complex options that are sort of not so newbie oriented, then it's probably best to stick with the basics and then link out to the existing more complex info from there. The less we can overlap content, the better, then it doesn't get out of sync!

I had thought of that and I knew that the terminology page was there, and I was going to point toward that... The only reason that I thought those particular terms should have a more in-depth description without the use of further jargon was because the terminology page isn't beginner-friendly (if that's a term).

I mean, I don't know - I'll defer judgment to others. Just to me, it seems like the terms that are used all the time, including in the beginner's handouts, should get more attention than normal terms.

That's fair - I guess still link to the terminology page from the "beginners" descriptions? It's a good reference to point people at anyway. And we'll just have to make sure to keep everything updated. ;)

I have to disagree. While, for example, the description of "node" is accurate, if not overly terse, in my experience it is an inadequate description for newbies.

There are a few basic terms that really need more descriptive discussion and need to be addressed in the Cookbook. Trust me the newbies will appreciate it. As we used to say in the South, "I cain't spell Drupal. but now I are one." There is no such thing as too much information when you're hungry for it.

Just to clarify, I didn't say this information shouldn't be documented, just reminding that duplication of content = double the maintenance. We should try and cross link rather than duplicate info when it makes sense.

Hi folks: Sounds to me like this discussion is pointing to work needed on some terms in the terminology page that might need an intro (the "terse" version, and an added section for new users. So, while working on the cookbook, we might write up the added description needed.

@Arianek Is there a desire to keep the term descriptions short in the terminology page? Any way around that?

Oops, rereading that, I want to clarify: the added section might be a second paragraph, not a new section in the terminology page.

I agree about rich text editors... however I think it's worth discussing whether the cookbook is for first-time site builders, or first time users of sites built by someone else. If your site was built by a developer, they made the decision about rich text editor.

Which newbie is this cookbook for? Perhaps it would be good to clarify "beginner" in the title.

And may I put on my accessibility hat for a moment and say that I always specify non-dropdown secondary menus due to accessibility concerns, unless a mega menu can be used.

Edit: sorry, I now realize that issue queues don't thread comments. This was in response to comment #22.

Hiya :)

I'm taking it to mean either one - either it's a beginner who has just installed his or her first instance of Drupal and will be moving on to set up his site and start adding content, or someone who hired another person to install Drupal and even if that person set the site up for him he still wants to know how to structure the site and add content.

My initial vision was for the new builder. However as I have now become a Drupal consultant/contractor, I often use parts of the Cookbook to educate my customers about Drupal. The structure for each kind of beginner doesn't work to well, but I haven't ever seen a book that asks you what kind of user you are and then restructures itself (sounds like an interesting module idea though).

@mlangfield: Go back to my video link in #10 and see, for example, how I now explain "node" to new users. That description probably does not belong in the general terminology page, but, IMHO, it definitely belongs in the Cookbook, and judging by the response of the people attending that session, I think they would agree. [My slides are available.]

Hi @Fanaile, @NancyDru, I love the idea of the book (or dashboard) restructuring itself, that's what I'd love to see. I came to Documentation a week ago to see what I could contribute, bounced around on some of the Prairie Initiative threads, the Wordpress.org vs Drupal.org discussion, got to know Fanaile in a LinkedIn group, etc.

I'm a web manager, among other things (like info architect and designer), and have instructed an editorial team how to use Drupal for content administration for this site (www.ipmglobal.org which I revamped in Drupal, my first big Drupal site). Somewhere, somehow, if Drupal is to be used by large organizations, web managers, web editors need some support. too, or they steer back to other CMS's. I don't know if this is where it will be, but it feeds into an idea I had that when a person registered on drupal.org, they could select from four or five user profiles:

Influencers: (press, VPs commissioning sites, etc-that might be the default for non-registered, like what we have now if you're not signed in), with marketing info:
Users or Managers: (site owners, web managers, etc.)
Builders
Developers (module and core)

Your dashboard would serve up content specific to your profile. So, support would be tailored to the role.

I suppose that's too complicated (seemed to span several initiatives). Still, some of the discussion above would be clarified if we decided the Cookbook is for the first-time site builder, rather than site manager. And add that in an introduction.

Then I might suggest site users/managers need a parallel Cookbook, what might be 80% the same material, with a few pages that would be different. Could be done using views and taxonomy, I would think.

I hope I'm not needlessly complicating things. It's just that I see the need for this.

@mlangfeld - if you want to pursue the ideas of a dashboard, do you mind starting a new issue (or thread on g.d.o)? feel free to post a link here. thanks!

as far as the target audience, i agree that it's fine to keep it both for beginner devs/site builders, as well as for site admins who are starting out. a lot of the configuration applies to both!

@arianek: I agree, but it might be nice to "warn" new admins on existing sites that things may have been set up a bit differently than the vanilla sit we document.

Sorry about that Ariane. Will do.

@nancydru - sure thing, no harm in that!

@mlangfeld - no worries, just want to keep each task separate. ;)

Moving forward with a rough-around-the-edges version of #15. Documentation will be written in a way to be useful to non-designers and non-developers.

Those with CMS background can honestly start with the Structure Guide easily.

@cleverington - I see your work on http://drupal.org/node/1279248 and nearby. I'm really liking it, thanks!
On the strength of this, I'd wonder if you could be bumped up to documentation maintainer role on drupal.org - to give you the ability to work with images on those pages. That navigation page really needs some screenshots, then it would just glow!

I know your account doesn't show much history on d.o, - but I wouldn't want that to hold us back from giving you encouragement and the tools needed to make these pages better.
Do I hear a seconder?
(this would be a new issue on the webmasters queue, but I'm starting here to get these eyes on it)

@dman - I was hoping to rewrite a number of them with the intention of asking for admin here in a couple of weeks after I get a) some solid 'work' done for examples of my intent, and b) get a whole bunch of screenshots, animated gifs, etc. with arrows and pointers ready.

I'm going to be dumping my server @ e8business.biz this weekend to have only base Drupal, a generic Omega subtheme, Views, and a few others of the Core-But-Not-Core modules so that I can generate screenshots a lot faster.

Excellent. No hurry, but it would probably be easier to do the screenshots as you go.
If you are comfortable getting a few more solid pages done first, I understand. Make an application in the webmasters queue whenever you feel cool with it.

Hi @Fanaile,

Thanks for taking this on. Are you still working on this issue? If not, we'll unassign it in a day or two so that someone else can give it a try. (Feel free to assign it back to yourself if you'd still like to work on it, as well.) Thanks!

A group os us will work on this at DrupalCampMD

The group of us looking at this at DupalCampMD are getting stuck on the outline. Seems to me that this has to sorted out first so content can be restructured and cleaned up.

We've jumped in working on the "Setting up maintenance tasks" section and reordering to fit the outline at #17.

In the proposed new outline there's a topic "Browser tips for accessing your site maintenance tools". We think that this doesn't deserve its own topic so we're putting it on the "Setting up maintenance tasks" page.

As part of the DrupalCampMD group trying to help move this in the direction discussed above, I was attempting to move and add to pages. Not all of them are available for editing by non-Documentation folks. This may be intentional, but if not, I just wanted to note it.

If they have images on them, that's why. I think it's changed but you used to have to be on the doc team to use images. You can file an issue to get those all switched.

Michelle

I've unlocked
http://drupal.org/node/120620
http://drupal.org/node/127454

From a manual check, those two were the only locked children of http://drupal.org/node/124931 I could see.
Please let us know *specifically* about any more locked ones you find.

Embedding images used to be a higher privilege, and therefore caused pages to become locked if an editor added images. Was "by design" at the time, but a better solution (images only hosted at d.o) now exists. We can unlock most of those lockdowns now. But not all, as high-profile pages d.o are still locked by design. Any doc maintainer can do this.

Just filed #1449652: Remove Cookbook (temporarily) from Docs homepage - I think we should take the main link to the cookbook off the Docs landing page while it's being updated, as it's super super out of date, and that maybe we can sprint on this (ie. post on g.d.o and drum up some help) between now and the end of Drupalcon. Whaddaya'll think? (Please respond on the other issue.)

I was thinking about learning a little more about using Drupal and cms in general as I have a site that I pay for such things and I am lost when even discussing it. Boy, what I learned by browsing this site is that at my 58 year old age, I am too frikkin old to take all this stuff in! I may come back after I get a few one on one lessons. Garry http://www.fishnfools.com

I checked through all the cookbook pages, and I found a few more I couldn't edit, but most of them have images. The list is below.

Regarding a sprint to get this cleaned up and ready for DrupalCon, I'd be game. I can't make it to Denver, but I'm up for joining you all remotely whenever. As a fairly newcomer to Drupal (about 8 months in), I think I can help out with the "beginner" perspective. I was a n00b not so long ago -- still am depending on your definition.

Locked pages (for me):

• http://drupal.org/node/120641
• http://drupal.org/node/120632
• http://drupal.org/node/120642
• http://drupal.org/node/120644
• http://drupal.org/node/120624
• http://drupal.org/node/120634

Unlocked them.

This issue is ancient, but I'd like to take a crack at helping with this if it's still relevant.

Sure, you can always feel free to edit any page in the Community Documentation section, and any improvements would be welcome!

I'm at the DrupalCon Sprint and will look at the Cookbook after lunch.

1. At first glance, it's difficult to determine if some of these comments were implemented. I will attempt to do this.
2. Drupal 7 is the focus of this cookbook. Is it worth spending much time on it? Is a Drupal 8 Cookbook under development? Should the status of this issue be changed Closed/outdated?

I'm interested in thoughts on this issue. Almost all comments are 4 years and older.

Thank you @isiteit for posting your thoughts after reviewing the task; it's very helpful to have someone take a holistic look at a task that has sat untouched for a while. I am working on this thread at one of the 2016 DrupalCon New Orleans Core Mentoring Documentation Tables.

I am not sure this issue should be worked on much further, but I do think it needs someone to review in-depth and update the issue summary. If there are active tasks remaining to be done, those tasks should be given their own issue thread (which can link to this issue). If there are no active tasks remaining, or once we have established issue threads for all active tasks from this thread, this thread should be closed. The nature of the fix is undefined and the scope of the issue is quite large.

isiteit--if you want to tackle the assessment of this thread and you want help, let me know and we can set up some time to work together in irc.