Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Sep 10 2020
Sep 10

Let's decouple Drupal - Well, what exactly?

When it comes to decoupling, it turns out there are many options on how to decouple. Not only are there many technology choices in choosing the right frontend framework and APIs involved, the questions become also more foundational: Which system should be in charge of handling different aspects of the application, e.g. routing, placing blocks or authentication?

So before moving on, we need to clarify what exactly we want to achieve:

Clarifying goals: Why to decouple?

For us, the main reasons are:

Independent frontend development

By separating the frontend from the backend, frontend development can happen completely independent of the backend. So frontend developers do not have to know Drupal development, but can focus solely or their part: the frontend. That way, it's much easier to find and onboard frontend developers.

Easier performance optimization

While efficiently lazy-loading CSS or JS assets of a page is quite hard to do with Drupal, modern frontend technologies handle this with breeze and simply lazy-load pre-built asset chunks as needed. Furthermore, the frontend can better optimize the page loading experience (and the assets needed per-page) since the frontend has the knowledge of what exactly is needed by which frontend component.

Re-usable frontend components

Re-usable frontend components - including asset dependency management - are a solved problem in the Javascript world and all the various Javascript frontend frameworks provide that. Additionally, tools like Storybook make it really easy to build up your own component library.

Modern frontend and UX

By building upon modern frontend tooling we can provide a more app-like UX to our users, handle client-side route changes and only reload and repaint what's needed when navigating pages. The web page can become and feel more app-like, or even be turned into a Progressive Web App that does more than providing an offline copy of the site!

Challenges faced

This sounds all good - but there are lots of challenges that must be well-considered:

Re-inventing the wheel

By throwing away Drupal's frontend, you also throw away all the existing integration Drupal provides with its own frontend. Besides the more obvious, like handling forms and logins, features like contextual edit links, previews or the layout builder just do not work out of the box anymore. So one has to develop alternative solutions for all those features - if needed. Depending on the solutions choosen, this can be a lot of work.

Server-Side-Rendering and Hosting

For delivering a decent user experience and being friendly to robots (Google) some sort of pre-rendering is needed on the server. So this needs extra thought and comes with new infrastructure requirements (Node.js) that, come at a cost, and must be considered when choosing where to host.

Cold cache performance

When the Drupal backend is connected via JSON API or GraphQL a first, uncached page load typically needs various kind of data, quickly ending up in multiple API requests to the backend. Since all of those need to be resolved on a cold-cache page hit requests possibly end up really slow and lead to slow first page loads.

Coupling of the frontend to the backend

When the frontend talks to Drupal via its default JSON or GraphQL APIs, the frontend needs to know about Drupal's data structure. Field names, their types and entity relationships are no Drupal interna anymore, but become part of the contract between the backend and the frontend, limiting the possibilities to develop them separately. One could implement custom JSON endpoints or GraphQL Schema to mitigate and fine-tune that.

Our solution: Rendering into Custom Elements markup

We figured that in order to reach the mentioned goals, we can use a soft approach to decoupled Drupal in order to keep more of Drupal's features available. The basic idea is that Drupal keeps rendering pages by providing the main page content as custom elements (markup). Then, this simplified markup can be picked up by client-side frameworks like Vue.js to handle rendering the elements client-side.

An example of custom element would be the following markup for a Twitter paragraph:

<pg-twitter src="https://twitter.com/bmann/status/1283090375742091264">
  <h3 slot="title">#Driesnote suggesting to ship an official component for React and Vue for managing menus</h3>

Note that we use pg as abbreviation for paragraph here. Or a quote paragraph:

  <h1 slot="title">a quote from twitter...</h1>
  <p>#Driesnote suggesting to ship an official component for React and Vue for managing menus<br>Ship it in NPM as those devs expect.</p>
  <span slot="author">Boris Mann</span>

Generating this markup, is exactly what the Custom Elements module does. The module renders the data of all visible fields either as attribute to the custom element tag, or as nested tag with a slot attribute.

As custom elements are part of Web components specification, web components provide a good fit for rendering the content client-side, but other client-side frameworks like Vue.js or React.js can pick up the data and render it as well - so there is plenty of choice for the best-suiting client-side solution.

So what about the page template?

Since the header and footer area is pretty static for most of the time on most of our sites, we figured they are best implemented by mostly static components in the frontend. Any dynamic parts, like meta tags or navigation elements can be complemented with data provided by (long-cached) API calls or even computed client-side (for example, the active menu item). If necessary, it's easy to re-render parts of it and client-side frameworks like Vue.js and React can handle updating only the necessary bits when navigating pages.
While the dynamic per-page content is provided by the backend in a single API response per page, the header and footer can be controlled by the frontend. The frontend application takes the custom element content and renders it, next to taking care of updating essential page metadata like meta tags.

Thus, for rendering individual pages, the frontend needs to fetch the main content - rendered as Custom Elements - as well as any page metadata that it needs for rendering the page from the backend. For that, we've implemented the Lupus Custom Elements Renderer module which turns Drupal into an API backend providing exactly that.

Summing up

By rendering the page shell and custom element content in a frontend framework of our choice, we achieve all of our goals stated. Moreover, the custom elements "format" provides a good way of decoupling the frontend of the backend, since any Drupalisms or backend complexities in the data model can easily by translated into a meaningful collection of custom elements. Those elements comprise a well-defined structure representing your site's content elements and transferring the necessary data to the frontend. In the frontend, the custom elements map nicely to Vue/React/Web/... components.

By keeping Drupal's page routing mechanism, we can keep using Drupal's path handling, including useful features like editor controlled path aliases or redirects. Since page responses are handled as whole by Drupal, we optimize and cache full-page responses and leverage Drupal's existing cache infrastructure and optimized cache tags for caching individual parts of the page.

Finally, the approach taken allows us to keep using some of Drupal's existing solutions like, cookie-based authentication for user-specific page responses, the layout builder or even form processing.

Following up

Since there is so many details more to talk about, I'll be following up with further blog posts in the coming weeks, covering the following topics:

  • Selecting a frontend framework. Server-Side-Rendering and hosting options
  • Architecture variants, Authentication, Custom Elements markup & json formats
  • A developer introduction: Creating components, adding Custom Element processors, the relationship to Drupal's render API, Custom routes and optimizing cache metadata.
  • Handling blocks & layout builder, content previews, forms, caching & performance optimizations.

Finally, I'm going to talk more about this stack at the Drupalcon Europe 2020 in my session "Custom Elements: An alternate Render API for decoupled Drupal" - so mark your calendars!

Oct 04 2017
Oct 04

Three days of sessions, discussions and meetings, one day for community, businesses, publishers and practices, and another day of code sprints - Drupalcon Vienna was a blast! It was very special experience for all our team members to have Drupalcon in town and we are proud to be among the supports of the event.

DrupalCon Vienna 2017 Sponsor
DrupalCon Vienna 2017 Sponsor

Here is a summary of our take-aways of the con:

Headless Drupal

One of the most discussed topics on DrupalCon Vienna was the idea of a headless CMS combined with a completely decoupled frontend. This way Drupal could not only serve as backend for a single website but as centralized data deliverer for applications of all kinds of devices. Combined with powerful JavaScript frameworks, like Angular or React, Drupal sites keep pace in the insanely fast changing world of web applications. Therefore Drupal should no longer be seen as an "all-inclusive"-CMS solution but as a single part in a modern Web-infrastructure and can return to its core strengths: Managing content.

As an example of how such a modern infrastructure could look like, kurier.at gave an insight of their system.

Adam Zielinski (CTO Telekurier Online Medien GmbH), (c) Amazee Labs
Adam Zielinski (CTO Telekurier Online Medien GmbH), © Amazee Labs

For further reading:

Contenta - API distribution
API-first initiative
Session: Headless, stateless, DB-less: how Kurier.at is transforming digital production with Drupal, NodeJS and Platform.sh


Andrew Macpherson, Théodore Biadala and Kristen Pol are part of the core accessibility team and it's always interesting to see what Drupal has achieved in all those years adressing persons with disabilities. The team briefly talked about some components of accessibility and the recent core accessibility improvements and what challenges they are facing. They gave half of their time room for discussions, which was very enlighning and informative. For instance automated testing can only cover around 40% of all accessibility issues. To get reliable test results many testss need to be done by real persons.

Another highly interesting, mind opening talk by Everett Zufelt was about how even little changes to the code can have a huge impact on a site's accessibility. Bringing in just a little more structure and semantic by using a wide variety of the available HTML5 tags, instead of just using <div> and <span>, is a big step forward for people depending on screen readers. The presentation also featured a list of good and bad examples which obstacles can be found and how most of them can be easiliy eliminated.

Andrew Macpherson, Théodore Biadala, Kristen Pol, (c) Amazee Labs
Andrew Macpherson, Théodore Biadala, Kristen Pol, © Amazee Labs

For further reading:

Session: JavaScript and Accessibility: Don't Blame the Language
Session: Core Accessibility: How are we doing, and what can we do better?
NYPL Design Toolkit
Manuel Matuzovic: Writing CSS with Accessibility in Mind

eleven Administration Theme

The current administration theme in Drupal 8 looks nearly the same as in Drupal 7. No large improvements have been made in Drupal 8. Although there is an initiative starting on developing a new administration them (with React) this approach will take some time before it will be part of Drupal core. However, there is already a modern administration theme on the way: eleven.

The eleven Administration Theme should be a modern way of how an administration should look like and behave with CSS variables, CSS grid and other CSS techniques supported in most modern browsers. As this is not intended for a wider audience and addresses solely administrators and editors backward compatibility with older browsers is not implemented.

There is also an own subchannel in the Drupal slack channel for the eleven theme.

Morten Birch, (c) Amazee Labs
Morten Birch, © Amazee Labs

For further reading:

Session: Admin Theming & design for a modern Drupal 8
BoF: Admin theme eleven
Drupal 8 Admin Theme: Eleven

UI Patterns

With UI Patterns it should be easy to get rid of the templates folder in the theme and connect the display of a field to a template in the administration backend directly. Advantages are a better overview and less Twig files.

For further reading:
Session: Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8
Drupal module: UI pattern

Landing Pages and Layouts

The Thunder team organized a BoF about "Landing Pages and Layouts" which lead to an interesting discussion on how layouts can be implemented in Drupal, as well as the tools & modules needed for editors to be able to have the necessary "content blocks" available for building good landing pages.
During the keynote, Dries has shown a demo of the new Layout Builder, which is currently worked on for inclusion in Drupal 8.5. As Tim Plunkett noted there will be an upgrade path of panelizer to the new layout builder in core, so panelizer can be considered a future-proof solution for layouts right now.

Driesnote at DrupalCon Vienna 2017, (c) Amazee Labs
Driesnote at DrupalCon Vienna 2017, © Amazee Labs

For further reading:
BoF: Landing Pages and Layouts
Drupal Thunder Issue: Landing Pages and Layouts
Drupal Core ideas: Add a Layout Builder to core
Drupal Issue: Implementation issue for Layout Builder

Amazee.io: lagoon

Amazee.io demo-ed lagoon, their fully open-source docker production system. It's powered by docker compose, kubernetes and openshift and nice CLI and UI tools are planned for it. This and the branch-ed based auto-creation of new environments make it an interesting development that could be the base for the next version of our in-house docker CI system, which is able to create test-sites per feature-branch including initialized content. Amazing stuff! ;)

For further reading:
Introducing Lagoon, amazee.io’s fully open source Docker in Production system

Sep 24 2017
Sep 24

While the Drupalcon webseite has a good few pointers to the well-known major tourist attractions, as locals we'd like to share our knowledge about some of our favourite places with you! So here a few recommendations:

Viennese Wine and Heurige

If you stay for the weekend after the Con, you can join the Vienna Wine Hiking day, which I can highly recommend. There are 3 possible easy hikes through the vineyards with lots of options to stop for tasting gorgeous wine directly from the producers. Furthermore you may enjoy great views of the city even if the wheather is not that great!

If you stay long enough, don't miss it! You can find details and options at https://www.wien.info/en/shopping-wining-dining/wine/wine-trail

If you cannot join the wine hiking day, be sure to visit some Viennese "Heurige" (wine taverns). Good options would be the Schreiberhaus or a little bit closer to the city-center Sissy-Huber.

Otto Wagner Buildings

The famous Viennese Jugendstil architect Otto Wagner (and friends) has left lots of traces back in the city. Apart from some of the subway stations (you won't be able to miss them) we'd recommend looking at the following buildings at least from the outside:

Cafés & Restaurants

Kaffee Alt Wien: An interesting mixture between a traditional Vienese Cafe and a "Beisl" (pub). The food can be recommended too, simple but authentice Viennese dishes, like Gulasch, Schnitzel and a variety of sausages. Although the Kaffee Alt Wien is mentioned in travel guides, it has not lost its athmosphere and is visited by tourists and locals alike.

Flatchers: Great steaks for a reasonable price. There are two restaurants in the same street: A French bistro with georgous French athmosphere and a larger one in American style.

Brunnenmarkt: A local market in one of the lesser known districts, lots of immigrants of south-eastern Europe and Turkey run market booths and Cafés around a nice plaza. You'll find great athmosphere and good food options: Kent, Cafe Ando, Cay Cafe am Yppenplatz

Barfly's: A cuban style cocktail bar with authentic athmosphere and music!

Wolfgang Ziegler

On drupal.org:


Drupal evangelist since 2005, Drupal Core contributor & contrib maintainer, TU-Vienna graduate (Information & Knowledge Management)

Dec 05 2016
Dec 05

The first Drupal IronCamp took place in the beautiful capital of the Czech Republic in Prague at the end of November 2016. More than 200 attendees from 27 countries took part in four days of sprints and two days of sessions.

In such a relatively small group of people I could get in touch with everyone I liked to, keynote speakers, CEOs, friends and other drupalists.

Group photo

So here is my summary of the sessions I have attended and which I found of interest.

KEYNOTE - Michael Schmid (@Schnitzel): The Future of Drupal

Michael showed us what people had in mind at the beginning of the 20th century when they wanted to predict the future now. It was both interesting and predictalbe, but also showed us that we still have not reached everything those people had in mind. The focus of this keynote was on Personalisation, Decoupled, Microservices and Containers - four fields, in which Drupal is already prepared for the future but not yet fully developed.

  • Personalisation: Websites won't be looking the same anymore. For disabled persons or based on a user's preferences websites will display only partial content or different content. This results in complex testing scenarios.
  • Decoupled: Drupal already consists of third party components, like Symfony or Twig. Also, Drupal already works great with decoupled frontends and technologies like node.js, React and other javaScript frameworks.
  • Microservices: Split up larger tasks into smaller ones, but keep an eye on coding standards and used programming languages and libraries.
  • Containers: A consistent website environment for development, testing and live will be achieved with the use of docker containers.


Fabian Bircher (@fabianbircher): Configuration Management: Theory and Practice

Fabian had one of the most interresting talks of this camp, which resulted in many discussions and talks in person with Fabian Bircher, Wolfgang Ziegler (@the_real_fago) and me (@KnudFrank).

The core theme of this presentation was the introduction of a new Drupal 8 module Configuration Split, where you can easily use Drupal 8s configuration managemen and split configurations for the use of different environments or different use cases.

[Fabian' blog post and slides] [Module: Configuration Split]

KEYNOTE - Larry Garfield (@Crell): Software Management Lessons from the 1960s

Has project management, described in "The Mythical Man Month" by Frederick P. Brooks Jr. in 1975 and 1995 changed in today's world? Most of the thesis described by the pioneers of modern computer architects and project management are still true. Larry and the audience had to admit this with no regret, but with relief. So project and software management has a steady and solid fundament to build upon and to rely on. This is good for companies working in collaboration with other companies and especially for the open source community to work together in such a large project as Drupal.


Théodore Biadala (@nod_), Mathieu Spillebeen (@MathieuSpil): Offline-Drupal

Comparing the approaches of Google's AMP, Facebook's instant articles, Appcache and Serviceworkers with real-world examples. Some techniques have limitations in browser support. Serviceworkers seems to be the most promising technology for caching websites in the browser, but unfortunately this still lacks support from Apple Safari. 
What's interesting about those "Progressive web apps" is that they do not necessarily require a front-end developed in Javascript. There is even a Drupal module: Progressive Web App.


KEYNOTE - Janez Urevc (@slashrsm): Ask Not What the Community Can Do for You, Ask What You Can Do for the Community

Only 0.5% of the users of Drupal contribute to the community. In this keynote Janez engaged the listeners to contribute to the community as well. He also showed the pros and cons of free software and propriety software and the processes in development with too many discussions and too few releases and too few contributers and missing functionalities. Engagement of developers is the core key for a community driven development.

Tamás Hajas (@eccegostudio): Short Twig recipes for Drupalers

Basics and advanced examples of Twig templates, inheritance, embedding, including and other useful recipes around Twig. An interesting talk but sadly a small crowd.


Wolfgang Ziegler: Efficient development workflows with Composer

Wolfgang had quite a big audience and lots of talk after the session. It seems that many developers have not worked so intensly with composer yet. But  this session provided an overview of possible workflows and showed practical solutions for building and deploying composer-managed projects. Wolfgang shared his experiences with handling Drupal projects and focued in his talk on approaches that can be shared across projects and team members.



A beautiful city but cloudy weather. Nevertheless the christmas market at night was shiny and also the after-parties had some surprises like the Cinema Zapping on Friday or the secret visit to Unijazz on Saturday. In two years the event will be back in Belgrad and I'm sure to be there too.

External links

Dec 23 2014
Dec 23

Last October Drupal Austria organized a full day long free workshop for getting started with Drupal 8 in Vienna. drunomics sponsored the event and I had the favour of presenting on Coding with Drupal 8. Meanwhile, Drupal Austria has got the recordings of the workshop up, the result: 4 hours of high-quality Drupal 8 training material in German:

[embedded content]

The available tracks are:

Intro - by Nico Grienauer (grienauer)
Sitebuilding Part 1 - by Philipp Melab (pmelab) & Sebastian Siemssen (fubhy)
Sitebuilding Part 2 - by Philipp Melab (pmelab) & Sebastian Siemssen (fubhy)
Theming - by Christian Ziegler (criz)
Coding - by Wolfgang Ziegler (fago)
Entwicklungsumgebung - by Philipp Melab (pmelab) & Sebastian Siemssen (fubhy)

You can find the playlist with all recordings on Youtube here.

Wolfgang Ziegler

On drupal.org:


Drupal evangelist since 2005, Drupal Core contributor & contrib maintainer, TU-Vienna graduate (Information & Knowledge Management)

Jun 11 2014
Jun 11

Today is a big day for the #d8rules initiative! Our crowd funding campaign was successfully funded and reached 100 % on Drupalfund. We really want to thank all you great 137+ supporters from the community: together you made this happen. Fago & klausi may continue with the progress that has been made already for porting Rules to Drupal 8 now and we are looking forward to gather additional funds in order to make sure that all 3 milestones can be reached in time!

#d8rules reaches 100% on Drupalfund

Why collect funds in the first place?

Before Drupal Dev Days Szeged, fago & me decided to collect funds for porting Rules to Drupal 8 because of the following reasons:

  • We felt there is a need for Rules in Drupal 8
  • Fago doesn't have enough free time because he runs drunomics, works on the Entity initiative for Drupal 8 and maintains several high-profile modules in Drupal 7 already
  • We felt that Rules should be ported as soon as possible, so that other contrib modules can have their integrations ported and we can fix some Drupal 8 issues like Conditions API & a Ctools-like Context system that is also required for the layouts initiative
  • As much as we love working on client projects, developing modules and giving back to the community on a large scale as with the Rules module is definitely something that we are passionate about 

So how did that all work out? Didn't think that crowd funding in Drupal was possible?

To be honest, we really underestimated the effort required to run this whole campaign. I stopped counting hours at some point, but I can assure that there were several hundreds of hours invested mostly from our free time to assure that everything is set up properly. So here's a wrap-up of how we did it, and be assured we have learned some lessons on the way :)

Setting up a project plan & defining our mission of course was critical in the beginning. That's probably something that you already do for your regular projects, so nothing really special in here. The only difference is that you don't know where your budget will come from.

  • Estimated hours: 1048
  • Community rate: € 45 / hour (drunomics and epiqo agreed to let fago & klausi work on Rules for the self-costs)
  • Milestone 1: € 13,500­  (~ $ 18,600) 
  • Milestone 2: € 15,660­ (~ $ 21,600­) 
  • Milestone 3: € 18,000 (~ $ 24,815) 
  • Total goal: € 47,160 (~ $ 65,000)

For a regular Drupal project that is probably a medium-sized budget, but for collecting funds that goal felt pretty ambitious. Before the #d8rules initiative, the projects funded via Drupalfund were $ 2400 maximum. 

This is why we decided to go for both corporate and crowd funding:

Corporate funding vs. Crowd funding

Sponsor packages for corporates vary between $ 650 - $ 11000 and Drupalfund perks were classified from $ 10 to $ 270.

We didn't want to loose much money on benefits so we tried to keep them focused at marketing (logos in different sizes on the website and other forms of saying thank you).

For the Drupalfund, we were able to add a physical incentive which seems to have motivated quite some people to donate:

The #d8rules Ruler was sold out a few days before ending the campaign and rumors are that Laserbox has created a second limited yellow edition for those who pledge last minute on the Drupalfund :)

In general, we tried to find sponsor package / perk names that encourage people to identify with supporting the project and which are directly related to the Rules module such as "Event dispatcher", "Batch processor" or "Data selection guru".

Calculating perks & a financial insight

Fees include Drupalfund platform (7,5 %), Paypal (3,5 %), Currency conversion USD to EUR (2 %) and VAT (20 %). This was a bit scary at the beginning, so we offer invoices for all donations $ 35+ in order to remove the VAT burden. Based on those fees, we put together estimations of how many perks we have to sell in order to achieve the goal: The plan was $ 10 x 70, $ 20 x 60, $ 30 x 60, $ 65 x 50, $ 90 x 50, $ 150 x 15, $ 270 x 5 which is a total of 310 people who pledge.

Let's have a look at what we got: 137+ people pledged as of June 11, 3pm CEST and the distribution is a bit different than expected:

Actually more people pledged larger amounts of money and within the $ 649+ range there are some pretty large donations which helped the fund succeed at the very end. 

Picking a crowd funding platform

We evaluated Kickstarter, Indiegogo & Drupalfund as three possible options to do the crowd funding. Kickstarter was too complicated to set up, because you need a legal entity in the US / UK. Indiegogo was tempting because it is quite established, has lower fees, offers a smoother user experience, you can do EUR or USD funding and choose between fixed or flexible funding models. On the other hand, we really liked the idea of Drupalfund becoming a role model for the Drupal community and felt like going with another platform would be counter-productive from a community standpoint.

Thanks to the great support from the Drupalfund team, setting up the campaign website was pretty easy. We could get some small usability enhancements in (you can now click on perks to donate) and they were very supportive throughout the whole campaign by promoting us on their blog for example.

So I think we picked the right trade-off in terms of choosing a funding platform and have shown that you may also run larger campaigns on Drupalfund. Still keep in mind that without those $649+ donations our campaign would probably have failed due to a lack of momentum around DrupalCon.

Generating & keeping momentum

Having the right momentum at the right time, I guess, is the hardest with setting up any campaign. Especially if you are asking for money, you'll need to bring people to your side. Luckily, we had lots of supporters from the community already: the Rules module has more than 200,000 reported installations and fago is well known all around Drupal.

I used the buffer app to constantly schedule tweets for the d8rules twitter account. Of course using an easy and positive hashtag such as #d8rules helped a lot. 

I also think that the Rules logo redesign by Nico Grienauer substancially supported the campaign. 

Rules logo with #d8rules hashtag icon by Nico Grienauer

Every campagin needs a video

Thanks to the great support from 11 Drupal community members at Drupal Dev Days, we were able to get some user voices captured which we then included in our campaign video. Dominik Kiss spontaneously offered to shoot and edit the video and I'm really thankful for the great work he did on a volunteer basis within the short time constraints of one week before launching the campaign on Drupalfund! 

[embedded content]

#d8rules video on Youtube: https://www.youtube.com/watch?v=gEH291mq48Y

Are we there yet?

Our colleague Max Mikus spontaneously offered to created some handcrafted indicators that visualize the funding process of #d8rules: The Drupalfund sucessfully filled up 50% of Milestone 1 but we still need more Sponsors to get there:

And then, Milestones 2 and 3 obviously would also be great to get funded.

But for now, we'd like to say thank you to everyone who believed in our project and pledged on the Drupalfund. It's awesome to see how many have supported us on the way either by donating, spreading the word and even offering volunteer help. Also note that there are already 10 contributors to the Rules 8.x repository on GitHub.

Let's have a discussion about: What's next for #d8rules and crowd funding in Drupal?

We will keep working, developing Rules 8.x based on the funds and limited free time that we have. I guess we have pushed the boundaries for crowd funding in Drupal a bit further, but there are also several questions to be discussed and resolved along the way:

  • How can we make contributing to Drupal more sustainable?
  • Is crowd funding a valid approach to gather funds?
  • How can we better attract non-contributors to fund and donate?

​Specifically for #d8rules, the next questions are:

  • How can we get Milestones 1-3 fully funded?
  • How can we attract large organisations to fund Rules in Drupal 8?
  • Should we do another round of crowd funding and how can we attract a wider audience?

Related issues

I would love to hear your feedback on the campaign. Asking for money in an open source world is tricky some times, but at least for the people I know: when we graduate from university we tend to have less time for contribution and spend more on client projects. Finding the right balance between contributing in the job is something that we always strive for at drunomics, but for huge initatives like porting Rules to Drupal 8, we really would love to get your input on how that should be accomplished. 

Thank you so much all funders on the Drupalfundour sponsors and everyone involved in the #d8rules initiative so far! We are just at the beginning :)

May 30 2014
May 30

Since the DrupalDevDays in Szeged Entity system constributors have worked a lot on getting the remaining beta blockers of the Entity system done, which are mostely centered around an unified field repository and entity storage improvements; i.e. automatic schema generation for your content entities!

We've been making great progress on the unified field repository front. There are new field info methods that are provided by the entity manager now, which cover the entity base fields as well as configurable or other module added fields. Those new methods replace the old field_info_fields() or FieldInfo methods, which we've been removed from Drupal 8 already. For more details, see this change record.

The work on automatic schema generation is not yet finished though, although we've a huge (300kb) RTBC patch which removes hook_schema() implementations and replaces them with automatically generated schema derived from the entity base field schema. Once that's in, we still have to take care of letting the system handle changes to the field definitions and consequently the schema (issue). Given that it will be possible to automatically generate an entity schema based on a site needs, i.e. we'll have entity storage capable of handling translations for multilingual sites. Actually, this is the primary reaon for getting this feature done that late in the cycle at all. However, besides that, I must say I'm really looking forward to not having to define the schema manually and I'm excited on how easy that will make it to define a new entity type!

I want to thank Acquia who sponsored some of my contribution time during the last weeks and thus enabled us to move on faster. Furthermore, I want to thank tstoeckler, plach, berdir and jessebeach who all did an amazing work on the mentioned issues!

Wolfgang Ziegler

On drupal.org:


Drupal evangelist since 2005, Drupal Core contributor & contrib maintainer, TU-Vienna graduate (Information & Knowledge Management)

May 13 2014
May 13

Today, I've the pleasure to introduce the #d8rules initative, our combined effort to get the Rules module ported to Drupal 8 in time!

#d8rules logo

Drupal 8 is coming...

Fortunately, the first beta of Drupal 8 is coming closer so it's time to make sure all the modules are ported and ready for Drupal 8. Unfortunately, the Rules module - my long term number one contributed module - is about to be left behind. I've worked a lot on Drupal 8 to get critical Entity API improvements like the new Entity Field API (called Entity Property API at the time of the introduction) as well as the new Typed data API done. Of course, the work on core is time intensive, not "done" yet and won't stop - so there is not a lot contribution time left for my contributed modules. :/

So where is Rules for Drupal 8 now?

In short, it's not there yet. While quite a bit of work under the hood and planning has been done already, the main work - porting of the module itself - is still to be done. As Drupal 8 ships with quite a bunch of important improvements, this requires the rewrite of significant parts of the module. In Drupal 7, the Rules module had to solve a lot of hard problems like handling its configuration, configuration translation, dependency tracking, integrity checks and plugins, which all have solutions in Drupal 8 core now. That's awesome, but it requires us to adapt the previous Drupal 7 solutions to work inline with Drupal 8 best practices. However, more than that - the foundational metadata Rules needs is already there as well!

The foundation is (mostly) there

In Drupal 7 the creation of the Entity API module, in particular its Entity Metadata wrappers and the backing Entity Property Information, was driven by the needs of the Rules module. While the Rules module makes it simple to work with data for site builders, the Entity module makes it simple for developers first. Subsequently, the Rules module can build upon the easy API and make it accessible via the rule model and its UI. For Drupal 8, the Entity Field API and its underlying Typed Data API are that easy API upon which the Rules module can build upon. That's great, as it means we have the foundation we can build upon in place - but again, it changed (improved) substantially and will require us to adapt a lot of what's there. However, having the Typed Data API and all the necessary metadata built-in means that the out of the box module and entity type support of Rules for Drupal 8 will be substantially better as well.

Actions and conditions in core

We've got an Actions and Conditions API in core already, so one might think another huge part has been taken care off. Unfortunately, no - those APIs have been created/ported with other use cases in mind, so they do not cater for all the more advanced features Rules users are used to. While I tried to make sure they fit Rules needs as far as possible when they were introduced/updated, they do not fit our needs yet and it might be impossible to make them fit without breaking those APIs. For Rules 8.x we plan to work on improving those APIs (from contrib) as needed first, so we can ensure they fit Rules' requirements. Once we are sure everything works out we'll know what we have to adapt and whether improvements can be contributed to core. Depending on how that works out, we'll see whether we can build up on the core Action and Conditions API or there will be Rules' variants of those APIs (again :(). For more details please see the related issues:

We have a plan

We've quite some work to do to get Rules ported to Drupal 8. klausi and me estimated the task to be additional 1050 hours work (from here). With us, working on it in our spare time besides our other contributions (Entity Field API, Rest module in core, ..) we figured the module won't be ready before sometime in 2015, not unlikely even 2016. That's obviously too late, so we'd love to invest more of our time and work on it during work hours as well, such that we can deliver a ported version in 2014. Our companys cannot afford taking that investment alone, but are up for supporting us and enable us to work on a community rate of € 45/h net cost for the project. You can find more details on the project plan and estimations on our initative site.

Rules needs your help!

If you think the Rules module is a valuable tool and helps you building sites faster, please consider supporting our iniatitive! There is a limited goodie for the 50 first supporters pledging >65$ - check it out. If you are going to Drupalcon Austin and you'd love to help, consider signing up for the #d8rules sprint! We'll get started porting either events, conditions or actions to the new API. Lastly, please help to spread the word! We've got supporter badges that you can embed on your site, and obviously our hash tag is #d8rules!

Video of #d8rules: https://www.youtube.com/watch?v=gEH291mq48Y



Iniative website: http://d8rules.org
drupalfund.us campaign: https://www.drupalfund.us/project/d8rules-support-rules-module-drupal-8
Project page: http://drupal.org/project/rules

External links

Apr 30 2014
Apr 30

For my Blocks & Layouts presentation at our local Drupal Austria Meetup, Drupal Dev Days Szeged & recently at DrupalCamp Donetsk, I have reached out to the community to gather some data. 60 participants provided their input on favorite Drupal 7 layout tools and what they expect from Drupal 8. It's time to share the results:

Which approaches are you using for realizing layouts in Drupal 7?

This is my favorite blocks & layouts related module

What are you most excited about or wish for Drupal 8

I have posted some further thoughts on Blocks & Layouts in D8 at my Drupal Dev Days Szeged wrap-up, and will cross-post a link to the survey results on the g.d.o survey post. Also check out my slides, download the raw survey data and let us hear your thoughts.

Josef Dabernig

On drupal.org:


I care about openness, clean interfaces and happy clients. Bringing together the open source community with real world use cases.

Mar 31 2014
Mar 31

Last week was packed with sprinting, presenting & exchanging ideas at Drupal Developers Days Szeged 2014. Let me share a recap with you: 

Connecting with the community

Wolfgang Ziegler (fago), our community friends Klaus Purer (klausi), Thomas Seidl (drunkenmonkey) and me passed by beautiful Budapest for some Parlament sightseeing and reached Szeged on Sunday evening, ready to spend the upcoming week sprinting on Drupal 8 and related projects. The conference hotel is located just next to the venue in walking distance to the city center with plenty of good & traditional restaurant options. The abording Tiza river provides a scenic setting and invites for a quick break when the mind needs to clear up a little during sprinting. Check out my flickr set for some visual impressions.

Drupal Dev Days group photo by TCPhoto.eu

After the good feedback on DrupalCamp Vienna that we had received as Drupal Austria members, we already felt quite proud of what we had achieved last November. Now, having attended last weeks conference, I feel like the Drupal Dev Days team just set the bar even higher. This is what dev days should be like: an entire week of sprinting & sessions where the community could get a lot of work done.


Dev Days are a unique chance of bringing together hundreds of people passionate about Drupal core to discuss hard problems and get work done in a very productive environment. The dev days team has shared these impressive stats:

115 core commits,
706 changed files,
11k+,7k- lines
7 change records
19 beta blocker/targets fixed
7 "hard problems" discussions

Of course, moving on with the Drupal 8 Entity system was fago's first priority. Fortunately, the smart folks working on the Entity Field API and the Multi-Lingual iniative have been able to use the opportunity to make great progress on having the Entity system automatically generating the schema for content entities, which besides being super-useful will enable all content entities to be translatable.

I joined the Lewis Nyman and the Drupal 8 front-end united sprinters to help with making Drupal.org finally responsive. Great progress has been made and I'm really looking forward to see this deployed. For now, you can go to http://bit.ly/responsivedo (user/password: drupal), give it a test-ride and report issues to the Responsive Bluecheese sandbox project.

Drupal Dev Days sprinting photo by dasjo

Tons of stuff has been worked on by many sprinters. One initiative that I'm really glad to see is the joined effort to make Search API for Drupal 8 the definitive solution for advanced contrib search solutions. Yay, for not having to choose between Apache Solr Search module and the generic Search API any more. The team around drunkenmonkey with nick_vh, mollux and others seems to have reached a lot. It looks like we can expect a flexible-as-usual Search API for Drupal 8 with quite some usability improvements. Easily setting up a site-wide search seems to be a high priority, which also means that we need an approach for including several entity types within a search. Note that per Switch from Field-based storage to Entity-based storage, fields in Drupal 8 can't be shared any more. Still, we think that there should be a way of indexing similar properties across entity types like a "date changed" field in a uniform way so that the search can be filtered and sorted on those. Personally, I'd envision some kind of meta-entity that allows to create fields that are based on similar fields of the underlying entity types and bundles. Similar to the abstraction that media module provides. This would allow us to use arbitrary search results in Views in a structured way. Here is the related Search API issue.

Sessions & BOFs

fago's session Drupal 8 Entity API has been substantially overhauled since last time in Vienna. Seems like the Entity system has made quite some progress during the last 4 months.

Drupal 8 Entity API Slides

My Blocks & Layouts from D7 to D8 presentation covered all display approaches from Contextual blocks over EVA to the big three: Context, Display Suite and Panels to provide a perspective on what has been planned for Drupal 8 as part of the WSCCI & SCOTCH initiatives.  

Panels lovers like Schnitzel and me are curious about where the Drupal 8 cycle will lead us in terms of fundamental Panels features like adding context based on CTools Context. I recognize that a lot of ground work has been made by converting Blocks to the Plugin system. An exensible Layout module couldn't get finished on time for core and there is a notion of a Context API but it isn't used anywhere, yet. On the other hand Display Suite has already been ported to D8. I understand that the Display Suite maintainers want to keep their focus on the entity view mode level while the Panels people are more into the generic layout approach that can also be applied to the page level using Panels everywhere for example. Let's see where this goes, also worth a mention is the Display Suite Inception module. 

Among the manyfold inspiring sessions, here are two presentations that I especially enjoyed: Community Building with Mentoring: What makes people crazy happy to work on an open source project? (slidesby YesCT and Building really fast websites with Drupal 8 (slides) by Wim Leers.

The community rocks & Drupal 8 is getting closer

Being someone that follows Drupal core development mainly from the side lines but who tries to keep a good overview of what's happening, Drupal Dev Days were really inspiring. As Florian Loretan mentioned in his talk Drupal 8 for real, it's not only about when Drupal 8 is going to be released but we should be closely watching the what Drupal 8 is going to be about. I think that the new and shiny architectural advantages that the Symfony integration provides us with, should also allow us to better decouple systems and make them reusable. For example for the upcoming Drupal 8 port of the Rules module, we envision to have Data selectors and the Conditions UI to be components that can be leveraged by other systems independly. Imagine a data selectors being used by a CTools-like Context UI, Metatag module or for setting default field values and visibility condition for blocks to be specified using the Rules Conditions UI.

Zsófi M. wearing Drupal glasses at Drupal Dev Days. Photo by TCPhoto.eu

Drupal Days Days Szeged 2014 have clearly shown: The community rocks. Now, let's start building websites in Drupal 8 already! If you are interested in collaborating on a project that requires development resources from Drupal 8 experts, let us know.

Sep 17 2013
Sep 17

Recently, the Drupal 7 Rules module has received some new functionality - mostly thanks to the development of the fluxkraft project. Quite some of them are under-the-hood improvements available to developers, but there is new stuff for site builders as well. So let's have a look at what's new for everyone using Rules and at what's in for developers also:

Configurable bundles for entity events & support for event settings

With Rules 2.4 events may define an event settings form via an optional event handler class. This might be useful in various scenarious, one of which Rules already implements: It's now possible to restrict entity related events to certain bundles immediately when adding an event. Compared to the previous way of adding a generic entity event plus a separate condition to check the bundle (e.g. "After saving new content" plus "Content is of type" condition) it's way nicer to just select the content type directly while adding the event:

Configuring the content type while adding the event

However, the new improvement is more than just a UX improvement - it performes better as well. That is, as when you use the event settings Rules only fires up when the configured event occurs - e.g. "After saving a new article". But if another content type is created Rules won't chime in at all. In most situations that's not a big improvement, but in certain performance critical situations it's quite valuable. That way it opens the door to the creation of useful new events (path-specific rendering events, anyone? :-)

Entity is of bundle condition

This is a new condition that is already available for a while, i.e. since Rules 2.3 - but as it relates to one of Rules' most confusing issues I'd like to highlight it here also. As probably most of you know, when you deal with an entity while conifguring a rule, Rules "sees" only all the properties and fields that it knows to be there later on. That is, if you have a content node, but you do not know the content type, you won't see any fields that are content-type specific. The way around this is that you do a check on the bundle, e.g. you use the "Content is of type" condition or the "Data comparison" condition to make sure the content type is e.g. "article". Given that Rules knows it's an article, you'll get to see the article related fields then.
However, with other entity types - e.g. taxonomy terms - there is no such neat "Term belongs to vocabulary" condition (patch welcome!), so you'd have to go with the generic "Data comparison" condition and know what you have to check for to make the fields appear (the bundle property, i.e. the vocabulary) - or you use the "Entity has field" condition for each field you want to use later on. Quite tedious. Now, the "Entity is of bundle condition" takes away the headache of figuring out what's the bundle of an entity and selecting this as part of a generic "Data comparison". Instead, just go with the "Entity is of bundle" condition, select your entity and bundle (e.g. the content node and "article") and you are good to go.

Event dispatches & task handlers

During the development of fluxkraft we faced the requirement to easily dispatch a bunch of events, depending on some configured events. We realized that this might be a common need for developers who want to support some neat event settings, so I worked together with Sebastien Siemssen (fubhy) to add this feature directly to Rules (actually it's fubhy who wrote all the code). So thanks to this improvements developers may make their event handler implement the RulesEventDispatcherInterface such that the handler gets notified whenever a Rule is configured (or "un-configured") with certain event settings.
Then, often you'd need to perform some sort of periodic checks in order to invoke the necessary events based upon provided settings, i.e. in one of our use cases we need to check twitter search results and invoke the respective event when new results are available ("polling"). The "Rules scheduler" module already solves executing that kind of periodic tasks, but it has been limited to invoke Rule components only. So the newly added support for Rules scheduler task handlers allows one to define custom task handler classes in order to make use of Rules scheduler's scheduling features to fire up custom code logic based upon a pre-defined schedule - such as checking for new twitter search results every 15 minutes. Combined, both features enable developers to implement configurable events like "A new tweet matches a search term" in a breeze.

Class based actions/conditions

In the fluxkraft project we've been using modern (object-orient, PHP 5.3, Drupal-8 style) programming practices in order to ease re-using existing PHP libraries and to simplify the update to Drupal 8 - so does the flux Services Integration project implement class based plugins similar to Drupal 8 (more on that another time). While doing that we realized it's quite a pain having to write old-style callback based Rules actions, conditions and events all over the place, and people new to fluxkraft would have to learn both approaches. Fortunately, I figured that Rules' object-oriented design already treats actions and condition plugin implementations as objects, thus supporting class-based actions and conditions in Rules was a question of adding just ~10 lines of code and some small related changes. (In fact, I'd have preferred class based plugins already when I wrote Rules 2.x initially - back in 2009, however unfortunately I felt the community would not be ready / like that approach at that time). Given that and the addition of a simple discover mechanism Rules allows you to provide new events / conditions / actions now :-) (requires 2.4 or later). For more information about that check the change record or look at a working example like the flux Twitter API module.

Not yet into Rules?

We've got nice new features, but you are not into Rules yet? Not a problem, there is a lot of free learning material around (get started with the handbook) or, if you attend Drupalcon Prague grab one of the remaining seats of our training and learn Rules in a day.

External links

Jul 15 2013
Jul 15

Three times a year DrupalCons bring the international Drupal community together and provide a great opportunity for coding on the next Drupal release, sharing knowledge or networking. Internationally-recognized speakers addressing a wide range of topics that appeal to software developers, website designers, IT managers and business executives.

DrupalCon Prague - We're going

This year's European DrupalCon will be in Prague from Sep 23th to Sep 27th. As drunomics is offering Drupal related services and most of its members are heavily involved in the Drupal community the company is proud to attend. Not only that, we have proposed three sessions:

Interested to see this sessions in the official DrupalCon programm? If so please share or comment on the DrupalCon website!

Christian Ziegler

On drupal.org:


Digital strategist with a strong interest in new tools, innovative projects and net-culture. Degree in business administration, focus on e-business, marketing and pedagogics. Engaged in the Drupal community as Drupal Austria Association's chairman.

Dec 14 2012
Dec 14

As previously announced on the IKS blog I’ve been recently working together with Stéphane Corlosquet on integrating the tools provided by the IKS project to do semantic content enhancements in Drupal as part of the IKS early adopter program.

The Interactive Knowledge Stack (IKS) project is an open source community which got funded by the EU to build an open and flexible technology platform for semantically enhanced Content Management Systems. Thanks to IKS, open source projects like Apache Stanbol, VIE.js or Create.js got started. While VIE.js and Create.js are already on their way to Drupal 8 via the Spark initiative, our focus was on integrating Apache Stanbol with Drupal 7. In short, Apache Stanbol is a java web application that leverages tools like Apache Solr, Apache Tika or Apache OpenNLP to provide a set of reusable components for semantic content management via RESTful web services. On the front-end side, VIE.js (“Vienna IKS Editables”) is the JavaScript library for implementing decoupled Content Management Systems and semantic interaction in web applications.

For leveraging Apache Stanbol with Drupal we send Drupal’s data over to Apache Stanbol’s EntityHub component for indexing, such that it is available to Apache Stanbol’s content enhancer. That means, we can use VIE widgets like annotate.js to send pieces of text over to Apache Stanbol for auto-linking content items indexed to Stanbol, which by default includes DBpedia entities, but could be easily extended by any source providing data in RDF. Next, the VIE autocomplete widget allows for easy tagging based upon entities indexed with Apache Stanbol - regardless of whether they come from DBPedia or from one of the Drupal sites your organization runs!


Initially, the plan was to use JSON-LD for sending Drupal’s content over to Apache Stanbol. However, while VIE.js makes heavy use of JSON-LD, Apache Stanbol does not (yet) support JSON-LD when indexing data in its EntityHub component (it does for sending back the text annotation results though). Thus, we used RDF/XML generated by the RDFx module to communicate with Apache Stanbol’s Entityhub. For easy indexing, we created the Search API Stanbol module, which leverages the (great!) Search API for that. Together, with an Apache Stanbol install that is pre-configured for Drupal’s use (link) you can get your own Apache Stanbol instance up and running with Drupal in a minute! Checkout scor’s screencast introducing the module!

[embedded content]

Next, we integrated VIE.js libraries and widgets into Drupal 7 such that one can easily use Apache Stanbol content enhancement capabilities from within Drupal. So we created the VIE.js module, which cares about adding the javascript library in Drupal. We used that to build an autocomplete widget for term reference fields that leverages the VIE.js autocomplete and creates according terms on the fly - while keeping a reference on the original resource. Moreover we integrated annotate.js with NicEdit which is available via the Wysiwyg module, such that text enhancements via Apache Stanbol are always just one click away!

Demo time

Enough with the talking, we’ve prepared a screencast demoing the Drupal integration:

[embedded content]

Of course, there is a demo available online also, so you can try it yourself! Head over to the demo page and give it a test!

Run it yourself!

While integrating all this nice stuff we made sure our work is easy to get up running yourself - so it’s easily re-usable and a good start for any further semantic content enhancement adventures with Drupal. So we’ve not only contributed the VIE.js and Apache Stanbol integration modules, but packaged the whole demo site as a Drupal distribution! You can download Drupal with all the modules needed and everything pre-configured out of the box (just as for Apache Stanbol) - just install Drupal as usual, run the pre-configured Apache Stanbol and you’ve the demo running.

There’s even a feature module which provides you with default content you can start over with. Check out the IKS Content Enhancement Demo distribution! Of course, you are welcome to use its issue queue for reporting problems or for collaborating on improvements or further features!

External links

Aug 08 2012
Aug 08


While the conversion to full CRUD for entities and classed objects for Drupal 8 made good progress, we’ve not yet reached the goals of fully translatable entities and having a default entity serialization for import/export, content staging and web services. For those points we need to know what’s in an entity! Yes we can look up the fields, but there are also base entity properties and further stuff modules put on entities, which both are no fields so we do not know anything about them. That is what the new Entity Property API is supposed to change: It’s about providing a unified interface to entity properties *and* fields, avoiding the split between fields and non-field properties. So fields will be entity properties working with the same API as well! Then, it’s about being able to instrospect what’s going to be in an entity - regardless whether it has been added by a module or by the user via field UI. But furthermore, with classed entity objects as the basis we can improve the developer facing API and make it easier to access property and field values (I’m looking at you, $entity->field_body[LANGUAGE_NONE][0][‘value’]).


As we’ve outlined in the WSCCI Web Services Format Sprint report we want to have a modern OOP, interface based API for properties. The API should allow for introspection, so that it’s possible to look up the defined properties of an entity type in advance. If you know the Entity property information system of the Drupal 7 Entity module, it’s a bit similar to that, but instead of adding an extra layer above the existing entities it’s about supporting it natively. So there will be no need for entity wrappers - all the easy API and information will be directly available in $entity. See the Entity Property API meta issue for a more complete list of planned features.

The current state

Work on that is currently done in a sandbox, where we’ll flush out the API with a test entity type. Once this works out, the plan is to convert a first entity type and to post a patch for further review to the core queue (here). So let me shortly explain the overall architecture of what we currently have or plan for: The idea is that *every* entity has to follow the following data model: The drupal8 entity data model Thus, an entity consists of multiple entity properties, which consists of one or more property items (just as field API $items), which each has one or more values (just as field API’s columns). You may notice that no language is in there - the idea is that this all just works with a reasonable language default, while it’s possible to get properties in a certain language by specifying an optional language parameter in the property getter. In order to ease access to the properties (in default language) we plan to implement magic getters, so that e.g. the node’s image alt text could be accessed like that: echo $node->field_image[0]->alt; As all entity properties have to follow the structure, it works the same way for others like the node title: echo $node->title[0]->value; $node->title[0]->value = 'updated title'; However, we actually know there can be only one title yes? So you can also do: echo $node->title->value; $node->title->value = 'updated title'; If the array access is omitted, it will just default to the first property item. That makes it easier to deal with single-valued properties, while it makes sure code does not break if a single-valued field gets changed to be multi-valued later on (or vice versa). Next, dealing with entity references should become easier as well, such that the system cares about loading referenced entities for you. E.g. to access the node author’s user name could work like that: echo $node->user->entity->name->value; For that all to work the system maintains so called “property definitions", what are a bit similar to $field and $instance for fields but are there for all properties. The system defines methods to look them up: foreach ($entity->getPropertyDefinitions() as $name => $definition) { echo "Property label: {$definition['label']}"; echo "Property type: {$definition['type']}"; } It will be possible to look up those definitions up front, i.e. without having a concrete $entity with data. So you can use it to generate UI. Of course there will be some more keys in the entity property definitions and we’ll add more keys on the way as necessary. Then the idea is to use the same API for other levels in the entity as well: foreach ($propertyitem->getPropertyDefinitions() as $name => $definition) { echo "Property label: {$definition['label']}"; echo "Property type: {$definition['type']}"; } That’s roughly where we are so far - of course some things will be adapted and change on the way. There is some prototype code in the sandbox, but nothing is ready yet. If you’d like to get involved, contact me and/or dive into the sandbox’s issue queue. If you are Drupalcon, don’t miss the Entity Property API core conversation and join the entity API sprints!

The time is running...

Yes, Drupal 8 feature freeze is not far away (December), so the time is running out. Unfortunately, recently I’ve not been able to invest enough time into this all to move on as quick as it’s needed now, so thankfully Acquia is helping out and funding some of my development on this. This will speed up things now, so expect a patch ready to review before Drupalcon :-)

External links

Wolfgang Ziegler

On drupal.org:


Drupal evangelist since 2005, Drupal Core contributor & contrib maintainer, TU-Vienna graduate (Information & Knowledge Management)

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web