Quantcast
Viewing all articles
Browse latest Browse all 426

Twig and the new theme layer in Drupal 8

Shortcuts:



Regular meetings

We are organizing our effort via several channels:

  • Weekly Google hangout: Thursdays at 11:30AM PT (2:30PM ET, 20:30 CET). We'll post an agenda and talk about progress and next steps.
  • Chat:#drupal-twig on Freenode. Come join the discussion to ask questions. We hold regular office hours here on Thursdays before and after the call.


Essential Resources

Here are some essential resources for helping us with the move to Twig:



Roadmap

Current plan for cleaning up the theme system.

  1. Update core to use two different theme engines, & fallback to PHPTemplate:
  2. Add simple example of Twig to core:
  3. Convert PHPtemplate files to Twig & use Twig as the default:
  4. Must-have's for Drupal 8

  5. Nice-to-have for Drupal 8

  6. Allowed after code freeze (Jul 1)



Issue tags & Documentation

See the following tags for core issues related to Twig and revising Drupal's theme system.



Code sprints

DateSprint
Current and upcoming sprints
June 2nd, 2013CodeSprint UA 2013
July 12-15, 2013NYC Camp
July 18-20, 2013Twin Cities Drupal Camp
Past sprintsDocs
Nov 24-25, 2012DrupalCamp North WestSummary
Nov 16-17, 2012Drupal 8 Code Sprint in Vancouver
Nov 1-4, 2012BADCampSummary
Oct 26-28, 2012DrupalHagen
Sept 29, 2012DrupalCamp London
Sept 8-9, 2012Drupal Night, Ukraine
Aug 20-24, 2012DrupalCon MunichSummaryResources
July 21-22, 2012NYC CampSummary
May 20, 2012Twin Cities Drupal CampSummaryResources
April 20-22, 2012Chapter ThreeSummaryResources
Feb 9th, 2013DrupalCon Sydney
Jan 26th, 2013SandCamp
March 9th & 10th, 2013Drupal Sprint Weekend
Mar 22nd, 2013Twig Sprint (online)
Apr 19th, 2013Twig Sprint (online)
Apr 20th, 2013Twig Sprint (Charlotte, NC)
May 3rd, 2013Twig Sprint (Stanford University, & online)
May 24th, 2013DrupalCon Portland


Principles: Waypoints to guide us

At the BADCamp 2012 theme sprint, we outlined some core principles to guide our work for the D8 theme layer.

Start with nothing
Core default markup should strive for semantic simplicity, with few HTML elements, added only as needed
Build from use cases
Don't assume you know what people want or add features based on "What-if?" Think about the 90% of use cases.
Provide tools
Give front-end experts a way to achieve specific goals; goals that apply to the remaining 10% of use cases. Keep in mind that complex problems may require complex solutions.
Consolidate
"Your markup is not special." Don't make something new. Work toward common theme functions that modules leverage (i.e. a Theme Component Library).
Visibility
You should be able to see what's going on in a template without reading docs. Twig provides a lot of this by virtue of its syntax (it looks like HTML). Form follows function.
Consistency
Do the same things everywhere, follow patterns. Use similar variable names across templates if they represent similar things.
Don't dumb it down
Complexity should be reduced but not obscured. Themers *can* understand template logic and loops. When complexity does happen, use comments to explain why.
Organization should be driven by meaning and semantics over technical convenience
Consider what an element means rather than how it structurally appears. For example: theme_item_list() came about from a developer's perspective: OL and UL markup is nearly structurally the same, so providing a single function with the type argument came about from a code efficiency standpoint. However, from a semantic HTML perspective, we do not use a singular 'list' element with an attribute to indicate whether it is ordered or unordered, we have two different elements. Semantically, OL and UL represent different information. Therefore, we should provide a separate templates for OL and UL, even though they contain nearly identical markup.
Related to this principle (and the principle of Visibility), names and locations of templates should be self-evident. Consider where a newcomer might expect to override markup. Example: Someone looking to override a menu isn't going to look for a item_list template, even if a menu is structurally identical. So we should not simply have a menu use an item list, nor should we simply include an item list from a menu template. Themers want to see markup in templates, not abstraction.


Tell your friends

Send people to this page using this link: http://lb.cm/twig


Shortcuts:

Viewing all articles
Browse latest Browse all 426

Trending Articles