I agree 100%. I've had clients that use SVN or CVS and nothing else.
12 should be optional. Numerous times I can build a theme from scratch much quicker than using a starter theme. A lot depends on client needs. You get their design and they want everything to the pixel and a lot of times getting that from a starter theme involves tons of CSS overrides.
15 I think is also optional. I've got over 50 clients and only 2 use multi-sites. I also like a little better structure:
/sites/*/modules/contrib /sites/*/modules/custom /sites/*/modules/devel
It just keeps everything more organized.
I do like the overall idea though. I've taken over client sites from some big name Drupal shops before that are a nightmare. It makes you wonder if they hired some kid off the street and said "here, make this site" without any guidance or training.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
On 9/20/2012 10:03 AM, Ken Robinson wrote:
I think that number 5 shouldn't specify a particular version control application.
Ken
At 09:13 AM 9/20/2012, Ms. Nancy Wichmann wrote:
I have recently started a full-time gig, after several months of contracting. In reviewing several extant sites, I identified several practices that I don't care for. So I mentioned the possibility of putting Drupal guidelines into place. They won't really be Commandments and I already have more than ten.
What rules/guidelines would you suggest so that we consistently produce the best sites we can? Here's most of what I have now:
- Follow Drupal Coding Standards; use lots of comments.
- No PHP nodes.
- No PHP blocks. (A sample block module is available.)
- Minimize PHP in Views.
- All code in Git, if possible. (It is best
to create the repository even before using install.php). 6. Use Features for content types and views; and for other things that lend themselves thereto. Commit these to Git repository. 7. Security updates should be scheduled in the project’s issue tracker to be done as soon as practical. Other updates should be reviewed for priority and scheduled accordingly. 8. For views that have a block with a “more” page, limit the View to those functions so you can use the built-in more feature. 9. CSS is your friend, use it before programmatic or theme styling as much as possible. 10. Look for existing solutions before writing a custom one. 11. Even if it is not a project requirement, building an accessible site is better. 12. Themes should be built on a standard starter theme (Zen, Omega, Fusion, etc.) 13. Block visibility addresses should be URL aliases rather than node numbers. 14. Links, including menus, should use relative URLs. 15. Given that most sites will be in a multi-site set up, contributed modules should reside in sites/site-name/modules and files in sites/site-name/files.
Views block names: views-name: function-name Code block names module: function-name
Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. -- [ Drupal support list | http://lists.drupal.org/ ]