Earlier this week, we looked at changes in content editing for nodes and blocks. Today we’ll be looking at the implementation of forms and views modules in the core of Drupal 8 as well as drawing some overall conclusions.

Built-in Contact Form

The ‘Structure’ page contained another item that really caught my attention: Contact form.  My first question was, ‘Why not contact forms? Plural?’.  Every site I’ve ever built needed the webforms module, and the contact form administration pages look very similar.  I submitted an inquiry to the default form, and I didn’t see anywhere on the admin pages to check for that submission.  It may be that this is an email only form, and nothing gets saved to the database.  Functionality continues to depart from what I’d expect when visiting the contact form configuration page.  You have the option to ‘Add category’ for the contact form.  But whereas I’d expect something resembling taxonomy for that, you actually create a new, separate form with unique recipients and/or fields.

Only one of the forms in the list can be ‘selected’ as the site-wide contact form.  Whichever form is selected now reserves the ‘/contact’ path in the system.  There was also a ‘Disable’ link in the list of forms/categories that didn’t function as I’d expect.  First off, isn’t that a bit redundant when combined with the unique ‘Selected’ option? Secondly, clicking that link takes you to the editing page for the form, just like the ‘Edit’ option does. The whole setup confused me quite a bit, probably because I was wanting it to look like webforms.  If you’re going to the trouble of adding a form builder at all, why not make it more generic and flexible.  Isn’t that the Drupal way?

Let’s Quit Messing Around.  What About Views?

I had been purposely avoiding views until I had a chance to check out what I’ve already discussed.  I knew that views in the core is the single most useful feature they’ll be adding to Drupal 8.  I didn’t want to get distracted by other new features once I started my investigation.  Visiting the views page looks much like we’re used to seeing once the module is installed in Drupal 7.  The exact same list of disabled views are pre-populated, although there are two distinct list boxes now (enabled, disabled) rather than having a ‘grayed out’ style for disabled views at the bottom of the same list like we’ve seen in the past.

Creating a new view has the same initial interface that we’ve seen in Drupal 7, although the ‘Create a page’ box isn’t checked by default now.  If you don’t check boxes to create displays in the view, a ‘Master’ display is added that doesn’t have a ‘Machine Name’ option and/or value under the ‘Advanced’ section.  Views in Drupal 7 functions the same way, although I had never tried it because I’m always creating a page or a block.

One of the features that I enjoy most about views is being able to add custom view templates to my theme.  It REALLY brings additional muscle and flexibility to Drupal. Upon expanding the familiar ‘Advanced’ section, I was initially confused.  What was previously ‘Theme: Information’ is now labeled ‘Output: Templates’.  OK. That makes more sense, actually.  Moving on.  The list of template file name suggestions is now a bulleted list and MUCH easier to see the order of priority. 

BUG NOTE: Clicking on one of the output category links on this page didn’t give me the default PHP code for the template file.  The resulting dialogue only provides a link back to the ‘theming information’, which seems inconsistent with the relabeling of this section.

A Fairly Substantial Bug

When I created my first Drupal 8 view, I wanted to keep it simple.  Aside from assigning the view name and selecting the option to create a page, I kept all of the defaults.  The result was a view that displays a list of teasers, but I inevitably want to define my own fields instead. I clicked the ‘Content’ link under the format section of the view settings and changed that to ‘Fields’.  Once I clicked the apply button, I expected to start adding some fields to my view, or maybe to see the warning about how the format is fields but none are configured.  Instead, I was returned with the settings unchanged.  

I tried several iterations of different options, but that value couldn’t be changed in the development release that I’m using.  I went a step further and created a new view without selecting the ‘Create a page’ option, and strangely enough ‘Fields’ is the default for the format in that instance.  I really didn’t dig much deeper because it’s obviously a work in progress.  I’d be surprised if I’m uncovering anything that the project team for this development release hasn’t already figured out.

Conclusion: This sneak peek continues to fuel my enthusiasm for both Drupal and the Drupal.org community.

I’ve probably been a bit too critical by even pointing out the bugs and oddities that I noticed.  There’s nobody out there suggesting that this release is ready for production websites yet, and I fully acknowledge that this is a work in progress.  That being said, cracking open the development code and looking around has me scrutinizing today’s projects to see where the updates in Drupal 8 will be useful. 

I may revisit the development release occasionally this year just to see how the project team is addressing some of the things that confused me about what I’m seeing today.  Hopefully you’ve been wondering how things are looking as well, and I’ve just saved you the trouble of doing your own investigation.  Have a question that I didn’t answer?  Feel free to comment below and I’ll continue to pick apart my test website with your suggestions.