Content types and Taxonomies, being the main structural features are very much the same. As you would expect, they are both fieldable (i.e.; you can add any number of different field types, such as file uploads, text fields, references etc) and some contributed modules we regularly use have also made it into core; namely “email”, “entity reference”, “term reference” and “date”. The options when creating fields, are pretty much unchanged, though some minor interface cleansing has taken place.
Views is now in core. This isn’t really a big change to a site builder at all (our default install profile had it in anyway), but it did take a good while for Views to have a stable release in Drupal 7, therefore slowing the adoption rate down. With Views now in core, this should be one major module less to wait for.
The features remain identical, the difference being the location the module sits in the file directory and there being no requirement for the other contrib module “ctools”, the features needed from this module to run the likes of “views” also now sitting in core.
This could be considered a big change and something that many themers may be worrying about. The truth is, yes it’s a change, but it’s not exactly a gigantic leap to something totally alien that will require a month of research to understand. Rather than using php template, themes are now put together using “Twig”. Bar getting used to the new file formats and using Twig placeholders and conditions instead of php ones, there really isn’t anything significant to worry about. Yes, there is an understanding of the the new file extensions and how it all stitches together to give you a working theme, but you had to get your head around that with php template files originally.
What this move does force, is the removal of using php code (other than region placeholders) in template files. This can only be a good thing, leaving template files for html markup only and moving the complex code into “modulename.theme” (replaces template.php). Taking a look inside this file, if you are familiar with running preprocess functions etc in template.php already, things should look very familiar.
As you would expect, html5 and media queries are all part of the package now, which should all help with those day to day site builder tasks.
The more significant changes in Drupal 8 are under the hood. As a site builder, creating a small module to perform “hook_form_alters” and other small features is a regular task. At the moment, this is an unknown for me as to how much things are going to change in terms of how code will be written. This is something we’ll be looking into in more depth with our fully fledged developers.
Other common features
The likes of users and account settings, the file system, regional settings, image styles, url aliases are all present and correct. The “roles” page has thankfully moved from within the “permissions” page, to sit as a tab at it’s side. A minor change, but having to wait for a site with a complex permissions page to load, before being able to click on “roles” link is very frustrating in Drupal 7. Almost worthy of adding a direct link on the shortcut bar!
Text formats and editors
On the matter of text formats - this is as before, though now has the addition of “editors” to the title. CKEditor (which we chose as our wysiwyg editor of choice in Drupal 7 and previous) is now part of core and there is a handy interface for choosing which editor buttons appear on which text formats. This was all possible before, but now that it is in core, it feels much more integrated and more straight forward to set up.
Pasting of text from the likes of Microsoft Word was handled by an option in the CKeditor module to force plain text in the past. It looks like pasting of plain text is baked into CKeditor in core now, although it does include span tags with reference to the source paste from. It would be good to see some cleaner markup being pasted in than this.
More significantly, we have often found in the past there is no great “image within text editor” solution for Drupal. We’ve tried many, from the likes of the functional but somewhat dated looking IMCE, and the more recent but irritatingly awkward media module. From what we can see in Drupal 8, image inserting is looking much better, the baked in insert feature giving you a cleaner UI and the things you would expect, like the alternative text being required and the image alignment using “data-align” attribute, rather than the long gone “align” option. The image width and height options seem a little strange - they don’t detect the actual dimensions of the selected image and they also don’t maintain aspect ratio, making it easy for a user to distort the graphic they have uploaded.
The feature, which forces only use of images stored on the site itself is a nice touch. I would still prefer to see the maximum image dimensions to prompt upload of a smaller file rather than attempt to scale it. This is often a problem for servers that don’t have enough memory available to perform the scaling action, which in Drupal 7, results in an ugly ajax error, rather than a useful message that actually explains what has happened) or at least allow the site builder to choose between these, but maybe there is a contrib module I haven’t spotted yet or that could be something to make?
What about other editors? For Drupal 7 at least, there weren’t (and aren’t) really any close contenders, with TinyMCE not being anywhere close to supporting the version 4 library. It would be nice to see support for this plus any others such as Aloha (the editor originally planned to be used in Drupal 8).
Overlay vs Edit in place (Quick edit)
So it would appear that the overlay module has bitten the dust. This isn’t a surprise considering it was one of the first things we turned off on a standard Drupal 7 install, despite thinking it was a great feature when it first came out.
In it’s place comes the ability to edit in place, with no refresh of the browser required. This all looks really neat and is obviously something that has been focussed heavily on. It’s something we’ve been wanting for a while and are itching to really put it to the test. Only time will tell if it’s a keeper, unlike the overlay module - I’m cautious to say that it will be though.
Despite Drupal 8 packing a lot of features that were contrib in Drupal 7, there are still some modules that we will require before we can build a site with the feature set our current sites have. The likes of “pathauto”, “menu_block” and “webform”, we use on just about every site and will be watching their progress very closely.