Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
documentation
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
2 Dec 2010 at 18:34 UTC
Updated:
3 May 2011 at 21:29 UTC
Jump to comment: Most recent file
Comments
Comment #1
jhodgdonWe could maybe have a few update groups, like "system", "node", and "miscellaneous". But having a group for each module seems rather silly, since they're already grouped on the whatever.install file page.
Comment #2
blackjack48 commentedMy sincerest apologies for not starting on this task sooner. I've been very busy this week getting ready for the holidays and finishing up end-of-the-year business. Due to the Christmas holiday, I will most likely either need an extension or I'll need to withdraw from the task. This task was more involved than I had anticipated, but I'd be willing to give it a shot in the coming days.
Just to clarify, is this the way to merge groups together?
Old code:
/**
* @defgroup update_manager_update Update manager for updating existing code.
* @{
*/
/**
* @} End of "defgroup update_manager_update".
*/
/**
* @defgroup update_manager_install Update manager for installing new code.
* @{
*/
/**
* @} End of "defgroup update_manager_install".
*/
/**
* @defgroup update_manager_file Update manager file management functions.
* @{
*/
/**
* @} End of "defgroup update_manager_file".
*/
New code:
/**
* @defgroup update_manager Update manager functions for updating existing code, installing new code, and file management.
* @{
*/
/**
* @} End of "defgroup update_manager".
*/
Comment #3
jhodgdonThat would work if those three groups were defined in one file, and were never used elsewhere. If the groups were used elsewhere, you would also need to find places where it said things like:
and change those to use group update_manager instead.
Comment #4
jhodgdonJust as a note:
This has been added as a GCI task
http://www.google-melange.com/gci/task/show/google/gci2010/drupal/t12933...
The task is currently unclaimed. blackjack48: do you intend to claim it?
Comment #5
h_peter commentedI have claimed the corresponding GCI task.
Comment #6
jhodgdonh_peter: OK. You can ping me on IRC or ask questions here if you need some guidance. Thanks!
Comment #7
h_peter commentedI have added summaries and short descriptions to some topics and merged the update groups into three groups (system, node, miscellaneous).
However, I'm not sure whether the assignment is convenient for each group.
Comment #8
jhodgdonGood first pass, thanks!
A few notes/to dos:
a) Several of the added lines have spaces at the end. Please remove them. Some editors have settings that will show you spaces at ends of lines, or a function to remove those, so you might investigate in your text editor of choice.
b) I like the idea of having a few groups of update functions, and system, node, and misc makes some sense to me... but I'm not sure about how you have divided them. For instance, I don't think Block should be part of the Node group, and maybe the Field Storage SQL updates should go in "misc" and not "system". Same with Statistics. So... maybe the choice of which modules to be put in which group needs a bit of work.
c)
If you are doing @addtogroup, then you shoudn't have descriptive information here. Maybe you meant to have this be @defgroup? The Node one in node.install has the same problem.
d) There are a LOT of groups in the Translation module. I wonder if they are even necessary?
e) A big chunk of documentation got cut:
We probably need that documentation somewhere. If it's an empty group, then we need to put the documentation somewhere else. Not sure where off-hand.
Comment #9
h_peter commentedThis should fix the mentioned to dos.
The Field API data structures documentation is now in the Field API group but maybe this part got too long, because it contains some parameter descriptions that are not displayed on api.drupal.org.
Comment #10
jhodgdonThis is looking good.
We should file a separate issue on the @param in @defgroup not being displayed. That information that is now in the Field API should be presented in a different way. It is not function params, and shouldn't be using @param. It should be presented as a list... I'll file an issue shortly.
Only a couple of things I would suggest changing in the current patch:
- There is still a bit of inconsistency in which updates are assigned to which groups. For instance, the field.install updates are in system, but the field_sql_storage.install updates are in misc. I think those two should be together?
- The updates in openid.install are still in their own group (prob should be in misc)
- I think I would put the user.install updates in System not Misc too.
Thanks!
Comment #11
jhodgdonHere's the other issue:
#1011740: Wrong info presentation in Field API Structures
Comment #12
h_peter commentedMoved some groups.
Comment #13
jhodgdonThis version looks great to me, and the patch applies cleanly as well. Thanks!
Let's get this in, and then we can take one more look at the Topics page on api.drupal.org and make sure it is all up to standards. This should get us at least most (if not all) of the way there. Great work!
Comment #14
webchickReading through this patch as well as http://api.drupal.org/api/drupal/groups/7, rather than grouping updates as one of "system", "node", and "miscellaneous" (which just invites contrib to invent their own categories making that page even more of a mess), I think it's better for all updates to be listed under a single group.
I would suggest instead of:
+ * @addtogroup updates-6.x-to-7.x-system
Just:
+ * @addtogroup updates-6.x-to-7.x"
The actual @defgroup definition should be in system.install though, since that's the only one that's guaranteed to run.
(Note: Check with jhodgdon before implementing this suggestion.)
Comment #15
jhodgdonThat suggestion is fine with me too, and I agree that the defgroup should be in system.install.
Comment #16
h_peter commentedOk, all update functions are in the same group now.
Comment #17
jhodgdonLooks good, thanks!
Comment #18
webchickGreat, thanks!
Committed to HEAD. Great job, h_peter! :)
Comment #19
jhodgdonIt looks like api.drupal.org has already updated with this new information. This is obviously much better than before!
But I think there is a bit more to be done:
a) A few topics have first-line descriptions that are longer than just one line, such as Batch Operations, and I think Node API Hooks (and anything else that goes longer than about 1.5 lines on http://api.drupal.org/api/drupal/groups/7).
b) Several topics have non-standard names
- "indexing Taxonomy functions maintaining {taxonomy_index}." (should start with capital letter and not end with a period, and ... what does that mean anyway?).
- "Field language API" -- language should be Language, to be consistent with the other Field API sections.
- A couple other ones end in "." too.
c) At least one description is non-standard: Menu tree (doesn't end with .). Maybe this should just be merged with the Menu System group anyway?
Comment #20
h_peter commented– edited some descriptions.
(I have not merged the Menu tree parameters group with the Menu System group because actually it is a subgroup.)
Comment #21
jhodgdonActually, looking at http://api.drupal.org/api/drupal/includes--menu.inc/group/menu/7 you can see that there are 5 "subgroups" defined within the Menu group... I guess you are right that they can stay as subgroups for now.
Two minor things with this patch, which is otherwise great:
a)
I don't think this group's machine name should be "taxonomy". It should probably be "taxonomy_index".
b)
Wrap as close to 80 characters as possible. The first line is too short.
Comment #22
h_peter commentedComment #23
jhodgdonGreat! Let's get this one in, and then we can take one more scan of the Topics list and make sure we are really done.
Comment #24
webchickGreat, thanks for sticking with this, h_peter!
Committed to HEAD. Not sure how soon before you'll be able to see it on api.drupal.org.
Comment #25
jhodgdonThe changes seem to be up on api.drupal.org already, and I think we can call this one "fixed" this time. I'll update the GCI task appropriately. Thanks again h_peter!
Comment #27
Einav123 commentedbvgc