This group is dedicated to optimizing performance of Drupal with coding standards. As such it deals with particular coding guidelines, sharing knowledge and benchmarks that might be integrated into Coder module.
If you are seeking help on high performance/scalability Drupal sites and how to gain a better performance for them, you might have a look at the High Performance group.
Guidelines
- Each coding standard gets its own Wiki page including
- a one line synopsis in the format XY is faster than YX
- a proper description of how it improves performance
- benchmarks from different platforms and PHP versions
- web links to references and additional resources
- You may
- suggest new optimizations by posting a story
- comment on new optimization proposals with insightful input
- perform benchmarks on your platform(s) for existing and new optimizations
Coder Drupal 8.x Battleplan
(Cross posted from http://drupal.org/node/2099351 because Angie said I could/should. This isn't a core issue, but it's an upgrade to D8 issue. We are talking about tackling automatic code upgrades.)
If the community agrees with the plan. It will be a few weeks or a more before I'm ready to ask people to write upgrades. But before we get there, in general, does this sound like a good plan or not? Please provide feedback on the d.o issue http://drupal.org/node/2099351.
Summary:
Read more
Giving the site administrator the full picture
A module, by definition, adds a feature to a Drupal installation. A well written module often provides administrative touches such as the ability to 'hide' the feature from certain user roles or because of a particular site configuration.
This is all well and good, but a problem can arise for the administrator when testing, if the module supplying the feature fails to supply some kind of visual feedback to indicate when it is in 'feature hiding' mode.
Create cookie naming standards
There are a handful of modules that set extra cookies to accomplish various things outside of the session. Some of them are used only on the client side and the server never needs to see them. Some of them are actually used on the server side. See:
https://wiki.fourkitchens.com/display/PF/Modules+that+break+caching,+and...
Identify and document externally-developed files which should not be changed to conform to Drupal coding standards.
Problem/Motivation
There are externally-developed files, such as misc/jquery.js and module/system/system.tar.inc that should not be updated to meet Drupal coding standards.
Standard needed for what is a "disruptive" patch
<
dl>
There is frustration among new developers about how to make issues and patches that cause a minimum of disruption and a maximum of ease for reviewers/committers.
So we need to make a page explaining this. Suggested outline is on the above comment, and suggested place to put it is either:
http://drupal.org/patch
or
http://drupal.org/patch/review
Clarify scope of PHP coding standards for core (major version) and contrib code
Posted by sun on October 1, 2011 at 8:09pm:
Problem
- Uncertainty about when or how to apply coding standards across Drupal core versions and core vs. contrib code.
Goal
-
Clarify the scope of coding standards with regard to:
- major versions of core
- core vs. contrib code
-
Explicitly specify/state which particular coding standards have been different for earlier versions.
Define basic conventions for converting things to classes
As we move to converting low level system in core to classes, we need to define a convention for doing so.
Please chime in on the discussion at http://drupal.org/node/1239644.
Read more
Recommended Markup Guide for Modules
I'm referencing the Drupal Markup Style Guide g.d.o wiki in the Definitive Guide to Drupal 7 and it hasn't been updated in a couple years so i wanted to give all interested parties, especially HTML5 folk, foreknowledge to update it (or link it to a d.o equivalent?).
Advice is sound and it's the most comprehensive take i've seen from a module developer's perspective, so that's why i'm providing the link: http://groups.drupal.org/node/6355
Read moreNew commit message format
Apparently, Git doesn't like commit messages that start with a pound sign, which leads us to define a new standard format for commit messages.
Read moreCore Conversations on documentation at DrupalCon?
Hey all -
DrupalCon Chicago's Core Conversation proposals need to be in by next Friday. Jennifer (jhodgdon) and I have been pondering whether and what might make a good topic or two to pitch.
Please post with ideas and whether you'd be interested in attending a docs focused session, it'll help us gear our proposal towards something everyone will be interested in!
Thanks!
Read moreContributed Module Code Reviews
Code review of existing contributed modules is frequently cited as a means to improving the quality of existing contributed modules. However, the task of performing a code review falls somewhere between documentation, writing and reviewing patches, reviewing CVS applications, and creating new modules.
This is a proposal to elevate the visibility of module review, and make it easier for newcomers to perform module reviews.
Read morePackage names for contributed modules (Drupal 7)
Modules are grouped on the module administration page (admin/modules in Drupal 7) by package, which is defined, optionally, in our module's .info file. Package, then, is the most visible way in which modules are categorized. This wiki page documents package names chosen by module maintainers, please edit it!
Read moreShould the docs style guide apply to interface text?
A ping in #drupal-docs earlier has brought to my attention that the Docs style guide only applies to handbook and not explicitly to interface text in Drupal core/contrib.
I'd think it should apply so we get consistent text and grammar formatting Drupal-wide, but didn't want to make such a sweeping declaration without some consensus from the community at large.
Read moreStandards for documenting implementations of theme functions
We don't have a standard doc header for implementations of themeable functions like THEME_process_HOOK and theme_breadcrumb.
my suggestion:
/**
* Implements THEME_process_HOOK().
*/
function garland_process_page(&$variables) {
//.../**
* Implements theme_breadcrumb().
*/
function garland_breadcrumb($variables) {
//...or
/**
* Overrides theme_breadcrumb().
*/
function garland_breadcrumb($variables) {
//...
Standards for documenting theme functions
A new issue: http://drupal.org/node/716496
There is a discussion there about how to standardize the doc header for default theme implementation functions, such as theme_table(). Please respond there if you are interested. Thanks!
Read moreStandards for documenting classes and interfaces
There's a discussion going on about standards for documenting classes and interfaces in the Drupal API -- please comment on the issue (and NOT here) if interested:
http://drupal.org/node/718596
Ban global variable names for temporary tasks
I'd strongly recommend to add a directive in coding standards to ban common (global) variable names for temporary tasks.
This is a very important security issue as it can lead to certain accidental variable overwrites such as:
In context of a $node some code tries to load assigned user object and does $user = user_load($node->nid);
While this feels pretty OK for the first second one single global $user before this line will lead to a user context switch and thus permission takeover.
This is a very common mistake i've seen many times - and which happens too soon...
Concept: Architectural standard
A experimental document on an architectural standard.
Read more
Only variables should be passed by reference
As you know if you've fiddled with PHP's error_reporting setting, Drupal 7 is not yet E_STRICT compliant. E_STRICT compliance is a good idea for forward compatibility (PHP 5.3 and 6.0) and also helpful for servers that already log E_STRICT errors.
Read moreDrupal Code +Test Sprint Beginners Guide
Last updated by greggles on Wed, 2010-03-31 16:06
THIS WIKI PAGE IS A WORK IN PROGRESS
In helping with LA Drupal's D7 Code+Test Sprint event, I noticed there's some easy points that help newbies feel progressive. There are many ways to help at a Code+Test sprint, and here are the ways that helped us in Los Angeles.
- Make sure you have a Drupal.org account, with "Contributor links" turned on in your profile. This will expose a sidebar block linking to areas of interest for contributors. For example: "Patches to review (D7)" is what most people click on to find patches needing review.
