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/ ]
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/ ]
At this company we use Git and that is all. So, for us, it's okay to say that.
12. In D6, we had a standard theme based on Genesis. However, it looks like that theme is pretty much unmaintained. With our increasing interest in mobile-ready sites, we are considering using one of those to come up with a new "standard" theme. With the volume of sites we have, overrides are a way of life.
15. Yes, in D7 we are using /contrib and /custom, but our D6 sites are not going to be changed. We have almost 500 sites and essentially one admin, so multisites are a necessity to maintain his sanity (but maybe it's too late anyway).
But I am also looking for more suggestions to add to the list.
And, we all know that such a list is not going to make a bad developer into a good one. But it can help a good developer be better.
Nancy
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
From: Jamie Holly hovercrafter@earthlink.net To: support@drupal.org Sent: Thursday, September 20, 2012 10:20 AM Subject: Re: [support] Ten Commandments
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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-
Jamie Holly -
Ken Robinson -
Ms. Nancy Wichmann