<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>At this company we use Git and that is all. So, for us, it's okay to say that.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><span>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.<br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color:
transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><span>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).</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><span>But I am also looking for more suggestions to
add to the list.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><span>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.<br></span></div><div> </div><div><font color="#ff007f" face="bookman old style, new york, times, serif" size="4"><i><b>Nancy</b></i></font> <br></div><div><font face="arial, helvetica, sans-serif">Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.</font></div><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-family: arial, helvetica, sans-serif; font-size:
12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Jamie Holly <hovercrafter@earthlink.net><br> <b><span style="font-weight: bold;">To:</span></b> support@drupal.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, September 20, 2012 10:20 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [support] Ten Commandments<br> </font> </div> <br>I agree 100%. I've had clients that use SVN or CVS and nothing else.<br><br>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.<br><br>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:<br><br>/sites/*/modules/contrib<br>/sites/*/modules/custom<br>/sites/*/modules/devel<br><br>It just keeps everything more organized.<br><br>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.<br><br>Jamie Holly<br><a href="http://www.intoxination.net/" target="_blank">http://www.intoxination.net</a><br><a href="http://www.hollyit.net/" target="_blank">http://www.hollyit.net</a><br><br>On 9/20/2012 10:03 AM, Ken Robinson wrote:<br>> I think that number 5 shouldn't specify a<br>> particular version control application.<br>> <br>> Ken<br>> <br>> At 09:13 AM 9/20/2012, Ms. Nancy Wichmann wrote:<br>> >I have recently started a full-time gig, after<br>> >several months of
contracting. In reviewing<br>> >several extant sites, I identified several<br>> >practices that I don't care for. So I mentioned<br>> >the possibility of putting Drupal guidelines<br>> >into place. They won't really be Commandments<br>> >and I already have more than ten.<br>> ><br>> >What rules/guidelines would you suggest so that<br>> >we consistently produce the best sites we can?<br>> >Here's most of what I have now:<br>> ><br>> >1. Follow Drupal Coding Standards; use lots of comments.<br>> >2. No PHP nodes.<br>> >3. No PHP blocks. (A sample block module is available.)<br>> >4. Minimize PHP in Views.<br>> >5. All code in Git, if possible. (It is best<br>> >to create the repository even before using install.php).<br>> >6. Use Features for content types and views;<br>>
>and for other things that lend themselves<br>> >thereto. Commit these to Git repository.<br>> >7. Security updates should be scheduled in<br>> >the project’s issue tracker to be done as soon<br>> >as practical. Other updates should be reviewed<br>> >for priority and scheduled accordingly.<br>> >8. For views that have a block with a<br>> >“more” page, limit the View to those<br>> >functions so you can use the built-in more feature.<br>> >9. CSS is your friend, use it before<br>> >programmatic or theme styling as much as possible.<br>> >10. Look for existing solutions before writing a custom one.<br>> >11. Even if it is not a project requirement,<br>> >building an accessible site is better.<br>> >12. Themes should be built on a standard starter<br>> >theme (Zen, Omega, Fusion, etc.)<br>> >13. Block visibility
addresses should be URL aliases rather than node numbers.<br>> >14. Links, including menus, should use relative URLs.<br>> >15. Given that most sites will be in a<br>> >multi-site set up, contributed modules should<br>> >reside in sites/site-name/modules and files in sites/site-name/files.<br>> ><br>> >Views block names:<br>> > views-name: function-name<br>> >Code block names<br>> > module: function-name<br>> ><br>> >Nancy<br>> >Injustice anywhere is a threat to justice<br>> >everywhere. -- Dr. Martin L. King, Jr.<br>> >--<br>> >[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>> <br><br><br>-- <br>[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br><br> </div> </div> </blockquote></div> </div></body></html>