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.
great list, why: 13. Block visibility addresses should be URL aliases rather than node numbers. I've encountered situations where path auto is used, and someone edits a node title, then the url is changed and then the block vanishes....I think node ids don't change as much. Idan On Thu, Sep 20, 2012 at 4:13 PM, Ms. Nancy Wichmann <nan_wich@bellsouth.net>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*: f*unction-name* Code block names m*odule*: f*unction-name*
*Nancy* Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-- [ Drupal support list | http://lists.drupal.org/ ]
On Thu, Sep 20, 2012 at 9:36 AM, Idan Arbel wrote:
great list,
why:
13. Block visibility addresses should be URL aliases rather than node numbers.
I've encountered situations where path auto is used, and someone edits a node title, then the url is changed and then the block vanishes....I think node ids don't change as much.
It is more SEO eccentric. I don't allow title changes when using pathauto. -- Earnie -- https://sites.google.com/site/earnieboyd
The other option to not have an issue with SEO is to save all paths but redirect. It is a 301 so it is fine. On Sep 20, 2012 7:13 AM, "Ms. Nancy Wichmann" <nan_wich@bellsouth.net> 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*: f*unction-name* Code block names m*odule*: f*unction-name*
*Nancy* Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-- [ Drupal support list | http://lists.drupal.org/ ]
It is not too obvious. We run into it all the time! On Thu, Sep 20, 2012 at 9:01 AM, steeph <ml@mixblog23.de> wrote:
What about the #1 rule: Don't hack core.
Or is it too obvious to include it? ;) -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
Unfortunately hacking core, in particular .htaccess, is not optional on some servers. On Thu, Sep 20, 2012 at 11:02 AM, Steve Kessler <skessler@denverdataman.com>wrote:
It is not too obvious. We run into it all the time!
On Thu, Sep 20, 2012 at 9:01 AM, steeph <ml@mixblog23.de> wrote:
What about the #1 rule: Don't hack core.
Or is it too obvious to include it? ;) -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ]
Changing . htaccess is required in many cases. That is not hacking core. I like to comment out core when editing . htaccess and then add my changes with a comment about what they are for. -Steve On Thu, Sep 20, 2012 at 9:29 AM, Franz Iberl <f.iberl@amazonas-box.de>wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional on some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
I'm not a fan of this list, and if someone tried to push that on me here I'd be visibly upset. Some of the bullet points are good, maybe even great but: 2. No PHP nodes. 3. No PHP blocks. (A sample block module is available.) If I want to use PHP to insert a value into a link, I will, and see no problem with that. This is left up to the developer, not all PHP code needs to be in a module. PHP filter is part of core. When used responsibly there is no reason to not use it if it fits budget/time/needs. 4. Minimize PHP in Views. Depending on the scope of the project, this can't always be enforced. Sometimes it's a lost more efficient to shove a little bit of PHP in a view than to have to recreate the view (and lose its support) from scratch in a module. 6. Use Features for content types and views; and for other things that lend themselves thereto. Commit these to Git repository. I don't understand the love for features. It only supports "some" important modules, and needs a host of other modules (UUID, strongarm) before it starts to become actually useful. Bloat, bloat, bloat. 9. CSS is your friend, use it before programmatic or theme styling as much as possible. No one is going to not tell me to not use the theme system. If I need to rearrange elements or make theme level changes, I will do so, and will not be told otherwise. 14. Links, including menus, should use relative URLs. This makes no sense. All menu links in drupal are absolute (they start at the domain root). It's a guideline where I work to never use relative URLs for files because they are not easily moved to new locations. But I knew I wouldn't like this list as soon as I saw the word "commandments". These guidelines sound like a lot of personal preference, and not a lot of realistic "in the fox hole" programming. Thanks, Patrick Avella On Thu, Sep 20, 2012 at 11:35 AM, Steve Kessler <skessler@denverdataman.com> wrote:
Changing . htaccess is required in many cases. That is not hacking core.
I like to comment out core when editing . htaccess and then add my changes with a comment about what they are for.
-Steve
On Thu, Sep 20, 2012 at 9:29 AM, Franz Iberl <f.iberl@amazonas-box.de> wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional on some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ]
I would agree with Patrick overall. This is a good blog post for someone but not *commandments* for the communities. I was going to let someone else say this but it is also based somewhat on opinion. There are best practices and coding guidelines but not commandments. On Thu, Sep 20, 2012 at 10:00 AM, Patrick Avella <me@patrickavella.com>wrote:
I'm not a fan of this list, and if someone tried to push that on me here I'd be visibly upset. Some of the bullet points are good, maybe even great but:
2. No PHP nodes. 3. No PHP blocks. (A sample block module is available.) If I want to use PHP to insert a value into a link, I will, and see no problem with that. This is left up to the developer, not all PHP code needs to be in a module. PHP filter is part of core. When used responsibly there is no reason to not use it if it fits budget/time/needs.
4. Minimize PHP in Views. Depending on the scope of the project, this can't always be enforced. Sometimes it's a lost more efficient to shove a little bit of PHP in a view than to have to recreate the view (and lose its support) from scratch in a module.
6. Use Features for content types and views; and for other things that lend themselves thereto. Commit these to Git repository. I don't understand the love for features. It only supports "some" important modules, and needs a host of other modules (UUID, strongarm) before it starts to become actually useful. Bloat, bloat, bloat.
9. CSS is your friend, use it before programmatic or theme styling as much as possible. No one is going to not tell me to not use the theme system. If I need to rearrange elements or make theme level changes, I will do so, and will not be told otherwise.
14. Links, including menus, should use relative URLs. This makes no sense. All menu links in drupal are absolute (they start at the domain root). It's a guideline where I work to never use relative URLs for files because they are not easily moved to new locations.
But I knew I wouldn't like this list as soon as I saw the word "commandments". These guidelines sound like a lot of personal preference, and not a lot of realistic "in the fox hole" programming.
Thanks, Patrick Avella
On Thu, Sep 20, 2012 at 11:35 AM, Steve Kessler <skessler@denverdataman.com> wrote:
Changing . htaccess is required in many cases. That is not hacking core.
I like to comment out core when editing . htaccess and then add my changes with a comment about what they are for.
-Steve
On Thu, Sep 20, 2012 at 9:29 AM, Franz Iberl <f.iberl@amazonas-box.de> wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional
on
some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
I think what it really boils down to, is that there are good developers, and lousy developers. No amount of guidelines, style guides, conferences, or annual reviews is ever going to "fix" a bad programmer. A good programmer has their own unique development style and can both understand and replicate another programmer's unique development style (in this case, drupal coding standards for example). A bad programmer just makes spaghetti out of everything no matter how much hand holding you do, and these are the people that need to be shifted out to less technical support type positions (AND NOT ELEVATED to management). Thanks, Patrick On Thu, Sep 20, 2012 at 12:18 PM, Steve Kessler <skessler@denverdataman.com> wrote:
I would agree with Patrick overall. This is a good blog post for someone but not *commandments* for the communities.
I was going to let someone else say this but it is also based somewhat on opinion. There are best practices and coding guidelines but not commandments.
On Thu, Sep 20, 2012 at 10:00 AM, Patrick Avella <me@patrickavella.com> wrote:
I'm not a fan of this list, and if someone tried to push that on me here I'd be visibly upset. Some of the bullet points are good, maybe even great but:
2. No PHP nodes. 3. No PHP blocks. (A sample block module is available.) If I want to use PHP to insert a value into a link, I will, and see no problem with that. This is left up to the developer, not all PHP code needs to be in a module. PHP filter is part of core. When used responsibly there is no reason to not use it if it fits budget/time/needs.
4. Minimize PHP in Views. Depending on the scope of the project, this can't always be enforced. Sometimes it's a lost more efficient to shove a little bit of PHP in a view than to have to recreate the view (and lose its support) from scratch in a module.
6. Use Features for content types and views; and for other things that lend themselves thereto. Commit these to Git repository. I don't understand the love for features. It only supports "some" important modules, and needs a host of other modules (UUID, strongarm) before it starts to become actually useful. Bloat, bloat, bloat.
9. CSS is your friend, use it before programmatic or theme styling as much as possible. No one is going to not tell me to not use the theme system. If I need to rearrange elements or make theme level changes, I will do so, and will not be told otherwise.
14. Links, including menus, should use relative URLs. This makes no sense. All menu links in drupal are absolute (they start at the domain root). It's a guideline where I work to never use relative URLs for files because they are not easily moved to new locations.
But I knew I wouldn't like this list as soon as I saw the word "commandments". These guidelines sound like a lot of personal preference, and not a lot of realistic "in the fox hole" programming.
Thanks, Patrick Avella
On Thu, Sep 20, 2012 at 11:35 AM, Steve Kessler <skessler@denverdataman.com> wrote:
Changing . htaccess is required in many cases. That is not hacking core.
I like to comment out core when editing . htaccess and then add my changes with a comment about what they are for.
-Steve
On Thu, Sep 20, 2012 at 9:29 AM, Franz Iberl <f.iberl@amazonas-box.de> wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional on some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ]
On Thu, 20 Sep 2012, Patrick Avella wrote:
To: support@drupal.org From: Patrick Avella <me@patrickavella.com> Subject: Re: [support] Ten Commandments
I think what it really boils down to, is that there are good developers, and lousy developers. No amount of guidelines, style guides, conferences, or annual reviews is ever going to "fix" a bad programmer.
A good programmer has their own unique development style and can both understand and replicate another programmer's unique development style (in this case, drupal coding standards for example).
A bad programmer just makes spaghetti out of everything no matter how much hand holding you do, and these are the people that need to be shifted out to less technical support type positions (AND NOT ELEVATED to management).
That's what put me off some early examples of C coding, years ago. The whole program was 1 large function, with multiple nested functions, no indenting or comments - yuk! The thinking seemed to be - if you can write a C program that works an is unreadable then you are a cool C programmer! Keith ----------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------
Calling them the "Ten Commandments" was a bit of a joke because I am starting on the road to ministry. The only one that might really be a commandment is "Thou shalt not hack core." And if I have a really serious need for that, I will discuss it with the team and get their blessing before proceeding - and I will also submit a patch to core (same with contribs). However, given that the vast majority of our sites live in multisite environments, hacking core is close to impossible. Otherwise, these are guidelines, not hard and fast rules, and the official title of the document reflects that. Yes, there are cases where, for example, a bit of PHP in Views is not only expedient, but the only way to go. What we want is for these cases to be discussed - and documented - when they arise. "PHP filter is part of core" - true, but if you used Drupal before 6, perhaps you noticed a change. It is now optional where it used to be standard. This is because so many security holes were exposed by using PHP. When I started out (4.7.8 I think), another helpful Drupaller hacked my site just to show me how easy that was. After that I learned how to write modules, where PHP belongs. Modifying theme functions is awfully close to modifying contribs. Updates may wipe them out without warning. Modifying SUB-theme functions is slightly better. But of all the sites I have built, I find it uncommon that I need to do this. CCK's (and now core) "manage display" is great and often avoids the need to do much of that. And hook_preprocess_HOOK is another great boon to avoiding such mods. We have upwards of seven Drupal developers working on several projects. If each follows their own style, then it gets harder for someone else to work on it later. Following the style to which core and contribs are held just makes life easier for everyone. As a contrib developer myself, I now find it impossible to not follow those standards. I even install Coder on my development sites to make sure I didn't inadvertently miss something (and rarely do). Call me anal if you want, but few people who know me will agree with you. As I said elsewhere, I agree, this is not going to make a bad developer good, but it helps find reasons to get rid of them. I am equally convinced that some guidelines, like these, help good developers be better. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: Patrick Avella I think what it really boils down to, is that there are good developers, and lousy developers. No amount of guidelines, style guides, conferences, or annual reviews is ever going to "fix" a bad programmer.
A good programmer has their own unique development style and can both understand and replicate another programmer's unique development style (in this case, drupal coding standards for example).
A bad programmer just makes spaghetti out of everything no matter how much hand holding you do, and these are the people that need to be shifted out to less technical support type positions (AND NOT ELEVATED to management).
I would say these brief bulleted points could serve as the basis for a very interesting discussion not as the end all and be all. I wonder why people seem to be so very touchy / take offense without getting into a discussion of the ramifications of these very general guidelines. They are very helpful to me as an intermediate drupalero. Tony On Thu, Sep 20, 2012 at 9:18 AM, Steve Kessler <skessler@denverdataman.com>wrote:
I would agree with Patrick overall. This is a good blog post for someone but not *commandments* for the communities.
I was going to let someone else say this but it is also based somewhat on opinion. There are best practices and coding guidelines but not commandments.
On Thu, Sep 20, 2012 at 10:00 AM, Patrick Avella <me@patrickavella.com>wrote:
I'm not a fan of this list, and if someone tried to push that on me here I'd be visibly upset. Some of the bullet points are good, maybe even great but:
2. No PHP nodes. 3. No PHP blocks. (A sample block module is available.) If I want to use PHP to insert a value into a link, I will, and see no problem with that. This is left up to the developer, not all PHP code needs to be in a module. PHP filter is part of core. When used responsibly there is no reason to not use it if it fits budget/time/needs.
4. Minimize PHP in Views. Depending on the scope of the project, this can't always be enforced. Sometimes it's a lost more efficient to shove a little bit of PHP in a view than to have to recreate the view (and lose its support) from scratch in a module.
6. Use Features for content types and views; and for other things that lend themselves thereto. Commit these to Git repository. I don't understand the love for features. It only supports "some" important modules, and needs a host of other modules (UUID, strongarm) before it starts to become actually useful. Bloat, bloat, bloat.
9. CSS is your friend, use it before programmatic or theme styling as much as possible. No one is going to not tell me to not use the theme system. If I need to rearrange elements or make theme level changes, I will do so, and will not be told otherwise.
14. Links, including menus, should use relative URLs. This makes no sense. All menu links in drupal are absolute (they start at the domain root). It's a guideline where I work to never use relative URLs for files because they are not easily moved to new locations.
But I knew I wouldn't like this list as soon as I saw the word "commandments". These guidelines sound like a lot of personal preference, and not a lot of realistic "in the fox hole" programming.
Thanks, Patrick Avella
On Thu, Sep 20, 2012 at 11:35 AM, Steve Kessler <skessler@denverdataman.com> wrote:
Changing . htaccess is required in many cases. That is not hacking core.
I like to comment out core when editing . htaccess and then add my changes with a comment about what they are for.
-Steve
On Thu, Sep 20, 2012 at 9:29 AM, Franz Iberl <f.iberl@amazonas-box.de> wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional
on
some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
-- Steve Kessler Owner and Lead Consultant Denver DataMan, LLC 303-587-4428
-- [ Drupal support list | http://lists.drupal.org/ ]
-- *Anthony Stefan Maciejowski*
Add to that: robots.txt .gitignore Also removing CHANGELOG.txt is a good idea as that can give people the actual version you are running. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 9/20/2012 11:29 AM, Franz Iberl wrote:
Am 20.09.12 17:17, schrieb Walt Daniels:
Unfortunately hacking core, in particular .htaccess, is not optional on some servers.
Adapting .htaccess I do not consider as hacking core.
Servus Franz
I would actually generalize it to: Don't hack core or contributed modules/themes.... it causes all kinds of upgrade problems. -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of steeph Sent: Thursday, September 20, 2012 8:01 AM To: support@drupal.org Subject: Re: [support] Ten Commandments What about the #1 rule: Don't hack core. Or is it too obvious to include it? ;) -- [ Drupal support list | http://lists.drupal.org/ ]
Well, steeph, you're right. It was too obvious to me, but, yes, it should be stated. We even discourage hacking contribs. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: steeph What about the #1 rule: Don't hack core.
Or is it too obvious to include it? ;)
Hi, it should not be, Don't hack contrib, as I feed we are not at this level, so instead it should be, Avoid hacking contrib, but if you need to, contribute the changes back. Gordon. On 21/09/2012, at 11:07 AM, "Ms. Nancy Wichmann" <nan_wich@bellsouth.net> wrote:
Well, steeph, you're right. It was too obvious to me, but, yes, it should be stated. We even discourage hacking contribs.
Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
From: steeph What about the #1 rule: Don't hack core.
Or is it too obvious to include it? ;) -- [ Drupal support list | http://lists.drupal.org/ ]
Gordon Heydon <gordon@heydon.com.au> mobile: 0424 755 506 (+61 424 755 506) web: http://heydon.com.au
Thank you for number 11 and the rest of them are good too. -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Ms. Nancy Wichmann Sent: Thursday, September 20, 2012 8:14 AM To: support drupal Subject: [support] Ten Commandments 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.
participants (14)
-
Anthony -
Earnie Boyd -
Franz Iberl -
Gordon Heydon -
Idan Arbel -
Jamie Holly -
Jim Ruby -
Keith Roberts -
Metzler, David -
Ms. Nancy Wichmann -
Patrick Avella -
steeph -
Steve Kessler -
Walt Daniels