The release of Drupal 8 will bring many improvements and new capabilities. Recently, Dries Buytaert, chief technology officer at Acquia and the founder of Drupal, sat down with Angie Byron, Wim Leers, and Alex Bronstein to answer a few burning questions about what this new release means in a live webinar. They went over some great questions, so we had the webinar transcribed. You can view the full transcript below.
Dries Buytaert: Hey everybody, another webinar. My name is Dries. For those people that have not heard about me or that do not know me, I started the Drupal project 15 years ago out of my dorm, worked on Drupal for 15 years now and I’m still the project lead. Then I co-founded Acquia and at Acquia I’m the CTO. That’s a short version.
Angie Byron: Hi, everybody. My name is Angie “Webchick” Byron. I got my start in the Drupal project in 2005 as a Google Summer of Code student. Over time, I got more involved in things like documentation, codes, reviews, core patch authoring, this kind of thing, and then over the years have now escalated to the point where I’m one of the core committers, so the people who make changes to Drupal directly. Within Drupal 8, I’m a product manager. Within Acquia, my job is to basically go out, talk to community members, and find out what’s stopping them from being awesome and help them be awesome; that’s about me.
Alex Bronstein: Hi, everyone. I’m Alex Bronstein, Drupal.org effulgentsia. I got my start also in 2005. Before then, I was a freelance programmer and I was writing custom CMSs for my clients between 2001 and 2005. In 2005, through one of those projects I discovered Drupal and realized that I would never have to write a custom CMS again because Drupal had all the flexibility that I needed. Then I ended up building more Drupal websites for a few a years after that and then joined Acquia to work on Drupal Gardens. For the last three years have been in the Office of the CTO working on Drupal 8 and I’m currently a Framework Manager for Drupal 8 Core.
Wim Leers: Hey, everybody. I’m Wim Leers from Belgium calling in from there. I started one year after Angie and Alex, so in 2006. I got rolled into it because I needed to build a website and I evaluated a bunch of CMSs. I find Drupal to be the best one, seemed that it was a good choice in hindsight. Got more and more involved in the community, did some interning work even for Mollom. After finishing my studies, I ended up joining Acquia to work on the authoring experience in Drupal 8 and so the best one I have here, so I’ve been working on performance of Drupal 8.
Dries Buytaert: Awesome, thanks for the introductions everybody. Like Wim, I’m from Belgium but I’m dialing in from Boston today. I don’t know if you can tell from the accent though, but both Wim and I, we speak Dutch as our native language. We really want to make this webinar as useful as possible for all of you, so please do post questions in the chat. There is a couple of questions that we received in advance from our partners, so we’ll go through a couple of these first, but before we go there I just wanted to reiterate the fact that a couple of weeks ago, two weeks ago, we announced what we call Drupal 8 all in, as an initiative, as Acquia.
Effectively, what we announced is that we are now ready to fully support customers on Drupal 8. What that means is that our team, from our professional services, to our support, to our engineering teams, and our services that they are ready for Drupal 8, and that we are signing up customers today to start building Drupal 8 websites effective immediately. The reason we did that is because the number of release blockers is getting closer and closer to zero. There’s about 11 or about 10 left today, so not that many left. Also the beta-to-beta upgrade path is almost supported in core, so these factors along with the fact that we have an amazing team of Drupal 8 experts, some of which are on the call here, that combination of expertise with the readiness or close to readiness of Drupal 8 itself gave us the confidence that we can start making customers successful today.
If you have any potential customers or if you want to work together on making customers successful on Drupal 8, we would obviously love to work with you on that. In the process of working with customers and partners on Drupal 8 projects, we have decided that we will try to give back as much as we can to the Drupal community. We’re going to port modules, we’re going to help improve Drupal 8, tweak the performance of Drupal 8, all of these things in the process. It’s actually a very healthy thing for our ecosystem to start onboarding customers on Drupal 8 today. It doesn’t mean we have to launch their websites on Drupal 8 but we can start building these websites on Drupal 8 today, so that they’re ready to be launched the day that Drupal 8 is supported in production. We’ve been encouraging people to start new builds now of Drupal 8, especially new sites built ahead of the actual release of Drupal 8.0.0. Again, as Acquia, we’re committed to making our customers successful, our joint customers successful, and to do whatever it takes to guarantee that success. All right, with that we should probably jump into the questions.
Angie Byron: Yes, I just wanted to talk a little bit about what’s new in Drupal 8. Just to orient people about things like that. For end-users and site builders, we’ve added a lot of great new functionality in Drupal 8. For example, we focused a lot on the authoring experience. You’ll see things like a WYSIWYG editor configured out of the box in-place editing, so you’re able to go on to the front-end of your site if you see a typo or similar, you could just quickly click into there, fix the problem, and hit save, and you’re done. We’ve also re-envisioned some of the admin interface. It’s like a nice, shiny refresh of the old game that was in Drupal 7. We’ve done some great work on the content authoring page to lay it out a lot more intuitively, so people can get in there and do what they need to do a lot easier.
We’ve also focused a lot on the mobile experience. Everything in Drupal 8 is responsive. We have responsive images, we have responsive toolbar, and we have responsive beams. What that means is that the website itself looks great whether it’s on a large desktop screen, or whether it’s on a tiny phone, or whether it’s on a humongous television. The screen will automatically adjust based on the size of the viewport that’s there. The nice thing too is in Contrib we offer the ability to use previews in order to see what things are going to look like in different devices. We’re hoping to target that for the core later on.
There’s also been enormous focus on multilingual. This is a key focus for sites in Europe, sites in parts of North America as well, where everything that you needed to do to build a site that was multilingual in Drupal 7, and we’ve incorporated all of that functionality into Drupal 8 plus a few other things. Drupal 8 has multilingual in its core, built into every single aspect of the system.
Then finally, there is just more stuff available in Drupal 8 out of the box. We’ve added the views model; we’ve added several of the key data modeling tools such as NID reference and date fields, and those kinds of thing, in order to allow for really robust site builds without having to download a lot of other things.
Alex and Wim, maybe you could talk a little bit more about some of the developer cool things that are happening there?
Alex Bronstein: Sure, I think one of the very exciting things is the configuration management. I mentioned earlier that I got excited on Drupal back in 2005 when I saw how flexible it was and one of those multi-flexibility was just how so much it’s configurable. I think a lot more is configurable has been even before Drupal 8, configurable in Drupal than a lot of other CMS’s that are out there, maybe than any other CMS’s that’s out there.
Before Drupal 8, there’s been a challenge with how to manage all of that configuration and I think Drupal 8 solved that problem really well, where the configuration can all be exported into files, managed, and then reimported from them, which means that it can be managed than a version controlled system, deployed across environments and it has built-in dependency management and language translations, so anything that’s a translatable string within configuration can be translated just with core alone.
Then there’s API support for other popular things like features and varying configuration by domain Contrib modules that existed in Drupal 7 but that were actually very hard to maintain in Drupal 7, and had various integration difficulties to no fault of their own but just through the lack of core API support for them doing the things that they did. But now with Drupal 8, those kinds of Contrib modules can be cleanly maintained and integrated with the rest of the Contrib space.
In addition to that, there’s been a lot of discussion on how Drupal 8 has moved all of its programming paradigm, object-oriented programming, and that has many places where that’s been done from routing, to services, and Dependency Injection and lots of other things. Then two places in particular that I think are very Drupaly and in many ways are the foundation of the Drupal code is the NAT API and the +1 API which just through those two APIs alone a lot of disparate APIs became unified. Paraphrasing a quote from that someone else, I think gave out a DrupalCon presentation, “You can learn once and then apply everywhere.” There’s a little bit more learning curve or maybe even a lot more learning curve to learn some of these foundational APIs but for a little bit more learning curve, you get a huge amount of payoff because once you learn some of these foundational APIs they’re repeated the same way in lots of phases.
Just one example of where the power of that comes in is for doing web services, have less Drupal, decoupled Drupal. Drupal core includes REST module which gives you a way to make use REST to get to both read and write entities into Drupal without the Drupal front-end.
In addition to that, the API support, the Unified Entity API means that the Contrib module that also do decoupled Drupal type stuff whether it’s the services module, or SWF, or GraphQL, or whatever the new hot technology is going to be in a year. It can all leverage this Entity API to just do what they need, as opposed to Drupal 7 where there are a lot of challenges with services modules just having to do custom stuff depending on which entity type it was working with, and then Wim.
Wim Leers: Yes, as I mentioned I spent quite a lot of time working on performance and cacheability. One of the very interesting things in Drupal 8 is that when we are caching something, so basically caching something is you get some inputs, you calculate something in that storage so you don’t have to recalculate it again. What we are doing in Drupal 8 is we are tracking the things that it depended upon and that allows us to much better know when those things change. That in turn allows us to handle highly dynamic websites much more easily because tracking those cache dependencies, and that’s what we call, “cacheability metadata.” It’s a bit of metadata for everything that is ending up being cached. That metadata allows us to figure out automatically which parts of a page are highly dynamic, which parts do not change quite as often, and so on. That allows for very interesting and as far as I have seen and know about, I’ve not seen in any other CMS or even framework because what we can do is we can still have the very dynamic and flexible pluggable nature of what is Drupal, as in you can download and install a whole bunch of module that provide additional functionality, and still have cacheability, as in still be able to cache the parts of the page that do not change. This really brings us to a point where Drupal can provide performance and performance features that only so far Facebook, and Google, and so on have been able to provide. For example, BigPipe style delivery of dynamic things on a page, ESI as I’m sure you know, but in any case, this additional metadata is going to allow for very interesting new possibilities in terms of caching and therefore also performance.
Angie Byron: Great, now we’re ready to get started with the Drupal 8 open Q & A. As a reminder, please submit your questions at any time throughout the webinar in the Q & A box. We will be answering the questions on a first come first served basis and we will begin with the pre-submitted questions. Just as a reminder again, if you have any additional questions, please reach out to your Channel Manager or email partners at acquia.com.
What Drupal 8 features are Dries, Angie, Wim, and Alex most excited about? What are each of you most looking forward to with Drupal 8?
Dries Buytaert: Alright, awesome. The first question is actually a fun one I think, so that’s why we actually picked that. The question is, “What Drupal 8 features are Dries, Angie, Wim, and Alex most excited about? What are each of you most looking forward to with Drupal 8?” I’ll go last here, but I don’t know Angie, you want to kick it off?
Angie Byron: Yes, sure. Something I’m really excited about is just how more fully featured Drupal 8 is out of the box, because in Drupal 7, if you downloaded Drupal 7 and you downloaded it next to something like WordPress or really anything, you would look at this thing and be like, “What is that?” Then you would immediately discard it and you go use the much better looking thing and then you would come back four years later when you finally hit a problem that you couldn’t solve and then you’d fall in love with Drupal. I’m hoping that by having all these new functionality within Drupal 8 as well as the focus on polishing the operating experience that we can hold our own side by side next to competitors a lot better.
Something else I’m really excited about is the fact that we have what’s called Semantic Versioning in Drupal 8. We’re doing not just Drupal 8 ships in whenever it ships in and it stays the same forever but at every six months we’re able to introduce new features. What I’m hoping is that flexibility is going to give us the ability to continually improve the default authoring experience, some of the functionality that comes in core and that’s going to be really great for Drupal’s adoption and for Drupal site builders.
Wim Leers: Wim talking here. I just talked a bit about cacheability and performance and so actually that is also what I am very excited about, the potential that I already mentioned of using that cacheability metadata and using it in specific use cases. One that is really interesting is at the DrupalCon LA I did a presentation about all of this and afterwards the Drupal Commerce lead developer came to me and told me he was very excited about the potential because he told me that the features that are in Drupal 8 with regards to cacheability will allow Drupal Commerce to be the first commerce system that he knows of in any language in the world to be able to cache the entire page properly and maybe some parts that are dynamic cache them separately, but in any case make sure that the shopping cart is not the thing that flows on every single page load. That’s going to be pretty interesting to see that hopefully Drupal 8 build commerce sites, in general will be significantly faster than those built with anything else. That would be very interesting and it shows a one very cool possibility.
Related to that, because all this cacheability stuff sounds maybe vague or abstract at the very least, well related to that, there is also a prototype so far that we’re going to develop further that is called “Renderviz,” short for render visualization, that is going to visualize for every single thing you see on the page, how cacheable it is, what went wrong. That allows you to, by looking at a page, truly understand what is causing a page to be slower, what is causing a page to be changing very often, and so on. Basically, for the first time ever you will be able to just look at any page and truly understand where every single bit is coming from and why it is slow or fast.
Alex Bronstein: Yes, those are all awesome things. For me, there’s so much to be excited about but for me it’s really about going back to the fundamentals. Again, since I started the Drupal development I really feel the things that really makes Drupal stand out is fields, entities, and views. Those three things working together to basically where you can make, you can model your site’s content in extremely flexible ways while keeping it very structured. That’s been true even before Drupal 8. What I think Drupal 8 has done that’s really exciting is really let those things shine. Things like making every field a field, so meaning like the no title is also a field, and the same way that the no body is. Through that we brought in a lot of the basic field types into Drupal core whether identity reference, and page and also all of, every field on every entity is translatable, and also WYSIWYG editable both for long text you can use WYSIWYG like a chief editor, and then also there’s the quick editor in-place editing functionality. Then with views by bringing it into core, making it so that every administrative listing in Drupal is also administering users, administering content so that’s the view - I really think there’s all of these great tools, I think the ecosystem will be able to sort of take the fields, entities, and views which have always been Drupal’s real number one selling point and it’s just, all of those things have just gotten so much better for Drupal 8.
Dries Buytaert: Awesome, thank you Alex. You guys all cheat us and mentioned several things versus the one thing that excites you the most.
Angie Byron: Drupal 8 is just so exciting though, so how can we stop at just one?
Dries Buytaert: Well so I’m totally going to do the same because it’s really hard to pick one thing. There are literally hundreds of improvements that I’ve been thinking a lot about the future of the web lately and I’ve written about it and spoken about it. It’s what I call, “The Big Reverse of the Web.” There’s actually a webinar that I did I think two weeks ago which is online, if you want to listen. It’s this vision that the web is going through some pretty big architectural changes where a lot of the experiences are evolving from pull-based experiences to push-based experience. What I mean by that is that information increasingly will find you versus you having to find the information. I won’t go into the details here but to fulfill that vision and to act that kind of functionality to existing websites, a lot of pieces actually have to come together, and a lot of these pieces are in Drupal 8. From improvements through the content modeling, fields and entities, like Alex mentioned, and structured content to things like web services, to evolving the patron remodel, and how we rebuild pages, and how we cache pages, and BigPipe like things. The things that we’ve just talked about to mobile support and improving the out-of-the-box experience for authors, all these things combined I feel is what gets me excited about Drupal 8 and I think what positions Drupal 8 to be in a great position for the future of the web, whatever way we will go. I think that’s my answer.
Can you speak to the competitive advantage of the administrative experience? Is this leapfrogging to put our competitors to shame in that department?
Angie Byron: Okay, great. The next pre-submitted question we got was, “The number one pushback we received historically with Drupal is that the admin content author experience is not as easy and elegant as it is with other CMS options such as, for instance, Sitecore. Can you speak to the competitive advantage of the administrative experience? Is this leapfrogging to put our competitors to shame in that department?”
Yes, this is a great question. I can start answering this and then others can chime in. One of the things that we at Acquia did and was my role for a while was we launched an initiative called, “Spark.” The idea behind Spark was to go and do competitive research, look at not just our open source competitors such as WordPress but also our proprietary competitors such as CQ5 and Sitecore and things like that. Then from there we created these artifacts like a spider diagram showing that we were very, very strong on technical flexibility, like we wipe the floor with everyone else on technical flexibility, but we do suffer on a lot of the other things that people, like more of the authoring experience people think are important. We’re finding more and more that say, the people who will actually use the site, AKA, “the victims of the site,” just kidding, but those people are the ones who are actually involved a lot more in the choosing of the CMS, which makes complete sense because it’s going to be their job day in and day out to do that.
In that analysis what we chose to focus on there were some of the key capabilities that people expect to be there out of the box, like WYSIWYG and previews that work in this kind of stuff. We also tried to look at areas where there weren’t checkboxes to check on Drupal side, either through core or Contrib. We focused on things like in-place editing because that wasn’t something we had a really great solution for out in the community, at least one that with holistic and worked on nodes and entity, and blocks, and all kinds of stuff. That’s really where we dumped our focus. In favor of letting Contrib continue to do what Contrib does well in spaces like workflow and media and things like that.
In Drupal 8, what I’m hoping is that, as I mentioned in my previous answer about in subsequent versions of 8.1, 8.2, we would be doing things like moving panels into core, or some subset of layout tools into core. We would be moving media handling into core and continuing to evolve the product so that it became even more competitive with what our competitors are offering.
What we’re going to do once Drupal 8 is out is basically continue that trend of revisiting, restudying our competitors, coming up with the next big list that we need to work on and then we’ll be hopefully knocking those off as fast as we can working with the community on making Drupal better.
What do you think the release means for our growth as an organization and how would you recommend we capitalize on that opportunity?
Dries Buytaert: Awesome, I’ll take the next question. The question is, “As a leading Drupal agency, we are naturally very excited about Drupal 8. What do you think the release means for our growth as an organization and how would you recommend we capitalize on that opportunity?”
I think it’s a good question. I’m not sure I have the best answer here possible but traditionally what we’ve seen is with every major release of Drupal, so from Drupal 6 to Drupal 7, or from Drupal 7 hopefully to Drupal 8, but also from five to six, we’ve seen a very large jump in adoption of Drupal and penetration in the market. Historically, it has roughly doubled with every major release of Drupal. What that means, if that same trend continues, which we believe it will with Drupal 8, what that means is that in the next few years we’ll see hundreds of thousands of new Drupal websites come online, growing the market share of Drupal. Obviously, these websites need to be built and so that provides a great opportunity, I believe for Drupal agencies.
The question is, “How do you capture that opportunity?” I think with Drupal 8 being this close to being released and Acquia pushing Drupal 8 as well, I think it’s important that all of you, all of the agencies become experts on Drupal 8 pretty soon and that you can help your customers be successful with Drupal 8. There’s going to be a lot more business out there as soon Drupal 8 goes mainstream, so to speak. In helping early customers with Drupal 8 - I think that’s how you get your agency ready for Drupal 8 in the process, or even in absence of customers on Drupal 8 you can help port modules and become an expert on Drupal 8 and help unlock the opportunity of Drupal 8. We’ve had many of our teams help with porting modules and it’s actually interesting, the feedback that I got from them because some of them were actually experts on these modules that they ported but that never ported it and so in porting it, they say, “Wow, I thought I knew how this module works by actually going through all the code and porting the module from seven to eight, now I truly understand how some of these things work.” Porting modules is a great opportunity to build expertise with Drupal 8 but also to help advance Drupal 8 and the entire ecosystem around Drupal 8. Short version is there’s a big opportunity for all of us with Drupal 8, all right.
Are there scenarios where you would recommend Drupal 8 to a client new to Drupal using another CMS platform?
Angie Byron: Cool, the next question I have here is, “Are there scenarios where you would recommend Drupal 8 to a client new to Drupal using another CMS platform?” Yes, I would definitely say yes. Sort of the loose rubric that we’re using here at Acquia is, this isn’t necessarily leading to a “Yes, absolutely” answer. Obviously, every customer build is different and has different constraints and stuff so it rivets us a case by case basis.
In general, what we look at is, “Do they have a launch date in Q4 2015 or later? Are they generally sticking to new module…” Sorry. “Are they generally sticking to either core modules or are they sticking to modules that everyone else is going to be using realistically, so anything in the top 30, say, if it’s stuff that you know is going to get ported regardless because everyone’s going to need it?” Those are pretty safe bets as well. Then you can help port them yourself if they’re not ready yet.
The other thing that we look at is, if it’s a new site build versus an existing site build. In theory, we have migration paths and core available from moving from Drupal 6 to 8. They’ve been tested but only by a handful of people so far but seven to eight is still in process. I guess for new customers that wouldn’t really matter but I mentioned it because a lot of people have existing sites they want to bring into Drupal. Drupal 8 does have a migration API. The migrate Drupal modules are essentially built into core, so that’s helpful for pulling information out of other CMS systems but you have to sort of weigh it on a case by case basis. It’s definitely much easier to do a project that is brand new, fresh from the ground up, and not trying to pull in content from elsewhere. I would say another couple of areas that Drupal 8 really shines in is highly dynamic websites. Once I’m done talking or maybe see the floor to Wim to talk a little bit more about what the kinds of caching stuff that’s in Drupal 8 allow for and then I’d say also for organizations that are comfortable with object-oriented code is another big selling point. They wouldn’t have to unlearn what they know to learn the Drupal 7 way, only to relearn what they knew before to eventually migrate to Drupal 8 or Drupal 9, so that’s my take on it. I don’t know Wim, did you what to touch a little bit on some of the caching improvements and how those would help for certain types of sites?
Wim Leers: Sure, yes it really depends on what kind of site you have, in what way you will be able to use it. In any case, regardless of the website, unless it’s completely static, which likely is not if you're using Drupal, you are going to be able to really choose which part. Basically you can choose to either let Drupal figure out most things for itself because given all that cacheability metadata that I mentioned, Drupal is able to determine automatically which things are going to make your pages slower because it causes Drupal to no longer be able to cache a certain page. Beyond that, every site is different. In Drupal 8, you are able to configure which things for your particular website are considered very expensive because many variations exist. For example, if you have something that is personalized to a specific user, it probably does more but not to mention it just lists that user’s private messages, or bookmarks, or favorites, or whatever it is. If your site has tens of thousands of users then probably you don’t want that to end of being cached along with the rest of the page because that means you have 10,000 variations of that page. In that case, you really want the overall page to be shared across all those 10,000 users and just cache, or maybe not even cache the individual thing that is per user that lists the bookmarks or favorites or whatever it is and just serve that separately.
Drupal 8 makes that tremendously easy. Whereas in Drupal 7, you would have to write quite a bit of code and you would have start untangling and understanding every single Contrib module. The difference is that in Drupal 8, Contrib modules already provide that cacheability metadata. You don’t have to spend time unraveling how actually it was built, where it’s getting its data from, to determine if you can actually safely cache it without causing bugs or security problems potentially.
It really depends on your sites whether it makes sense to cache the entire page per user, or to cache individual things. Drupal 8 gives you the tuning up to choose how to cache because maybe your site has not 10,000 users but only 50 because whatever audience that it is designed for. Drupal 8 is giving you many tools and is forcing Contrib to think about cacheability, which you never really have. The combination of those things is going to make for a much more pleasant experience in making your sites faster, as in caching specific parts that are otherwise expensive to generate because they're so dynamic.
Angie Byron: When would you basically say that, like if a customer is coming in who needed a site with a massive amount of content, or a massive amount of users, or something like that that Drupal 8 maybe a better choice for them than Drupal 7?
Wim Leers: Yes, I probably didn’t make that clear enough. In Drupal 8 we have the potential, we have the tools, and it is already in core for some parts. It is currently RTBC, so ready to be committed into Drupal 8 right now to basically cache things even for authenticated users. As in the entire page minus the parts that are too dynamic for every user which means that instead of having to generate every single thing dynamically for every user which was usually the strategy for very dynamic thing to Drupal 7.
In Drupal 8, what will become the default strategy is to actually cache across users because we have that metadata. Instead of seeing page slow times or page generation time that are in the hundreds of milliseconds, it will be in the tenths of milliseconds or lower even. Only the dynamic bits need to be calculated still. What you will basically see is a constant amount of time per page load plus only a small bit that is still dynamic and that is there for not constant time. Across the board, usually you will see constant time page loads except for the dynamic bits. Yes, definitely the more complex your sites are, the more you will benefit from the caching improvements in Drupal 8.
What are the customer benefits of redeveloping scenes over Twig?
Alex Bronstein: Great, this is Alex speaking. I’ll take the next question which was, “What are the customer benefits of redeveloping scenes over Twig?” A little background to that is every version Drupal Core shifts with the templating engine that core uses. In Drupal 7 and before that was PHPTemplate, and in Drupal 8 the one that core uses is Twig. I think 99.9% of sites, it just makes sense to use the same templating engine that core uses. It only makes sense to use a Contrib templating engine if you have a really specialized need to use the templating language that’s different from the default but that’s a very extreme minority.
In Drupal 7 before if you were doing templating, you were doing using PHP, and in Drupal 8 it’s going to be Twig. Again if you're in the 99.9% case, it just makes sense to use Twig if you're using Drupal 8. In terms of what the benefit of that is and some of the things to look forward to, one really great one is that Twig is a much friendlier language to onboard the diners too than PHP just because Twig doesn’t have to do that much, that’s the whole point. PHP is a very full featured language. Twig has a much more limited scope of what it’s trying to do. It’s just basically helping you press variables, have basic for loops and if loops, and not really a whole lot more than that.
The syntax of it is very lightweight and it’s not intimidating for designers to learn and it’s also a lot less verbose which means when you're looking at a template, what you're actually looking at is mostly HTML, and the dynamic pieces where you're printing variables is short and easy to understand, and not cluttering the screen the way in PHPTemplate the actual verbosity of PHP does. What that allows for is a more effective team functioning for it doesn’t have what you can have like a designer, and a front-end developer, and a back-end developer deciding how they’re going to share the work of working on the templates because the language is very easy to pick up and navigate for anyone on the team.
Another benefit that’s huge is security. One of the downsides with PHPTemplate is because you have all the PHP available to you; it’s very easy to do things that would lead to security problems. Anything from running database queries in your template, to just printing out variables that haven’t been filtered for XFS because in PHP sometimes raw variables are provided, because there might be used cases for needing to do some logic based on a raw variable. Since its PHP, once it’s raw, then if there’s a print statement of that variable that’s potentially a gateway to an XFS attack which is a really bad security vulnerability.
Twig just removes all of that because it doesn’t likely you invoke database queries and everything that’s printed out is properly filtered or escaped and just basically by default, there’s no XFS hole as long as you're using Twig. Then a potentially experimental thing, that’s like a long range thinking kind of thing that maybe in the future it will be possible to do some client side template rendering. Taking the Twig template back out prior but you’ve done working for your site and be able to render them in a JavaScript if you're doing some decoupled frontend.
Like I said, having a language like Twig that has a PHP implementation of rendering as well as the JavaScript implementation which Twig has. By having this lightweight neutral language that different languages can actually render is one step to lay back. There’s other steps which why I said this is more like a long term future proofing content that necessarily something you can do today.
When you look at Adobe CQ5 as well Sitecore, how does Drupal 8 differentiate?
Dries Buytaert: Awesome. There are a lot of people that I speak to like Twig in the Designer theme or community are very excited about what we’ve done with Twig since some of the other work around theming and cleanups of HTML and stuff like that. I’ll take the next question. I guess it’s more of a sales question. I’ll try to do that. The question is, “When you look at Adobe CQ5 as well Sitecore, how does Drupal 8 differentiate basically?” It’s a complex question because when we do and deal against Sitecore and CQ5 which we have great win rates against them. There’s not necessarily like one reason. It’s always like a combination of different things. There’s not a straight answer here but I think as it relates to Drupal 8, there’s definitely some feature differences, some feature advantages. Many of the things we’ve talked about in this call like the stuff that Wim has been working on around cacheability and big byte. I believe that we’re the only CMS platform in the world. Definitely now CQ5 and Sitecore that has embraced this new page rendering model which is a pretty big deal in terms of scaling dynamic websites. Other strengths I believe are things like multi-user. If you just think about drupal.org, for example, we have over 1 million user I guess. I don’t think most of our competitors have that ability to scale to that large number of users and the kind of management functionality that runs a possibility for one of the best for multi-lingual.
There’s a long list of things that I think we're better at. Obviously there are things that we’re less good at as our competitors and we’re working hard on fixing those, like generally feasibility has been one of those that we’ve invested a lot in making a better step. We’re very optimistic that Drupal 8 will help close that gap. That to step back at a higher level, one key other differentiator not specific to Drupal 8 but what strengthened our position with Drupal 8 is our content modeling tool. A lot of our competitors, they're still very page-centric, which is an outdated model to be honest. Drupal has never been page-centric. It’s always been focused on notes and entities and these kinds of abstract content types and really focused on content reuse and these things, which is the reason why we often win. But outside of beta, it’s actually maybe not features and functionality. It’s the fact that Drupal is Open Source and a lot of great things come from that. It provides them the flexibility that they're looking for. A lot of these organizations, customers they want creative freedom, whether it’s related to design or how to develop the site. They want that flexibility to build what they want to build, to build what they're dreaming of if you will, and not be limited by the functionality provided by the CMS. Another element of Open Source is obviously - Open Source is a license but it’s more than a license when you build a community around your Open Source project. It’s really a community of people, a community of organizations that are innovating on top of the Drupal-based platform. The amount of innovation that comes out of the Drupal community which you can measure say in terms of modules we have almost 25,000 modules now. That innovation is really valuable to a lot of users and customers because it gives them speed to markets. You don’t have to build a lot of this functionality. They can just download the module and enable it and so license to build websites and launch website is much faster than they can do say with Sitecore or Adobe CQ5, so that is key.
Related to that is because the flexibility and the innovation, Drupal just makes for a better integration platform. Like often, almost every large websites and even small website they want to integrate Drupal with other technology, marketing technologies, whether it’s single finance system, whether it’s CRM system that they want to hook up into Drupal, whether it’s marketing and innovation tools, whether it’s Legacy, custom backup systems, whatever it is that they do. Most websites have integration to different systems and many websites have many integration. Open Source just makes that much easier, much better especially even after – there’s usually modules to start from. One of the reasons why we went and I think Drupal 8 will only strengthen that. The architectural changes, the usability changes, I think Drupal 8 will make a big step forward in the industry. So to keep moving, I think there’s more questions.
Moderator: I think Wim is up next.
Regarding the new Rapid Release Cycle where every six months new features can be released and so on with Drupal 8 and later versions, seeing how many Contrib modules in Drupal 7 are still in development or beta release, should we be a little afraid of losing many really good Contrib modules because developers will be unable to keep up with the Rapid Release phase?
Wim Leers: Yes, Cristina asked an interesting question as well. The question was, “Regarding the new Rapid Release Cycle where every six months new features can be released and so on with Drupal 8 and later versions, seeing how many Contrib modules in Drupal 7 are still in development or beta release, should we be a little afraid of losing many really good Contrib modules because developers will be unable to keep up with the Rapid Release phase? I remember from Joomla, I experienced that it happened despite many Joomla components being sold commercially and thus offering a financial incentive to developers as well. How do you think this will play out in Drupal?” That’s a good question because of course Drupal 8 is the first version to adopt semantic version and to have this model where a minor version can have new things. I would first say semantic versioning is very widely adopted at this point. Drupal 8 is almost late to the game if you will. Many projects are doing this including many what you could call “mission critical projects,” as in projects that other companies are building big things upon.
Part of your concerns can actually be answered by or part the concern, I’m sure you're not the only one with this, part of that can be answered by looking at other projects because they have faced similar concerns and similar problems and things has been going very well there. That’s all for the reason we adopt the semantic versioning at all. Maybe Dries can talk about it later a bit more because this was definitely put under a lot of scrutiny as in we didn’t just flip a switch and decide to do this. We spend a lot of time weighing the pros and cons.
Another part of the answer is understanding semantic versioning better. The question already mentioned the fact of our featured editions and I want to stress that, it’s definitely mostly about feature editions and so that means adding modules, and polishing UI. It’s really the major releases only. The next time will be Drupal 9, that is really BC breaking, backwards compatibility breaking. In principle, there are not going to be any BC API breaks. As in everything will continue to work just fine, moving from 8.0 to 8.1 to 8.2. If there are going to be BC breaks, backwards compatibility breaks then they're going to be very minor ones. With as much of a backwards compatibility layer as possible and probably they're only going to be accepted even if they only affect a very small number of module. We are able to look at the modules on drupal.org to determine what the impact of a third API change would be and if only one module ever implemented a specific thing, well then the impact is very low and the cost to the community, the ecosystem is very low, so we could choose to do so then.
Generally speaking, we will at least be very, very careful if we do any BC breaks at all. That is mostly about semantic versioning which is the key part of the question but at the end it was also asking how you think this will play out in Drupal. I personally think that in Drupal 7 and prior versions but maybe especially in Drupal 7, we saw a lot of competition between different modules doing similar things because of the lack of patterns. Some patterns simply were not in Drupal Core. A good example would be the fact that we don’t have a plug in API in Drupal 7 and so the CTools module which you may know provided a plugin API but not every single module wanted to depend on that. Some modules depend on CTools and provide one solution to a problem and other module solves the same problem but in a different way and not using CTools. That’s just a general example but the point is due to a lack of certain patterns that were actually needed, there has been more computation and does also more duplication and Drupal 8 solved that because it does have those pattern because we learned from the things that were missing or perceive as missing in Drupal 7 and so that should significantly encourage less duplication and more collaboration. I think a tiny portion of the things that are still in test development or beta release for Drupal 7 are the modules that are frustrated but then the people working on them are frustrated, or it’s just so much work to get it all working precisely because there is a bunch of duplication going on, so I think that should help significantly…
Angie Byron: To take on what Wim just said to is, I’ve been reaching out over the past couple of weeks to various Contrib module authors that are in the top 20 and 30 to find out what they're doing and what they're working on and stuff. A major version switch like Drupal 7 or Drupal 8 presents a really great opportunity for consolidation of competing efforts. There’s a lot of, the maintainers out there right now that are talking to each other and trying to figure out how they can combine efforts and make sure that they only have to support one module with Drupal 8 instead of two modules to Drupal 8. What you’ll see overall is a consolidation of effort on making Drupal 8 modules ready and that’s been really positive to see as well.
Wim Leers: Awesome, we’re almost out of time but I think there’s room for one more question. There’s one question which I think we have to take which is, “When will Drupal 8 be released?” There’s a lot of other sub-questions to that. I’ll read them to you real quick, or rather it says, “The release date is September 8. Much are very excited by the way, should we order Champagne yet? Also I wanted to ask if he, I guess Dries, remembers when Acquia started to really sell Drupal 7 compared to its released date?” Then it says, “We started to use it in proper live projects seven months after the release. How big is the warm up with Drupal 8?” A bunch of questions. The truth is as always, Drupal 8 will be released when it’s ready. We’re working through the critical bugs. I believe there’s 11 critical bugs left; we’re fixing a good bunch of those every week. At the same time there’s also incoming critical bugs; new things that people discover as they import their modules or start to build websites in Drupal 8, really hard to predict when that number stabilizes at or runs zero. We do estimate it. If I were to estimate it, I would say our goal is once we get a release candidate ready by DrupalCon Barcelona and hopefully our release shortly after that. Maybe the middle of November timeframe if I were to forecast something but don’t hold me to these dates but that’s what I would say. I don’t know how long it takes for champagne to arrive but it can work backwards from those dates I guess, when you should order your champagne.
In terms of the warm up period, it is true that with Drupal 7, even when Drupal 7 Core was released, it wasn’t ready for large projects that needed a lot of contributed modules because these contributed modules needed to be ported from six to seven. In the case of Drupal 7 that took a very long time. The reason it took a very long time in part is because the Views module decided to, once Drupal 7 was released, they decided to basically re-architect Views to leverage some of the new APIs in Drupal 7 and that port took a long time. As a result, a lot of other modules which were dependent on Views or had Views integration, they were also stalled and so it took over a year or maybe 18 months before Drupal 7 was truly ready in terms of availability of a lot of contributed modules.
We think it’s going to be different this time with Drupal 8 because one of the things we’ve done is we’ve incorporated a lot of key modules, contributed modules. We’ve moved to core including the Views modules, so I think it will be a lot better. Having said that, there’s still a lot of modules that people will use but Drupal 8 out of the box and Angie talks about this as well, Drupal 8 out of the box will be much more capable than Drupal 7 out of the box. It will also be much more stable and tested than Drupal 7 out of the box. In terms of QA, we’ve also are much more thorough in release management process.
Having said all that, for complex websites, there’s obviously going to be dependencies on contribute modules and we’ll have to upgrade these modules. We’re organizing a variety of different efforts to help upgrade these modules from Sprints to other things that we’re hopefully announcing soon. One lesson learned is that maybe it isn’t the best to completely re-factor a module after Drupal 8 is released. Maybe it’s better for the ecosystem as a whole to do more of a straight port and minimize refactoring and then to do refactoring overtime.
I’m just showing that as something to think about and the right answer may differ from module to module but definitely one lesson learned from Drupal 7 is that is to be thoughtful about when we do these liquifactorings. Great question, maybe a long winded answer but it hopefully gives you a little bit of guidance on how to think about the readiness and release date of Drupal 8.
Moderator: Great, thank you so much to Dries, Angie, Alex, and Wim. Some of your questions are being answered in the Q&A and chat box as we speak. For any of those that weren’t answered, we will follow-up and send out those answers when we send out the recording of the webinar. We will not leave any of your questions unanswered. Thank you all so much for attending and this concludes the webinar.
Real-time Question within the Webinar:
Drupal already has a pretty substantial barrier to entry for devs. Do you expect this to increase with the release of Drupal 8?
Angie Byron: The answer is ""it depends". Devs who learned PHP via Drupal 7 and below will definitely have new concepts to learn. But developers who learned literally any other language or PHP from version 5+ should actually find Drupal 8 *easier* to approach.
