The clean markup project cleans up the markup for the core Blocks module, and Panels.
The project contains three sub-modules:
- Clean markup API
- Clean block markup
- Clean panel markup
The Clean markup API module just provides some useful functions common to all clean markup modules: it doesn't implement any hooks of it's own.
The Clean block markup module allows users to change a set of options related to the markup for each individual block. The actual work is done in a Drupal way: an implementation of hook_preprocess_block and a custom block.tpl.php file that overrides core's. The options form is available from the individual block's configuration page (i.e.: admin/structure/block/manage/%module/%delta/configure). Configuration is stored in variables.
The Clean panels markup module allows users to change a set of options related to the markup for panel panes and regions. This is done through a Panels style plugin and custom template files. Users can make use of the module by changing the style for the pane or region to "Clean markup" and selecting options in the Panels dialog. Settings are stored by Panels. This module also provides some alternative panel styles.
Note: please review the 7.x-2.x branch (and optionally, the 7.x-1.x branch). The 7.x-3.x branch is currently in development.
Links
https://drupal.org/sandbox/rhache/1805074
git clone --branch 7.x-2.x http://git.drupal.org/sandbox/rhache/1805074.git clean_markup
Smooth review checklist
- Application checklist: completed
- Review bonus: none, sorry :(
- Intended Drupal version: D7
- Similar modules: none found
- XSS vulnerabilities: none found
- Translatable: done
- Uninstall variables: done
- Background and experience:
- mparker17 taught himself Drupal in March 2009 in preparation for a job interview at PeaceWorks Technology Solutions in Waterloo, ON, Canada. He got the job, and worked first as a themer, then a site builder and finally a themer-site-builder-and-module-developer on over 43 Drupal sites before leaving to join Myplanet Digital in Toronto, ON, Canada. Since joining Myplanet, he's worked on primarily the back-end of another 6 Drupal websites. He also has 6 commits in Drupal Core, reviewed a book on Drupal migration, and has contributed to a number of contributed projects. He also maintains the content and configuration on three other websites, his blog, Brady's Meat & Deli and Allied Flooring.
- rhache has been a part of the Drupal community for 7 years now and has contributed a base theme called LayoutStudio as well as Semantic CCK while helping build hundreds of Drupal sites. One of rhache main preoccupation with Drupal is developing tools that allow front-end developers to build sites with simpler yet richer semantic markup. He is currently working as a front-end developer at Myplanet Digital since June 2012.
Comments
Comment #1
mparker17Setting this to Needs Review.
Comment #2
Vasiliy Grotov commentedHello!
Please, take a look at Ventral report and fix the errors - http://ventral.org/pareview/httpgitdrupalorgsandboxrhache1805074git
clean_markup.info
files should be used for classes or interfaces declarations, not for .module files. Same for other .info files. (https://drupal.org/node/542202)
clean_markup_blocks.install
Please, add variable_del('clean_markup_blocks-defaults') to hook_uninstall().
clean_markup_blocks.module
Might be a good move to split hook_form_alter() into two individual hook_form_FORM_ID_alter(), since we care about only 2 forms.
Thank you.
Comment #3
mparker17@Vasiliy Grotov: thank you for your review! Here are my responses:
This has been fixed in all branches (commits
5d6f6ca,2329b58,26eec78).The module stores block settings as variables, so the code in hook_uninstall() removes all variables that start with
clean_markup_blocks-, so I can ignore this.I need to modify both forms with the same code, which is why I chose to do it the way I did, rather than creating two hook_form_FORM_ID_alter() functions and copy-pasting the exact same code, so I'm going to ignore this.
Comment #4
Vasiliy Grotov commentedNice work. [=
No need to duplicate the code. You can use common function with code, which hook_form_alter() holds right now and pass $form and $form_state by reference (e.g. &$form) in each hook_form_FORM_ID_alter().
So each hook_form_FORM_ID_alter() will use the same exact code and it will be called only with these two forms.
Comment #5
mparker17Fixed a bunch more coder issues from the report you linked to.
There's still a pile of errors in the one file: I'll fix those later today if I can.
Comment #6
mparker17The module is ready for review again.
Coder still complains about function comments spanning more than one line, but I can't make them any shorter than they are.
In regards to the
hook_form_alter()versushook_form_FORM_ID_alter(), I read the API documentation on hook_form_alter, which says thathook_form_alter()is called beforehook_form_FORM_ID_alter()(last paragraph before the Parameters section). This is exactly the functionality that I want — the ability for other modules to extend or override this one — so I've chosen to keep it the way it is.Comment #7
bhobbs-chitika commentedHello,
In regards to the comments, looking at the standars for comments a comment for a function looks something like
So the summary line should be short, hence the one line limit, and then a longer description can follow that.
I couldn't find any major issues with your code.
Good luck
Comment #8
patcon commented+1
Comment #8.0
alberto56 commentedAdding bio for myself
Comment #9
alberto56 commentedI enabled and tested your module on a test site. Here are some notes:
(1) In this issue description, you should set the git clone instructions to:
instead of
Otherwise we end up with a folder entitled 1805074 rather than one entitled clean_markup.
(2) The module works as advertised for blocks. I don't use panels so I could not test the panels submodule. From what I gather you are using the Drupal API correctly.
(3) Many users use the context module to import and export block placements between environments. Your module works well with contexts, and, because your settings are stored as variables, they can easily be imported and exported using the strongarm and features modules. This makes your module ready for a dev-stage-production workflow, not strictly necessary but appreciated by a growing number of users.
I'm setting this to RTBC as I believe it's ready for full module status.
Cheers,
Albert.
Comment #10
mparker17Thanks very much @alberto56!
I have changed this issue description as you suggested in (1).
Comment #11
mparker17@Rob Loach promoted this to full project status!
Comment #11.0
mparker17Changed clone instructions as suggested.