[support] Ten Commandments

[Jamie Holly]

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:
> >
> >1.    Follow Drupal Coding Standards; use lots of comments.
> >2.    No PHP nodes.
> >3.    No PHP blocks. (A sample block module is available.)
> >4.    Minimize PHP in Views.
> >5.    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/ ]
>