Here is a list of the D7 core module Handbook pages that need reviewing, and likely updating. Please post here for any general discussion or to put dibs on a page. (Handbook pages that already have issues I've noticed are linked here, pls add any I've missed in comments, and I'll roll them into this post.)

If any need major updating, you should probably open a new issue for it and post a link here. Also, if something needs a lot of updating, but looks like it's been maintained well, or just if you have any doubts, it is probably a good idea to try and contact a module maintainer and make sure that you are on the same page.

Will need to double check on what the approach is regarding deciding what to archive vs. just update, and how to manage versions. If anyone knows the system (before I get to asking someone) please post here and inform the masses! ;-)

aggregator - reviewed by technivant no tech block - done
block - reviewed by technivant - has tech block - branching #1153220: Block module docs cleanup
blog - reviewed by technivant - no tech block - branching #1153252: Blog module docs review
book - reviewed by technivant no tech block - done
color - reviewed by technivant no tech block - done
comment - reviewed by LeeHunter no tech block - done
contact - reviewed by LeeHunter done - no tech block
dblog - reviewed by LeeHunter
filter - reviewed by LeeHunter
forum - reviewed by smiro2000 - #895230: Working with forums in Drupal 7 & 6 -- Combining & Reworking
help - reviewed by LeeHunter, bmadore - #569142: Handbook page on help module needs better information
image - reviewed by DjebbZ, needs work #1019030: D7 Core Image docs
locale - reviewed + updated by LeeHunter
menu - reviewed by LeeHunter done - no tech block
node - reviewed by LeeHunter done - no tech block
openid - reviewed by DjebbZ and batigolix
path - reviewed/updated - arianek
php - reviewed by LeeHunter
poll - reviewed/updated by framlinggroup
profile - updated by LeeHunter
rdf - reviewed by LeeHunter (see comment#34) related: #1003544: Drupal 7 RDF documentation page on says it's a contrib D6 page
search - reviewed SqyD, needs work?
simpletest - #261616: Update the testing docs - #580076: Simpletest handbook does not cover unit testing
statistics - reviewed by batigolix
syslog - reviewed by SqyD
system - reviewed by SqyD
taxonomy - to be reviewed under new issue #1125284: Update D7 core Taxonomy pages
tracker - reviewed + updated - richard eriksson, arianek
translation - reviewed + update by LeeHunter
trigger - reviewed and updated by jjkd - related #1113554: Finish editing of D7 core module page for Trigger
update - reviewed, overhauled - arianek
user - reviewed and fairly heavily updated by arianek

#25 forum-permission-d7.png42.34 KBsmiro


I've reviewed and updated aggregator, block, blog, book and color handbook pages against drupal-7.0-alpha3

I've done the comments landing page

I've reviewed and updated Poll -

Help is done.

I've actually moved it to the developer guide. I haven't addressed the associated issue noted in the OP, but that's not a D7 issue.

just updated the master list - thanks for all the reviews!

The locale module is done (needs more work but it's probably good enough)

hey lee - i was just looking at the forums page, and i see you updated it a bit (it looks fine) i'm wondering what we ought to do with tho. update it to be a d7 page (with any needed notes at the bottom for d6?) i don't think it's worth having 2 separate subpages... thoughts?

I'm going to do a d7 version of the forums using this approach:

also, image module........hmm. i spose we need to somehow indicate the changes that have happened in D7. which wouldn't be a big deal except wow, the image section has got a lot going on that's all child pages of the image module landing page. (i'm assuming this is why you left this one for later!)

i think i'm going to start at the end of the list and work my way up to meet you.

re: forums, awesome that looks very logical and user friendly.

user is done

update is done, could probably use a second set of eyes

about to do path

Reviewed and added some references specific to Drupal 7 and tagged the page as such.

For Tracker, added some more details on the menu items and paths to pages for d6/7, cleaned up the formatting and language a bit more. Looks good now.

Done profile.

Reviewed RDF. Much of this is developer/themer content which I can't evaluate. I've posted a note on the Semantic Web GDO asking for expert review.

new42.34 KB
new42.34 KB

updated the working with forums in D7 page
also opened an issue Q for having it reviewed, sorry...

Reviewed syslog

Reviewed help Added access information which had been edited to include only info relevant to Drupal 7. Made minor spelling and grammar changes.

I've reviewed search and although it has D7 specific instructions I have a few issues with it:
A lot of cron specific text that might be replaced by a reference to the con handbook. Also no mention of the "poormans cron" in D7 and its missing a lot of other (D7 specific) settings.

Should we rewrite this?

I reviewed the OpenID handbook page with batigolix. The functionality is pretty much the same in D6 and D7. We can mark it like reviewed !

reviewed and slightly modified system. Please review

Since the image module linked on top of this issue is actually for the contrib Image module, I created a new book page for the core Image module here :
I have no idea where it should fall in terms of handbook organization. It may need review and/or screenshot.

YOU GUYS + GALS ROCK! I've updated the main list with all the new reviews and links to any new issues that were created.

SqyD - would be awesome if you can open a new issue and document your suggestions for the search/cron related pages. thanks!

DjebbZ - we actually do need to make those alterations either right on the old Image page and the D6 content into a subsection, or possibly move all of the image handling info over to the field module page. Can you open a new issue and paste a link to your page there noting this? Then I can talk to jhodgdon and figure out what we should do about that one, it's a bit tricky.

Only 3 in need of full reviews left!


I changed "Add a field to a vocabulary (Drupal 7 and later)" and made it link to since the field-ui is shared across vocabularies, content types, etc..)

@ericduran thanks, that looks good. did you work through any of the other taxo pages in the end?

I've done the translation page and done a quick and dirty cleanup of the whole translation section.

Someone just posted this issue about the RDF page - it is still saying RDF is a contributed module (which it was in D6), and it needs to be updated for Drupal 7.
#1003544: Drupal 7 RDF documentation page on says it's a contrib D6 page

I had edited the the Update manager page to include where you would find this module inside of Drupal and my revisions were removed due to style and coherency.

As someone who doesn't understand all the technical details, and a person who has been repeatedly frustrated with documentation and finding simple answers I feel it's important that each module contain the information about where you would find the module being discussed. I know I have to do something to the module... but how do I find it? Assuming someone is looking because they are at the module is an assumption that shouldn't be made. I ended up on that page myself after reading about the module elsewhere, and I still had no idea where it was located inside Drupal. It doesn't have to take hours of reading to find things if we include pertinent information simply. Where something is located on the page designated for the something being discussed to me isn't incoherent, but provides coherency.

Possibly the location I placed them wasn't the best choice. I think they should be at the very top. The 1st thing a person sees is where the module resides inside Drupal. Due to the new overlay, I'd suggest we just give a direct url location. Again make it simple. Simple is always imho best with initial documentation. Details and more information can be give below or on a linked page.

I propose adding the following to the top of the page, and to add the same type of locations to any page discussing a core module.

Drupal 7: found under Core heading Update manager
View log of available updates:
Edit settings:

Drupal 6: found under Core optional Update status
View log of available updates:
Edit settings:

@uneedstuff - so you were just wanting to add the paths to the update manager admin pages?

if so we should add that right into the paragraphs where it's first mentioned (we don't tend to just put lists of the paths to admin pages separate from the content).

the section of the style guide on formatting the paths is here as well just for reference:

@arianek, yes I think it is easy to forget that people who don't know Drupal, don't know where to find what is being discussed. I had no idea where to find it myself.

Yes, I know you don't tend to just put lists separate from the content. A person has to read through the entire text just to find where something exists, hence why I'm making a suggestion to change that idea and thought pattern, and make it easier to find that information.

Where something is located is imho the most important information to share when you're talking about a setting or module. Hence the suggestion to place the location right at the top, then people know where everything being discussed can be found.

@uneedstuff - thanks for elaborating, i think you make some good points. though i'm not too keen to break up the paths to admin pages from the content (because i do think it will make the pages more chopped up), but i'll definitely make a point to be more mindful of putting in some of that more basic information/links into these main pages where it makes sense. also, just as a side note - links to all of the admin pages/sections for various modules can be found from within your d7 site, in the help pages in your drupal install - so eg. for blocks admin page, you can find the links to it from the blocks help page eg.

we also need to rethink how the "beginners" section of the documentation ( plays a role, and whether it can be updated to cover some of this basic info in a more condensed way.

also, i think that this will become a lot easier to manage when we develop features for the documentation to have conditional text so that we can have level-specific information added onto each page without making it too long.

(i know this isn't a super straightforward response, but just some wider context of how we might support beginners better!)

@arianek ah! I didn't realize how much more or easier it is to find the information inside of the drupal installation. Click on help and bam tons of information. Not that I don't feel it's a good idea to let people know simply where something is, but that does make a difference. I had quite looking in help as I hadn't previously found it helpful. Not sure who did that work but great job!

@uneedstuff aha :) this makes me so happy to hear! jennifer (jhodgdon) and i with a bunch of help from a few other docs team members overhauled the core help stuff for d7 about a year ago - i'm so pleased that you find it more "help"ful!

image module page/section really needs work, i've filed an additional issue: #1019030: D7 Core Image docs

Working on trigger

Working on to update to style guidelines.

1st pass on trigger complete, if I can get some feedback, that would be great!

jjkd: The trigger page looks OK, but I think it could possibly use more detail. Things I think could be useful:
- explaining what an "action" and a "trigger" are at the top, after the first sentence.
- explaining what the 5 categories of actions actually mean ... actually they are not really categories but correspond exactly to the modules that define the triggers, so I might say something like "Triggers are grouped in the administration pages by the module that defines them".

It also needs a bit of style/copy editing, as noted in the page status.

Ok, I believe I have addressed all the comments on the page for Trigger. If you agree, please mark it as complete in the description section of this issue above, and let me know. I will then remove the style/copy tag on the page.

If there's additional work to be done on the Trigger page, please let me know. Thanks!

Status:Active» Needs work

I reviewed and it is definitely closer, but I think it could still use a little bit of work:

a) Copy/style/capitalization/punctuation review - I saw a few things that needed fixing, nothing extremely major

b) Consistent terminology. In D7 at least, the events that cause actions to fire are called "triggers", not "events" or "trigger events" in the inline help. Let's use that terminology on this page too.

c) The Actions admin page in d7 is under Administration > Configuration > System > Actions

d) D7 developer section should also tell how to define actions (hook_action_info

e) In D6 the tabs are not the names of modules. This needs to be made clear in this doc page, because as it reads now, it makes you think that "content" is a module name. It isn't. Also, is the "comment" tab called comment or comments?

f) d6 - Actions are not under Site building in the menu system, but actually under Site configuration.

g) See item (d) above - also applies to d6 where the hook doc is at

Issue tags:+Sprint: April 2011

jjkd - are you able to do the suggested edits from jhodgdon (comment #51), or does anyone else want to pick that up?

Yes, working on it. Sorry to clutter up this meta issue with so much specific to one page. I should have created a separate issue for it, but I didn't think this was going to be so involved, I will do so now and seed it with the issues from #51.

Ok, it is now #1113554: Finish editing of D7 core module page for Trigger

I think the discussion of Drupal-specific terminology may have implications for our glossary. If necessary I will open that as a separate issue in addition to the fixes needed on the Trigger page.

jjkd - thanks for the update! i've updated the list at the top to reflect your review and the new issue.

As noted on the other issue, Trigger page now looks good - thanks!

Awesome - thanks (updated the list)!

Do we have a particular way to indicate the status of the remaining module pages in this issue? I only see a few that seem to be marked as complete, but I'm not sure how to tell which pages are considered finished or not and which still need work.

if it says it's been reviewed by one person, that's pretty good (and means that the content should be accurate) - but we probably want a sweep through review on all at the end to make sure the style is relatively consistent. (or at least on all that don't have large problems with separate issues.) if there was major issues with any, additional issues have been filed (and noted above).

so, to review, it looks like taxo is the last one needing a run-through, and then we can set this to "needs review" for a final once over of all pages that don't have outstanding issues.

i very much like the style on and have been pointing people at that for an example of an ideal completed page.

so anyone want to give taxo a detailed review and update to d7 info, then we can do a final review?

As part of Sprint: April 2011, I'm trying to wrap up the pages that are ready or just need light formatting. Will list here as they are done. Beginning with Taxonomy. Created new issue for that: #1125284: Update D7 core Taxonomy pages.

I like how the field-ui page has a section at the end called Technical details:

Technical details

Core module: Yes.
D7 Core Profile: Standard.
Dependencies: Field, Field SQL Storage module or custom storage module.
Related Modules: Field, Field SQL Storage, File, Image, List, Number, Node, Taxonomy, User, Text
Permissions: None.
API Documentation: Field storage API
Database tables: None.

I'd like to add a section like that to all module pages, for example:


Technical details

Core module: Yes.
Dependencies: None.
Related Modules: None in core.
Permissions: Administer news feeds, View news feeds.
API Documentation: ?
Database tables (4): aggregator_category, aggregator_category_feed, aggregator_category_item, aggregator_feed, aggregator_item


Technical details

Core module: Yes.
Dependencies: None.
Related Modules: Dashboard.
Permissions: Administer blocks.
API Documentation: block.api.php, block.module
Database tables (4): block, block_role, block_custom, cache block.


Technical details

Core module: Yes.
Dependencies: None.
Related Modules: None.
Permissions: Administer blocks.
API Documentation: blog.module
Database tables: none.

That is an interesting idea. However, a lot of those "technical details" are highly dependent on the Drupal version, and those module pages go for d6 as well as d7 (and in the future, d8, etc.).

I think I would also prefer to lead people who would need those technical details towards knowledge of how they could find this information for an unknown or contrib module in the future, rather than (or in addition to) listing the information directly (which might get out of date and would be complex to list and get all the version changes right):
- Database tables - make it a link to the hook_schema() function for the module on, which not only lists the tables but also shows the fields and other details. Plus they could easily then switch to the d6/7/8 version as needed to figure out what has changed.
- Permissions - make it a link to hook_permission() for the same reason.
- Dependencies - link to the file, which lists dependencies (I think there's a way to browse the git repository and make a link to a particular file? Again that would let them switch between versions relatively easily).

That's a good point. I don't want to simply duplicate. I like the idea of linking to those areas of the api. So I could have the same structure, but more links to the api?

i actually really liked that block - ken rickard did that on the field ui page and i've been considering making it into a module docs standard. but if it makes sense to link into the API for some sections that's cool.

@carolyn if you want to add those ones you wrote up to the docs pages, i think that'd be great.

Fairly heavily reworked/updated for clarity and to conform to style guide (i.e., replacing terminology such as "Weblog"). Would like to have this reviewed, please! Thank you.

#63/64: The problem is that you need to be careful about the database table names and permission names -- many of them changed from d6 to d7. So while that block may be handy for Field UI, since that is new in d7, for something like block or filter or etc. it would get fairly messy to list the db tables and permissions for all the versions. IMO.

For instance, the proposed text for the Block module in #61 is probably right for d7 for instance, but in d6 the "block" table is called "blocks", and there is an additional permission that is not even present in d7. Permission names should not be capitalized either (I think). And there are actually 7 files on the API site that are part of the block module in d7, not just two (the total is not the same in d6).

So... I think it needs some thought and care if you want to do it right.

Well, we can just explicitly title the section at the bottom "... for Drupal 7" so there's no confusion, right?

New version


Technical details for Drupal 7

Core module: Yes.
Dependencies: None.
Related Modules: Dashboard.
Permissions: Administer blocks. Also see the API docs at block permission.
API Documentation:, block.api.php, block.install, block.module, block_test.module
Template files: block-admin-display-form.tpl.php, block.tpl.php
Other files:, block.css, block.js
Database tables (4): block, block_role, block_custom, cache block. Also see the API docs at block schema.

Also, I don't think Dashboard has been mentioned in this issue.

looks great to me :)

the new d7 core modules were done on a separate issue - they probably don't have the tech details block, but are otherwise finished.

I'm going to do final reviews on all modules starting with "c" - color, comment, contact

The proposal in #68 looks good to me too. :)

did some small tweaks to but i don't know the module well - if anyone else does and wants to improve the d7 specific info in particular, go for it! calling it done for now, but left the page as "needs updating. it also doesn't have a tech details block.

I looked at the color module page and made a few edits. I thought I read that the color module will re-color up to 5 regions, so I'm not sure if this first line is strictly correct:

The Color module allows a site administrator to quickly and easily change the color scheme of a site, with the exception of the background, which stays white.

I also added a header called "Uses". I liked that header in the Fields UI page, and I think it would be another thing to consider adding as a "standard" section. I envision something like this:

[1 - 3 lines introducing the module]


[use cases - why you would need this module]

How to use...

[configuration instructions and options.]

Technical Specifications for D7

Thanks! I have been meaning to write up a standard for the module pages for a looong time. Maybe a separate issue to work on that? Bet we could get one defined pretty quick. In fact... #1142004: Create Module Docs landing page standard there we go!

Can I get a 2nd opinion on (comment module d7) - comment module is already split into versions, but there are so many small subpages... I am inclined to merge all the D7 pages back into a single page formatted around this theoretical standard.

I think the D7 UI for comments changed a bit, while many of the concepts are the same. D7 also has fieldable comments, thus adding two new tabs about comments on the content type page.

this page has very detailed descriptions and explanations of the D6 comment settings UI:

Besides that page, which could probably be tightened up and better with a screenshot, there isn't much to the d6 comments docs. Some of this page may be useful descriptions of general comments features that also apply to d7 docs (and could be copied over as appropriate).

We could start by fixing up and writing the "ideal" D7 Comments docs, then see how easy it is to roll the d6 docs in.

I am working on the Technical Details in alphabetical order. Right now I am working on A-F.

For the Color Module:

Technical details for Drupal 7

Core module: Yes.
Dependencies: None.
Related Modules: None.
Permissions added: None.
Permissions needed: Administer site configuration.
API Documentation: color.install, color.module
Template files: none
Other files: color-rtl.css, color.css,, color.js, color.test, preview.html, preview.js, images/hook-rtl.png, images/hook.png, images/lock.png
Database tables: none.
See also: themes/bartik/color/, themes/garland/color/

Hey Carolyn -

Something occurs to me - maybe we should start a new issue to work on making all the pages consistent? This one was really targeted at just updating the content to be accurate, and I think that it's become daunting enough as is. ;) (And we could deal with merging pages, etc. then too.)

You mind tracking the tech details blocks on a new one? Or you think that it will take a short enough time that it's not going to drag this one out too much?

For now I'm going to continue on to Contact module.

Just got distracted merging 5 tiny pages into - roughly made it comply with but no tech block. Calling it done for this issue.

Tackling menu next.

Just got stuck in merging a bunch of tiny pages into as well. Marking that one done too.

Node next.

Issue tags:+Sprint: May 2011

tags - i'm going to keep working on this for may

There was hardly any content in the page - I added in the D7 node help content to create the "uses" section, and the configuration is in subpages, so I didn't update it. Done enough!

reviewing aggregator - done, that was a quick one, nothing too terrible, despite the pages being broken up and formatted a little oddly.

block needs more rearranging, branching to new issue #1153220: Block module docs cleanup

blog needs love too, new issue #1153252: Blog module docs review

book was not terrible, marking done

reviewed comment, thought it looked familiar, realized i'd written most of the d7 docs :-p marked done.

Issue tags:+Sprint: July 2011

Status:Needs work» Fixed

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.