Planet Drupal

This is a follow up of earlier blog post How import / export quiz questions to Drupal. As mentioned earlier Quiz questions import (qq_import) module is the one of the potential modules to import quiz question into Drupal from external sources. The Drupal 7 version of the same has been just released and this version includes a major architectural change from the previous release i.e. we have developed to take the advantage of Feeds module.

Google Plus One Linkedin Share Button Tweet Widget Facebook Like

We've been having a lot of fun with maps recently. From the challenges of dealing with 100,000 markers (see this DrupalCon Portland mapping session) down to smaller maps that attractively reveal the nature of their data locations through animated clustering and beautiful marker images in colours that reflect location type, such as the kind of shop (hairdresser, camera store etc) or the price range of rental accommodation.

For the map maker who is not a pro at Photoshop or similar tool, the bane of a marker image is that its attributes (shape, colour, resolution, #kBytes) are all wrapped up in this one atomic unit: the .png file. When assembling markers for various types of locations you can't easily combine "this" marker image in "that" colour with "this" cute symbol in the middle, in "that" size… And then have all that repeated automatically on the fly by your map, as more locations are added to your site.

But with scalable alternatives spreading rapidly, most notably WOFF, and repositories like Font Awesome and fsymbols featuring more and more cute icons, we are now striding closer to an easier solution.
Drawing form these repositories IP Geolocation Views & Maps let's you superimpose any scalable icon on top of any of your traditional marker images, giving you a smorgasbord of combinations.

To contrast the font "awesomeness" of the icons versus trad .png we've included a couple of screenshots. The first, a highly zoomed-in map with markers, reveals how both map tiles and marker images have become pixelated during enlargement, while the font icons have not. In the second the font-size of those two special font icons was increased dramatically (and their colours changed to black). Notice the sharpness of these characters, 'cause that's what these are, characters, at any magnification or zoom level? Luvly.

And how much do you have to pay the ferryman, to get those snazzy icons from your server to the other side?
How much? The price in bandwidth is: one. One UTF character. Not a 10k image or even a 1k image. One single UTF character per icon. That's, well… nothing.

Having said that, unlike the fsymbols set, the Font Awesome icons do come with a CSS file for easy icon customisation as well as a WOFF file (or if not supported a TTF or SVG fallback), automatically loaded by your browser. This does constitute a one-off hit of 55kB or so. But that sets you up for as many font icons as you wish, at no further cost in bandwidth.

Thus you can pick & mix marker images and font icons to your heart's content and assemble CSS-stylable, scalable, super-sharp markers to create beautiful maps for your clients. All through an easy UI. No Photoshop in sight.

So for your next map, give IP Geolocation Views & Maps a go and let us know what you think. Available in 7.x-1.x-dev and the upcoming 7.x-1.21 versions.

File under:  Planet Drupal

Another DrupalCon down. More memories, more connections, and a little more Drupal knowledge. Here’s Dave’s take on DrupalCon Portland 2013.

Company

pre { font-size: 15px; } .node aside { font-style: italic; margin-bottom: 1.5em; } /*-->*/ /*-->*/

Pantheon is a great company with great product. They make hosting Drupal sites easy, and you can try out their service for free. I've enjoyed watching their company grow, and they make great contributions to Drupal overall.    Commerce Guys is a great company with a great product. We make getting started selling online with Drupal a breeze, and I've had a blast being part of the products team responsible for Commerce Kickstart.   Yesterday was a happy day for me because Commerce Kickstart is now available on Pantheon. Great + Great = Even Greater, so if you want to try Commerce Kickstart directly on a premiere hosting service, it's never been easier to do so. Go ahead and try it out!     Tags: Drupal PlanetCommerce Guys

Topic: Drupal

Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.

From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.

One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.

We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.

While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:

• WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
• Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.

For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.

Drupal 8 will ship with big authoring experience improvements: WYSIWYG editing & in-place editing, thanks to the Spark distribution that Acquia — my employer — is sponsoring.

But how well does it fare with the growing importance of structured content? Do Drupal 8’s WYSIWYG & in-place editing enable it or prevent it?

The new web world order: many form factors

The Big Thing of the last few years: the advent of mobile. Inherent to that: websites that are optimized for mobile devices and act as data providers for apps.

A new form factor — mobile devices — changed web development forever. Before mobile, the life of web developers and authors (content creators) was relatively simple: make sure websites work well on a few typical screen sizes (let’s deny the existence of Internet Explorer 6 and all the misery it caused).

But … we cannot predict what’s next. We cannot predict new content consumption form factors. That’s where content strategy becomes vitally important:

content strategy is to copywriting as information architecture is to design

We have to make sure that our content is structured and has enough metadata to successfully reuse the same (structured) content for different content consumption form factors. Without having to edit each piece of content again.

Structured content: successfully dealing with form factors

NPR’s Create Once, Publish Everywhere is the most often cited example of a content strategy that successfully provides content for many form factors. They create content once, then publish it to >10 different platforms. With a small team, they do more than some other companies, because of their excellent content strategy. It took them years to evolve their systems in this direction, and it paid off.

Another example is TV Guide. They decided back in the 1980s to capture all semantic metadata, to build a database and extracting a magazine from that, rather than just creating a nicely formatted magazine every time. Thanks to that, they’re still relevant today.

It appears that the reuse of content is something every website should strive towards. There’s nothing inherently bad about it. However, there are downsides.

TV Guide editors used a mainframe application (and maybe still do?). NPR editors use this UI:

NPR editors are encouraged to only think about content, not presentation — hence a very basic data entry UI is all they get 1. This UI looks more like a web front-end to a database than a CMS (anybody else who’s reminded of PHPMyAdmin?)…

So, while this may be true:

The goal of any CMS should be to gather enough information to present the content on any platform, in any presentation, at any time.

No CMS really aims to have a poor authoring experience, of course.

Drupal & structured content

Drupal is already well prepared for structured content.

All of the principles that are being used when reviewing code that is being proposed for Drupal core inclusion, are a superset of the principles applied to structured content. Drupal demands full separation of concerns at every level. Everything must be overridable/alterable. Separation of concerns for CSS files, to ensure clean overriding of styling without having to duplicate all CSS. Content may never contain CSS nor depend on CSS. And so on.

Five features in particular stand out with regards to structured content and content reuse:

1. Structured content: Field API.
   It allows content to be modeled as granularly as desired.
2. Clean content: Filter system.
   Ensures fancy mark-up is only added on output, and the stored content is as clean as possible. e.g. the fancy typographic features in this very piece of text is automatically added by Typogrify.
3. Different presentations of the same content: view modes.
   A view mode defines the order of the fields and the field formatter & label of each field. 2
4. Internal reuse of content (within the website): Views module.
   To create lists, grids, tables, galleries etc. of content, while showing related content. A listing can be configured to use a specific view mode.
5. External reuse of content (outside the website): REST module.
   To provide JSON, XML, HAL, JSON-LD, YourCustomMarkupLanguage output.

Drupal authoring experience

Drupal’s authoring experience used to be remarkably similar to that of NPR’s COPE. We’ve gone through a lot of effort in Drupal 6, 7 and 8 to improve usability in general. In Drupal 8, the Spark distribution on which I work has specifically targeted the improving of the authoring experience.

Some of the authoring experience improvements in Drupal 8 (in part) thanks to Spark:

1. two-column backend content editing (with publishing options/meta configuration in a sidebar)
2. in-place editing for fields
3. CKEditor-powered WYSIWYG editing

The first is noncontroversial when looking at it from a structured content perspective. It’s the second and third that appear to be counter to the premise of structured content — to quote Karen McGrane about WYSIWYG editing:

[…] we allow content creators to embed layout and styling information directly into their content. Unfortunately, the code added by content creators can be at odds with the style sheet, and it’s difficult for developers to parse what’s style and what’s substance. When it comes time to put that content on other platforms, we wind up with a muddled mess.

or Jeff Eaton about in-place editing:

The editing interfaces we offer to users send them important messages, whether we intend it or not. They are affordances, like knobs on doors and buttons on telephones. If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”

First, let me state that I in fact do not disagree with either of them. We’ve actually taken that into account while adding WYSIWYG editing and in-place editing to Drupal core. Let me explain how.

WYSIWYG in Drupal 8: enforces clean markup

By default (in the Standard install profile), Drupal 8 will not ship with formatting/layout tools enabled in its WYSIWYG editor (CKEditor).

We make sure in Drupal 8 to prevent crappy markup and format/layout markup (style, font attributes). It’s not only impossible to set these kinds of “bad attributes” in the WYSIWYG editor using the toolbar, it’s also impossible to paste them in and to use the “source mode” (where you can type HTML directly) to insert them — you can type them in the latter case, but they will be stripped upon going back to WYSIWYG mode from source mode, or upon save if you try to save it without going back to WYSIWYG mode.
This is powered by the new “Advanced Content Filter” feature in CKEditor 4.1, which was added specifically on our request to make this possible.

Furthermore, we made it very easy to configure CKEditor in Drupal 8, yet at the same time very hard to break the above strictness. Only HTML tags and attributes allowed by a specific CKEditor toolbar button will be allowed, even if you add more buttons. So the above “guaranteed clean HTML” will not only be true for the default WYSIWYG configuration, but for any configuration. Drupal 8 will even automatically sync WYSIWYG configuration with filter system configuration:

In the past, configuring WYSIWYG editors was a pain, and in part because of that, the configuration of the WYSIWYG editor and corresponding filter system settings were too permissive.

Finally, we’re currently working on making sure that when you insert an image into a piece of text (with or without a WYSIWYG editor), that won’t result in the final HTML like <img src="/files/styles/thumbnail/llama.jpg" width="100" height="100" alt="Awesome llama!" />, but instead in a placeholder that the filter system will transform into the final HTML upon output: <img data-file-uuid="aa657593-0da9-42c0-9a05-5d63d27ad27d" data-image-style="thumbnail" />.
In other words: the text should only contain text and programmatic references to other content; the filter system should then handle “upcasting” these into their final form. This will make it much, much easier to upgrade existing content to new image styles, to modify referenced media, to migrate to a new CDN, and whatnot.

WYSIWYG in Drupal 8: from brochureware to newspapers

Drupal needs to cater to both the extreme of very structured content for maximal reuse and to the extreme of unstructured content (where pretty much all data is in a single “blob” called the “body” field, besides maybe a “title” and a “tags” field). It also needs to deal with everything in between.

Drupal may be used for news sites, but also for brochureware sites. By having the WYSIWYG editor be configurable, and hence letting the site builder choose whether formatting/layout tools are available or not, we empower the user to choose.

WYSIWYG in Drupal 8: previews are evil? WYSIWYM to the rescue?

A WYSIWYG editor by definition provides a preview — a best effort preview, that is not guaranteed to be accurate. Providing a preview is not a problem in and of itself, as long as the author knows and understands that the content will be used in multiple contexts, where it will look different.

Of course, reality is that not every author will be sufficiently educated, so we have to take potential abuse into account. Drupal’s filter system and very strict WYSIWYG editing in Drupal 8 do precisely that.
What might be even better though, is if we were to make it explicitly visually obvious that the WYSIWYG editor is indeed providing a best-effort preview: visualize the building blocks of the content that the author is using, to make him very aware of the structure of the content that he’s creating.

This is what is some people have called WYSIWYM: “What You See Is What You Mean”. 3 Wikipedia defines it as follows:

WYSIWYM (an acronym for “what you see is what you mean”) is a paradigm for editing a structured document. It is an adjunct to the better-known WYSIWYG (what you see is what you get) paradigm, which displays a formatted document on screen as it will appear in only one mode of presentation.

The main advantage of this system is the total separation of presentation and content: users can structure and write the document once, rather than repeatedly altering it for each mode of presentation, which is left to the export system.

A HTML text editor specifically built for to be a WYSIWYM HTML editor exists: WYMeditor.

WYMeditor’s main concept is to leave details of the document’s visual layout, and to concentrate on its structure and meaning, while trying to give the user as much comfort as possible (at least as WYSIWYG editors).

• You may have tried a full-featured WYSIWYG editor, but you apprehend that your clients use it inappropriately, with the risk it degenerates visually and on the code quality.
• You may also have tried the BBcode syntax, Markdown or the wiki-style syntax, but you don’t want to force your clients to solutions that are too technical/complex for them, even if it tends to generate good quality code.

The downside of WYMeditor (besides its utilitarian UI and absence of keyboard accessibility) is that it doesn’t support the whole range of websites that Drupal needs to support: some people want to do everything in a WYSIWYG editor, and for the simplest websites, that’s acceptable. Drupal tries to impose as few choices as possible.

So, ideally, we’d use CKEditor, with a way to turn on a “WYSIWYM mode”. The great news: this already exists to a certain extent in the form of its “Show Blocks” plugin! (Which we’re already shipping with Drupal core specifically to accomodate this.)

If we find this an acceptable solution, then all we need to do is improve CKEditor’s “Show Blocks” plugin!

Of course, this line of reasoning might come across as a superficial solution that isn’t a real solution. But let me demonstrate that the core a this pattern has been used for almost 20 years: in the LaTeX world.

WYSIWYM & LaTeX: LyX

I’m sure many of you know LaTeX. It’s a “document markup language and document preparation system”. It’s typically used for writing papers, but also books. 4

LaTeX is based on the philosophy that authors should be able to focus on the content of what they are writing without being distracted by its visual presentation. In preparing a LaTeX document, the author specifies the logical structure using familiar concepts such as chapter, section, table, figure, etc., and lets the LaTeX system worry about the presentation of these structures. It therefore encourages the separation of layout from content while still allowing manual typesetting adjustments where needed.

That really captures the gist of it: authors focus on content, don’t think about visual presentation. That’s up to “the system” to figure out. Now, here too, it is the domain markup, and complete knowledge of it, that is problematic: the plethora of LaTex commands.

That’s why tools like LyX exist. LyX is essentially an easier to use interface to generate LaTeX. It shields the user (mostly) from the rather complex LaTeX markup. It provides a preview of sorts, but one that clearly looks completely different from the end result that LaTeX’s typesetting will generate: LyX encourages writing based on structure (WYSIWYM) rather than appearance (WYSIWYG).

If all of the above sounded rather abstract, let’s look at an example:

• Writing LaTeX: here’s a tiny subset of the LaTeX code — see the attached file for more:
  In inline formulas it looks like this: \begin_inset Formula $\lim_{x\rightarrow\infty}f(x)$ \end_inset
• Writing LaTeX in Lyx:
  
• The output for both:
  

LyX’ initial release was in 1995. It’s still actively being used. Many, many papers have been written it as well as many books.

But … WYSIWYG editors suck!

Sure, WYSIWYG editors sucked… because they allowed for formatting & layout, which Drupal 8’s WYSIWYG editing doesn’t allow.

We still have work to do to stress the importance of content structure over content presentation — see the WYSIWYM section above. But that can be bolted on top of the solid foundations that we already have.

So, these wonderfully colorful quotes used to be painfully true, but they’re not applicable to Drupal 8’s WYSIWYG:

WYSIWYG Editors suck because they promote thinking about style rather than content. While content editors are busy changing headings to Comic Sans, pondering the use of a grimacing smiley on their about us page or getting creative with colour, they are not considering the actual copy they are adding to the site.

WYSIWYG Editors suck because as a designer you lose control over big chunks of the design. Anywhere that allows people to enter HTML via an editor allows them to get as creative as they like, using any mark-up that they like. Unless you carefully go through and remove all the creativity that stuff is going to stay there. For developers, even if you switch off most of the buttons, just allowing the administrator to enter simple formatting and links, you still have a situation where a user is entering HTML which you then display on the website. This can enable all kinds of stuff to get into your content, which is then very hard to remove and fundamentally tied to the current design of the site.

In-place editing

In-place editing does not inherently conflict with structured content. In fact, for most things, Drupal’s implementation of in-place editing stresses the fact that the content is structured: most structured data is impossible to edit in the same way as it is presented. Only for textual fields, we offer the überfancy “true WYSIWYG in-place editing” capability, where Jeff Eaton’s quote from above is most relevant. Even there though, abuse is prevented by the very restrictively configured WYSIWYG editor. For other fields, like taxonomy terms, image fields, boolean fields and so on, we still offer a form-based editing UI while editing in-place, and the danger of letting content presentation prevail is extremely limited.

To a degree, in-place editing can even be useful in increasing awareness of the need for structured content. If the content isn’t structured (i.e. one blob of data, for example a “body” field containing all content besides the title), then that becomes immediately and painfully obvious: no specialized, optimized in-place editors appear to edit the particular piece of content; instead you’d have to find your way to the particular thing you want to edit in the body field.
In-place editing in the way we’ve implemented it encourages structured content.

In our initial implementation of in-place editing, there was more potential for misunderstanding and abuse. But we’ve made two important changes:

1. in-place editing is no longer triggered on the page level, but at the entity level: the user must declare his intent to edit a specific entity in-place. So the user can no longer get the impression he’s “editing the page”: he’s explicitly made aware of the type of content (entity type) he’s editing (node, taxonomy term, custom block …) and of the field within that piece of content (entity) that he’s currently editing (Title, Author, Body, Tag, Image …).
   
2. in-place editing is no longer saving each field individually, instead the modified fields for a specific entity are queued up and saved at once, this strengthens the communication to the user that he’s editing a singular piece of content that just happens to be rendered on this particular page. (In progress.)

Finally, in-place editing is only designed to be used for quick edits (hence it being triggered by a “Quick edit” action in the contextual links of entities). It’s intended to bring a level of “delightful interaction” to editing, instead of being forced to go back to the overwhelming back-end form every single time, even if you don’t need to modify metadata.

Education, understanding, awareness of content reuse

It is absolutely essential that authors (content creators) understand the entire flow of the content: from creating it first, using each field for its proper purpose, to the different ways that content might end up in output.

Because in-place editing happens on the output, and output can happen in many ways, in-place editing never allows all the content to be edited: at the very least it is going to be impossible to edit metadata. From that last perspective, it’s definitely possible for an author to abuse in-place editing.

We need to provide omnipresent, explicit awareness whenever an author is creating or editing content. Both when editing on the back-end and on the front-end. Low-fidelity, simultaneous previews of the different view modes and preferably on multiple form factors would be the ideal here.

Embedding this explicit awareness is something we still have to achieve for Drupal.5

Data storage in NPR’s COPE

We saw NPR’s UI earlier in this article. What we didn’t see yet, are two fundamentally different ways of storing the data within what is presented as a single field to the end user:

1. Each paragraph of a single text field is stored as a distinct database record. This also implies that the position of the paragraph needs to be stored. (See the full diagram for details.)
2. When saving a paragraph, all HTML markup it contains is stored independently: it stores just the text in one database record, and then there is one database record per HTML tag used within that paragraph, which stores the type of tag, the start and end position of that tag within the text, and the attributes for that tag. They call this Markup Addressing:
   .

In essence: extreme database normalization!

Drupal does not yet support this out of the box. The question is whether this is actually necessary? There’s a lot of additional overhead to going so far in normalizing data. What is the use case for storing individual paragraphs in separate database records, when many paragraphs are meaningless without the surrounding paragraphs?

The use case for storing the markup separately from the text it was applied to is more clear: to easily facilitate those platforms that don’t use HTML markup, and to support changes in markup more easily (e.g. <b> → <strong>). NPR decided against the alternative: storing the markup in the database and filter (strip/transform) it on the way out.
The main gripe Daniel Jacobson had with “filter on output” is based on how he’d seen that implemented before: hard-to-maintain scripts and most systems allowed all markup to be used. However, Drupal already has a mature system to deal with that: its filter system.

Both architectures have downsides. Neither is clearly superior6. Time will tell whether Drupal’s data storage approach needs to evolve.

Conclusion

WYSIWYG and in-place editing can clearly be highly problematic when it’s implemented like it has been for many websites for about a decade now. For many websites, they have been (ab)used to the extreme point of entire HTML pages being built by a WYSIWYG editor, which has caused consistent inconsistency and utter lack of reuse. Liked by authors at first, until things went bad — or until the next redesign.

The other extreme is a system like NPR’s COPE, where it is guaranteed that content is consistent and reusable. At the cost of the authoring experience.

However, I believe that using WYSIWYG editing in a very disciplinary manner combined with a well-defined system for filtering on output and a data model similar to NPR’s COPE, can yield equally successful results as NPR’s COPE, but with a significantly better authoring experience.

Sources & related reading

• http://en.wikipedia.org/wiki/Content_strategy
• http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
• http://blog.programmableweb.com/2009/10/21/content-modularity-more-than-just-data-normalization/
• http://blog.programmableweb.com/2009/11/11/content-portability-building-an-api-is-not-enough/
• http://karenmcgrane.com/2013/05/23/drupalcon-keynote-video-and-talk-notes/
• https://www.lullabot.com/blog/articles/inline-editing-and-cost-leaky-abstractions
• http://alistapart.com/column/wysiwtf
• http://www.rachelandrew.co.uk/archives/2011/07/27/your-wysiwyg-editor-sucks/

1. Both examples are content businesses. The efficient managing and reusing of that content is the whole reason they exist and survive. Hence it is acceptable for them to have a very poor authoring experience. Also: the data model has to be right from the beginning; if something was missing or wrong, it may be impossible to transform old content to the updated data model. Hence there is also an intentional lack of flexibility. ↩

2. Use the Entity View Modes module to create new view modes. ↩

3. Not in the sense that it was discussed at the WYSIWYM BoF at DrupalCon Portland, where it was really about semantic annotation. ↩

4. The whole reason it exists is because somebody got fed up with messing with WYSIWYG editors to get everything just right: the typography, the whitespace, the layout, and so on. Instead, that person wanted to just write the content and have software automatically calculate optimal whitespace, optimal typesetting. ↩

5. The Spark team has already been working on this to a certain extend: the responsive previews patch. However, it is not tightly integrated with editing; neither on back-end nor front-end. ↩

6. Ideally, there would a domain-specific markup (as in, a markup with annotations for the specific knowledge domain of your site) that has more expressive semantics and would then be transformed to HTML when the content gets rendered for web purposes, and to something else than HTML for other purposes. We should explore this.
   But at the same time, the threshold would become rather high: which sites, besides those whose primary business is the longevity of their content, the long-term relevance and reusability of their content, will want to invest to build their domain-specific language?
   It requires a lot of discipline and research, to come up with a sufficiently expressive domain-specific markup. Precisely because once you’ve begun expressing content using your domain-specific markup, there is no way back. You cannot automatically enrich existing content with newly added domain-specific markup. The domain-specific markup must be complete before you begin using it.
   Not to mention that either the author will need a complete understanding of the complete domain-specific markup as well, because otherwise it will all have been a measure for nothing. Once you enter this realm, it’s also very realistic (and human) for authors to forget about a few elements of the domain-specific markup. So then something like a WYSIWYG editor, but with buttons that generate the domain-specific markup could be a great help. This is once again WYSIWYM. ↩

• Spark
• Drupal
• WYSIWYG
• usability
• structured content
• Acquia
• LaTeX
• LyX

• AttachmentSize NPR's COPE UI127.48 KB Unidirectional text editor configuration to text format filter settings syncing4.32 MB WYMeditor example33.54 KB CKEditor's "Show Blocks" plugin31.1 KB "Operators with Limits" LaTeX example that matches the screenshots2.58 KB Writing LaTex in LyX131.28 KB LyX/LaTeX output17.78 KB In-place editing of various entities on the page.1.32 MB NPR entity diagram43.16 KB NPR Markup Addressing642.56 KB ( bytes)

In this week's episode, join part of the Lullabot team that worked on launching the new Lullabot.com redesign.

• Drupal.org security announcement
• Learning Sass and Compass series
• DrupalCon session videos on YouTube
• DrupalCon Prague
• DrupalCon Austin
• ConFab conference
• DrupalCamp Austin
• DrupalCamp Colorado
• Drupal Dev Days in Dublin

Lessons learned from building the new Lullabot.com site

You will need to modify your .htaccess file located under your web root.

Change ..

# To redirect all users to access the site WITH the 'www.' prefix, # (http://example.com/... will be redirected to http://www.example.com/...) # uncomment the following: # RewriteCond %{HTTP_HOST} . # RewriteCond %{HTTP_HOST} !^www\. [NC] # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

to ..

# To redirect all users to access the site WITH the 'www.' prefix, # (http://example.com/... will be redirected to http://www.example.com/...) # uncomment the following: RewriteCond %{HTTP_HOST} . RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Tags: apacheseocanonicaldrupalplanet Tweet

One week ago today, DrupalCon Portland concluded.

While the weather didn't completely cooperate (it's still cloudy, cold, & misting BTW), the overall atmosphere was polite, the keynotes were interesting, the sessions were varied and the attendance was record setting. I feel like I learned a ton.

Here's a short list of some of my favorite sessions:

Anthony Ferara's session on code complexity was instructive, delightful and inspiring. I spoke with another dev about it and we both started geeking out on the tools he was using. Phploc in particular was something I could easily get using in short order.

Michael Lopp's keynote was thought provoking, and focused. He spoke on the three archetypes critical for the success of a startup, the engineer, the designer, and the dictator.

The old & new field API in D8 session was another crazy mind expanding session that incorporated much of the new D8 hotness. For example it was reported that field instances are now CMI compliant, work on field widgets and display settings are in the works.

Ryan Weaver’s Behat session was splashy, inspiring, and raucous. It covered how Behavior Driven Development has the possibility to convert user stories into tests that can be executed as QA steps.

The Takeaway

What was truly memorable was the sheer scale of DrupalCon. With 3300 recorded attendees, the logistics of coordinating all the speakers, the food, coffee and extra time activities was staggering. The continued growth of the Drupal Community at times can be hard to quantify, but when you’re standing shoulder to shoulder with 3000+ drupaleros for a group photo, the exhilaration is palpable. What’s even more impressive is that not long ago, DrupalCon North America could have fit inside of one of the smaller conference rooms with space to spare. The sprints on Friday alone had higher attendance than several early DrupalCons, as claimed by chx.

More people at the sprints than whole early DrupalCons

— chx (@chx) May 24, 2013

All in all, it was an exciting week and a productive one at that.

DrupalCon Portland produced numberless new connections and strengthened friendships, a FEMA affiliated disaster logistics site in under 24 hours supporting victims of the tornado in Oklahoma, committing twig support into Drupal core, and completely swamping the testing servers for core patches.

For a short, rainy week, it was good work, good work indeed. All of this stems from a central Drupal truism: our strength is in our community. Codebase is one effect of that strength.

Yesterday Drupal.org got hacked, and potentially all the password hashes on the site fell into malicious hands. According to the security team's announcement, the attack was not a result of a Drupal vulnerability, but of other, as yet undisclosed, software on the server.

Drupal has long had one of the best security track records among open source CMSs. The security team does a great job of tracking down even the smallest exploits, often removing modules that maintainers choose not to fix. The vast majority of fixes and security updates we see are protecting against "privilege escalation" -- vulnerabilities that can only be exploited by users who already have some level of administrative access.

For example, there was a webform update yesterday to close a hole that allowed somebody who already had permission to create or edit a webform, to gain full administrative access. We use webforms on a huge number of sites, but we have never set up a configuration where we give an untrusted user the power to create or edit webforms. And yet on a large, community driven site, you might want to give some people the ability to create a survey without further access. This kind of strict, detailed review leads to a project that has a high level of security baked in. It's very rare that we see the more dangerous kinds of exploits -- SQL Injection, Cross-site scripting (XSS), or Remote Code Execution.

This incident highlights that there is more to security than just the software. In this case, something else in the hosting environment provided a weakness that allowed an attacker to break in. What was it? They haven't said, so far, but we can speculate on some possibilities:

Tags: SecurityDrupal PlanetIndustry: BusinessE-CommerceSoftwareStory Type: Sustainable/Open Business

This month's Central Denver meetup varied slightly from the normal format. The focus on the meetup was discussing our experiences and thoughts from Drupalcon Portland. As such, the main introduction question was, "Did you attend Drupalcon Portland?" It was nice to see that roughly seventy-five percent of audience had attended, as it left a lot to discuss. We once again provided collaborative notes for members to contribute to and we certainly had a lot more participation than last month. Thanks to whoever created the fun ASCII art at the bottom of the notes.

So here are some sessions that various members found most important and/or exciting to discuss. John Fiala brought up a keynote for this year's Drupalcon, Thriving In A World Of Change: Future-Friendly Content With Drupal, wherein Karen McGrane addresses the very important distinction between storing data and presenting data, and demonstrates how WYSIWYG editing is a relic of the age of publishing; the antithesis of mentioned distinction.

Someone then mentioned Sam Richard and Mason Wendell's session titled Managing Responsive Web Design with Sass and Breakpoint. It's great to see SASS mature into a standard front-end tool, especially when RWD is only becoming more important with time.

Rick Manelius was excited to talk about the Drupal 8 configuration management initiative and all of the fun we'll soon be having with YAML. All of this was discussed at length during Greg Dunlap's session, Using The Drupal 8 Configuration System. This is a huge step in the right direction, and the pains that we've experienced using features and other tools that convert configuration into code will largely become a relic of the past. While this is great for the future, someone mentioned using a settings.local.php to alleviate some of this pain now.

Carl Wiedemann talked potential problems with Drupal 8's architecture, pointing to Mark Sonnabaum's core conversation titled We're Getting OOP Wrong and There's Still Time to Fix it.

And finally, Scott Reynen and I made mention of a couple sessions in that are listed in our Favorite Moments in Portland.

Whew, that was a lot to talk about. Fortunately we also had time to do something a little out of the ordinary. Normally we have a general question and answer portion of the meetup, but this time we asked if someone was willing to have the community help them work through the given problem in real time. We adopted this idea from the South Denver Drupal Meetup and it went surprisingly well. Maida Scott was able to resolve the problem of creating a subtheme out of the Marinelli base theme. It was great seeing the community's collective debuggin mind asking the question, "Why?" and identifying problems before making conclusions. Pro-tip: Drupal's theme and module registry gets confused if it encounters multiple .info files with the same name.

This was proceeded by many hurrahs; some were cheers over food and drink at Interstate Kitchen and Bar.

Node.JS is the hottest new technology that is making the web real-time. The most important thing is that node.js is not a server-side language, it’s a web-server that is incredibly fast and efficient.

Throughout this series of articles Propeople Drupal experts will talk about some basic concepts of node.js and how to write some cool things using node.js and node.js module.

So, first of all let’s understand what is node.js and when we should use it.

What is Node.JS

Node is a JavaScript runtime that works on the server side, based on Chrome's V8 JavaScript runtime. This means that if you know javascript, you can easily write something interesting on node.js and, practically, you can use the same code for the client and server side (ex: some classes, models, etc) with one exception, on the client-side you are working with DOM, where on server-side you may work with databases, file-system, etc.

It’s an Asynchronous programming language, in other words, while you have to execute some actions ex: db select, you tell the node.js to make a db query and after it’s done return a response, during this time you can do anything in parallel.

It is single process but it’s multi-threaded – compared with php which creates a process for each user in node.js the same single process can execute parallel actions for each user. This is much faster because servers don’t need to spent time and resources for creating a process for each request, get some data from database and other operations. You just need to start the server, load all data and wait for user requests.

Node.JS is event-driven. It’s similar to events in a browser, while you’ll be waiting for an action from a user (button click or other).

Socket.io (Websockets in browser). Imagine you have a tunnel between a client and the server, through which can send messages in both directions, client-server-client. You can say to the client something like: “hey, you’ve got a new message, or there is a new comment on your article” and you don’t need to refresh the page or to send some ajax request from the client to verify this.

You can write extensions in C++. This is cool because with C++ you can integrate some external devices to your application, or use some libraries written in C++, or something else that node.js can’t do.

When should we use it?

In real-time web applications you should transfer a lot of data between a client and the server without refreshing the page. With node.js and websockets you can maintain a persistent connection between the browser and the server. This means you can create a real-time browser-based web app in node.js that practically doesn’t consume system resources to serve a big amount of clients. Any time you want to develop a web app that is communicating with server, node.js is a great option.

In next series of this articles the Propeople developers will talk about how to install and configure node.js/node.js module for drupal and also how to create a drupal module using node.js.

If you are planning to add some fast chat or messaging to your website, don’t hesitate to contact us about building your Drupal/Node.js functionality.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

Last week 9 of us from Aten attended DrupalCon Portland, 2013. With more that 3,300 registrations, this was the largest DrupalCon yet. Our team was privileged to be sponsors, speakers, and co-organizers for the event. As always, there were plenty of incredible sessions, so many people to catch up with, and no shortage of after-parties. Here are a few highlights from the team.

Ken

A recurring theme that surfaced in a number of sessions was that of changing processes. Responsive web design has had a huge impact on how we design and develop websites. Jared Ponchot's talk, "Designing on Purpose: Design Process & Deliverables in the Responsive Age", dove into the UX side of designing for a responsive web while Sam Richards and Mason Wendell gave front-end developers lots to think about in their session "Managing Responsive Web Design with Sass and Breakpoint".

I'm extremely excited that Twig is going to make it into Drupal 8. This change will be one of the greatest boons to front-end development for Drupal in years. Jen Lampton has done a fantastic job leading the initiative and it was great to see so many people working on Twig at the code sprints on Friday.

Finally, John, Garrett and I spent a lot of time discussing the future of Center and Prototype, the base and starter themes Aten uses internally to kickstart projects. They're now full projects on drupal.org and we're planning on having a release for each in the coming weeks. Exciting stuff!

Jon

It was good to see so many people turn out for the "Drupal DoGooders Happy Hour" that went to benefit Aaron Winborn. A couple rooms full of people were able to enjoy some food and drink, and talk with Aaron and his family via Google Hangout. I think we all appreciated being able to thank Aaron for the years he spent contributing to the Drupal Community and to give a token of our appreciation back to him and his family.

Scott

My favorite part of DrupalCon was probably Ashe Dryden's "Programming Diversity" session. I'm sure I wasn't the only audience member hoping Ashe would give us a silver bullet for diversity problems in our industry. Instead, she explained the complexity of the problem and gave us some practical approaches to helping solve it. One of her tips, "Have the hard conversations," I unfortunately had an opportunity to apply while still at DrupalCon, in some hard conversations I might have let pass without Ashe's well-designed slides fresh in my mind.

Karyn

What an amazing week! Though this was my 5th DrupalCon, it was also my first opportunity to actually be part of a company that had a booth. That was an interesting perspective to the conference from the get go. It was fun to be able to greet people, talk about the awesomeness of Aten, and hand out scout books.

I didn't make it to too many sessions this time around. However, I ran the "Making Drupal Meetups and Events Rock" session with an amazing panel of Drupal contributors. We had great feedback from that session and more questions than we had time to answer.

The other highlight of the week for me was the "Women in Drupal Meet & Greet Reception" on Tuesday night hosted by Aten Design Group and Squishy Media at the Squishy Media offices. Despite the torrential downpour we had an amazing turn out. Women started piling in right around 6pm, and continued throughout the night. Squishy Media had to send the final ladies home around 11 pm. Beyond great networking, events like this do so much to promote women in the community.

Ryan

For those who didn't catch the featured Coding/Development session, "Development, By The Numbers" was a fantastic look at the long term readability and maintainability of open source projects. The short end of that is Drupal is looking better and better as time passes. The concepts and tools discussed, such as checking cyclomatic complexity with phpmd were invaluable, and I encourage every developer to check it out.

I also had a great time attending a couple of BoFs. One was on non-profits and NGOs, and people expressed frustrations in upgrading distributions, which was extremely valuable given that Aten maintains the OpenAid distribution.

I was delighted at the opportunity to host a BoF on Vagrant, and it was a little awkward given my utter lack of experience in hosting "BoFs"–but I had a blast nonetheless. The Drupal community could use some input from those who have DevOps experience, and I hope to have inspired others to contribute back to the DevOps Drupal group.

John

I had a blast in Portland. It was great to get a chance to see coworkers face-to-face again after working abroad in Australia for the last 6 months.

I was super excited to see Jonathan Snook present on SMACSS after reading his book a couple times and having presented on the subject myself in the past. He didn't disappoint.

For me, the highlight of the conference was Karen McGrane's keynote, "Thriving in a World of Change: Future-friendly Content with Drupal". Karen's thoughts on structuring content for longevity and flexibility are a fundamental shift in how we view website development. Read her book if you haven't. Drupal is ahead of most platforms when it comes to structured content. However, Karen warned we may be taking a step back with in-place editing features in core. While easy to use, in-place editing leads authors to believe their content will always live within the context of the current page. We should be encouraging authors to look beyond the page.

Since sessions were recorded, I've been catching up on a few that I missed while at the event. "Plugin Haikus" is one of those, and is definitely worth watching for anyone interested in a better understanding of the cTools plugin system–something that's been on my mind a lot lately.

Garrett

Drupalcon seems to always be as much about kicking with cool folks as it is about sessions, and this round was no different. I especially enjoyed getting to high-five John Ferris in person, as he's been representing Aten in the southern hemisphere since last December.

The front-end track contained some really great content, the highlight for me being Jonathan Snook’s "Scalable and Modular Architecture for CSS". The session was essentially an overview of Snook’s excellent book of the same name, which reaffirmed some of the front-end approaches we’ve been building for at Aten.

Lydia

The DrupalCon 2013 highlight for me was having so many people from the Aten team in Portland; it’s always a good time when we get out of the office together! We enjoyed watching sessions by our team members, roaming the streets of downtown Portland, trying new restaurants, new bars, and debriefing in our hotel lobby. Ken Woodworth, Aten’s Art Director, flew in from our Rochester, NY office, and John Ferris, Front-end Developer, was able to join us all the way from Australia; it was great to see them!

Spending time at the booth talking to old friends, new friends, and colleagues is always a treat. We shared hundreds of our DrupalCon Portland sketch books, new posters, and great conversation about our work and clients. These times always reinforce my gratitude for being able to work with such a great team doing good work for an amazing client base.

Justin

For my part, DrupalCon is always a great opportunity to connect with people – clients, friends, other shop owners, and even colleagues – who we otherwise just don't see very often in person. I had some great conversations and was inspired by the sheer growth in the Drupal community... there are some incredible organizations doing all kinds of great work, and it was great to see that again first hand.

Shopify open sourced Dashing late last year, their Dashboard software created for displaying dashboards on TVs around their office. We decided to see have a play and see what statistics we could show on our office TVs.

Install is simple via gem, although as a non Ruby person I spent more time than I should have installing Ruby 1.9 (from source in the end). Once up the server runs on a port (3030 as standard) and applications can simply send data to the dashboard in a certain format and it is displayed immediately.

Open Atrium

read more

Drupal Dev Days Dublin is ideally timed to be at the very last minute when developers can still come together and make API changes to Drupal 8 core as per the current timeline.

The event is looking for sponsors, awaiting session submissions and people to register (only €25 for a standard ticket).

This is also a first of a kind event where extended sprinting is built into the planning. The generous folks at DIT (Dublin Institute of Technology) are providing space for the sprints the whole week before the event as well as the sessions. There are already Multilingual, Views and Field API/Entity API sprints proposed. Do you want to lead a sprint on Mobile, Performance or some other favorite topic or join existing sprints?

• Sign up for the event at http://dublin2013.drupaldays.org/about/tickets
• Join the sprints at https://groups.drupal.org/node/296483

#node-300938 .picture { display: none; }

I've had the pleasure to present the current state of the Drupal 8 Multilingual Initiative - great work of numerous highly respected individuals - just last week in Portland at DrupalCon Portland 2013. Although I did do live demos at previous editions of this session, at this point we have just too many great improvements, that it does not fit anymore. So for this session, I opted to provide a better overview and more context as to how this affects site building in general for Drupal 8, including the extent of change as it applies to contributed modules.

We are still working on several key pieces of the initiative, and will have meetings every Wednesday leading up to the code freeze coming July 1st, 2013. Join on our meetings to help with the remaining tasks. We have tasks for all experience levels!

Download the slides from https://portland2013.drupal.org/sites/default/files/slides/D8MI-Portland...

Knowledge Language English First time speaking at Drupalcon: Core convos, How to organize a sprint, Reviews, New contributors in InitiativesCathy Theys05/30/2013 - 11:52Developers Revolt: work for companies that provide contribution time

The first time I spoke into a microphone at Drupalcon Portland was during the conversation part of the Core conversation: Making core development sustainable by Greg Dunlap. I had so much adrenalin, I was shaking. I took notes while waiting in line for the mic, so I had a bit I wanted to say. :) That was also the session where the Developer Revolt was said out-loud: that developers, since they are in demand, can insist that they only work for companies that give them X number of hours to work on contributing to Drupal. I suggest that X equals at least 3 hours per week.

The problem with that is that even experienced drupalers can use help picking issues to work on. So having support to help developers use their community hours well is important. I have some ideas about how to put that into practice, so I'll be reporting on how that goes later in the summer as I experiment on some of my fellow comm-press folks.

Plan a sprint in your hometown

My main session can be watched now for anyone who is thinking about organizing a sprint in their hometown. At portland, we had about 350 people at the mentored sprint and about another 250 in the regular sprint... but the Running coaches wanted! Contribution sprints and trainings session by Jess, Andrea, Addi and me, has info useful for any size sprint, 8 participants and on up! I'm super happy this was recorded so that people can watch it anytime and see that they themselves can do a sprint. Also, it forced us to organize documentation we already had into a clearer document on drupal.org: Sprint Resources. One of the things we took to heart from the optional speaker webinars was to make our session accessible. So if anyone has feedback on how we did in that area, I'd like to hear about it.

Passionate about needs tags? Yep.

Patch Reviews: Get good reviews, give good reviews. Faster. by Andrea Soper and me, I think, gave me a chance to speak passionately. I got to propose crazy suggestions for the future, and I took notes of suggestions that people had. One super outcome of this session was that it might actually be possible to do one of the crazy suggestions which is to have a check list of remaining tasks, that will automatically link to instructions (Contributor task documents). Talking with folks, it seems like a timeline for a checklist of needs, is at least 3 months, and after the Drupal 7 port of Drupal.org. Another good suggestion was to have a sidebar block that highlights if a patch is one of the first couple produced by a new person.

Missing target audience, no problem. New contributors in core initiatives.

New Contributors and Core Initiatives: What they bring and how to bring them in by Jess and me, was given to a target audience: Core Initiative Leads, who ... had scheduling conflicts and were not able to attend. The audience that was there was great. :) But, since the core conversations were recorded, I will be checking in with some of my IO friends to see if they watched it. ;)

While working with Migrate and Migrate 2.6 beta 1 I stumbled upon several undocumented "surprises" which are hopefully going to be documented, but so far, you can spend lots of time trying to figure out what may be wrong. Here's roundup of my findings:

1. There is one correct way of registering migrations and handlers

You should do this in hook_migrate_info(), your register code may look like this:

Read on about Migrate Module Caveats. May Save You Some Time... and Hair

Last week, Alexis Findiesen and I traveled to Portland, Oregon for DrupalCon. Portland, cleverly noting that Drupal's logo is a water drop, welcomed over 3,300 Drupalistas from all over the world with four days of nearly non-stop rain! Now that Alexis and I are back on the east coast and mostly dried out, here's a quick summary of a few of my favorite sessions, keynotes and DrupalCon moments.

Drupal 8 is Coming!

Now that Drupal 8 "Code Freeze" is only about a month away, we're starting to get a really good idea of which features are going to make it into the final release, coming this winter. Project lead Dries Buytaert's The Current State of Drupal 8 keynote on Tuesday gave a good overview of where things stand now. Or rather, where they stood last Tuesday, but I'm getting ahead of myself. Drupal 8 development has been focused on several major core initiatives, and the leads of most of those initiatives offered updates in breakout sessions. Here's a sampling:

• Views, long one of the most popular contributed modules for Drupal, is moving to Drupal 8 core. While the user interface is mostly unchanged from Drupal 7, under the hood it's been completely rewritten, and it should make site building much easier.
• Drupal 8 has a new templating engine called Twig. It's going to remove a lot of the complexity from Drupal theming, while at the same time giving themers even more flexibility to make Drupal sites look awesome.
• The Mobile initiative is going to make it much easier for Drupal to handle all kinds of browsers, whether it's a site visitor viewing your site on a giant 27" monitor, or your site's managing editor making an emergency update from her iPhone.
• Last, but certainly not least, the Configuration Management Initiative promises to eliminate one of the biggest causes of headaches for Drupal developers and site owners—synchronizing configuration settings from development to staging to production servers without blowing away content.

These and other sessions gave us some great information to help us continue to plan our own Drupal 8 migration (Have you started working on your migration strategy yet? We can help!), and upgrading the modules we've contributed to the Drupal project to version 8. There were also some great sessions on designing and prototyping for Drupal, creating interactive maps, and using Drupal as a backend to power data-driven mobile apps.

"Responsive Design Won't Fix Your Content Problem"

Drupal 8 does a great job of presenting content to a wide variety of devices in the post-desktop era, with responsive design out of the box. But Wednesday's keynote speaker, user experience guru Karen McGrane, says what the web really needs to be future-friendly is responsive content, with true separation of content from form, and an end to letting content creators treat the web like print.

Social Events and the Hallway Track

While the sessions were great, the real draw of DrupalCon is the opportunity to meet and hang out with other Drupalers, from down the street or the other side of the globe. Hallway conversations, informal "Birds of a Feather" sessions, lunches, dinners, a wet midnight trek to Voodoo Doughnuts, and even a "pinball pub crawl" gave us lots of chances to share Drupal war stories, talk about favorite modules and techniques, and explore chances for collaboration.

Help4OK

On Tuesday night, a group of volunteers gathered in DrupalCon's 24-hour Coder Lounge to build a website to help organize resources for victims of Monday's tornado in Moore, Oklahoma. The next day, FEMA director Craig Fugate officially announced the launch of help4OK.org in a tweet.

Core Sprints

Whenever you get several Drupalers together in the same place at the same time, great things tend to happen. When you get over 600 Drupalers together in the same place at the same time, truly magical things can happen. Every Drupal 8 session I attended included a plea from the presenter that went something like this: "Do you like what you see here? Do you want to make sure it makes it into the final D8 release? We need your help! Come to the sprint on Friday!" And people did. In droves.

Alexis and I decided to help out with the new Twig templating engine. Earlier in the week, there was a lot of concern that Twig wouldn't make it into Drupal 8. While Twig itself had been added sometime back, most of the rest of Drupal hadn't yet been converted to use Twig. Unless every single template in Drupal core got converted to Twig, well before the July 1 code freeze, Twig would be pulled out in favor of the old PHPEngine. A couple dozen of us settled around a few big round tables in one of the convention center's meeting rooms and started finding things to work on in the issue queue. Before long, there was an announcement that Twig had just been committed to core! Not too long after that came the news that the "mega-patch" (that would convert all of Drupal core's templates to Twig) was nearly ready. We helped out with checking to make sure the new templates were outputting the exact same markup as the old ones, profiling to make sure the new templates weren't any slower than the old ones, and a couple of other Twig-related tasks.

Elsewhere in the convention center, other teams were working on other Drupal 8 initiatives, several contributed modules, and Drupal documentation. It was an exciting day!

Sadly, the next North American DrupalCon isn't for another year, in Austin. But CapitalCamp, D.C.'s annual Drupal Camp, is barely two months away!