much more functionality was incorporated into the core
Yes. Drupal was the first open source CMS to hire a top usability team to do testing on Drupal 7 and many people in the community were shocked. It was unusable. A major goal of Drupal 8 was to make it functional and easy to use out of the box. For many years, Wordpress had an ease of use that blew Drupal away. Drupal 8 was intended to take what Wordpress was doing right and do it better to make it easier for the beginning content editor.
Traditionally, anything dealing with images was ridiculously hard in Drupal compared to Wordpress. Drupal 8 ships with a
WYSIWYG editor and at least based on the last releases I tested, also included in place editing (i.e. you can edit right on the page without going into an editor) and
media handling reminiscent of Wordpress.
Other big elements that ship with Drupal 8 out of the box
-
mobile-first, responsive default theme front and back
- complete
i18n compliance - everything front to back is translatable. It will be one of the most powerful multi-lingual platforms out there
-
Views in core - Views has traditionally been a killer feature of Drupal, but it was an add-in module. Now it's in core.
-
configuration management - if you think of Wordpress or earlier versions of Drupal, configuration all lives in the database. This makes it super hard for developers to add features while editors add content. With Drupal 8, content and configuration are fully separate. This is a huge pain point with Drupal 7 (traditionally people use the Features module, but it has issues) or Wordpress and one of the most anticipated changes.
On the flip side, though, there is a certain
decoupling of the front and back ends. It is expected that many Drupal sites will not use Drupal at all for output. In other words, Drupal will be a content
managementsystem, but not a content
displaysystem in many implementations. This, by the way, is how the New York Times custom CMS works - it only handles managment, not display.
So, for example, Drupal might output pages to Twig templates that transform those into HTML when sending to a browser over HTTP. However, people might choose to have Drupal output data as JSON and that gets processed and output by a native app on mobile. A common alternative so far seems to be to use Angular JS to build a lightweight front end.
In short, there is a lot more in core than before, but it is also set up to be decoupled more easily to use less of core.
infinity sign, representing the new learning curve
This is a controversial subject. From an end-user perspective, the learning curve will probably be flatter than Drupal 7. From a developer perspective, it depends on who you are
- if you are a traditional drupal user who is self-taught and looking to move to Drupal 8, you are almost starting from scratch and you will have to up your game and learn about PSR0, Symfony, Twig and all sorts of other things. It will be daunting.
- if you are a professional programmer used to professional best practices for PHP and JS and especially if you are already developing with Symfony (which is a huge dev community), you will find it easier to get started in Drupal because it will be less idiomatic. There will be more standard practices and fewer Drupalisms.
The controversy is that a lot of people feel that though this opens Drupal to a huge community of professional programmers, it leaves the vast majority of the traditional Drupal community behind. To address this, one group has forked Drupal 7 into Backdrop and plans to develop along the traditional Drupal lines.
What are your general thoughts about how this will roll out?
I think it's a make or break moment and many questions remain. Will it be an XP or a Vista? Remains to be seen.
My gut belief is that a large number of hobbyists will jump ship and Drupal will become more of an enterprise app. There are concerns right now about performance and many people assert that Drupal 8 will not run well on cheap shared hosting (and some would assert that Drupal 7 already doesn't). I think it's already becoming hard to develop on Drupal as a one-person shop. Drupal teams now commonly have designers, front end devs, back end devs, dev ops and some type of IA/content strategy specialist.
Pro Drupal shops already have it so that their sites have automated nightly builds that spin up the current
server config (not just the site, but the whole stack) and run the automated test suite (the Drupal.org site has, for quite some time, run the automated test suite every time a .patch file is uploaded to a discussion thread). This is already way different than not only Wordpress or Joomla, but I don't even see this in the Sitecore world even though those builds are hugely expensive.
Personally, I have a client who was told they need a Drupal site for their project. In fact, I think the lifecycle costs will be much too high for them and they will struggle given their resources to keep the site on its feet long term given where Drupal is going.
I think all their needs can be met with Weebly at a fraction the cost and hassle.
I am *guessing* that when we look back at this rollout some years from now, we'll see 2015 as the highwater mark for the number of sites hosted on Drupal, but that the number of large, high-profile sites hosted on Drupal will continue to increase and it will be more of an enterprise system.
That said, the out of the box experience is such that if the performance issues are improved and it can run on cheap hosting, it will be a great option for people who don't give a damn about PSR0 and Angular JS and just want a simple site they can go in and edit. I don't think that's the direction of Drupal though.
