RSS Tags

Search is an important facet of any large website these days. We’d talked previously about why you want to take full control of your site search. Bombarding your users with a mess of links won’t do anyone any favors. One of our favorite solutions for this problem is Apache Solr and recently we had the opportunity to set it up on Drupal 8. Let’s take a moment to go through a bit of what that solution looked like and some thoughts along the way.

Setting the stage

Before we dive too far into the how, we really ought to give a bit of time to the why. More specifically we need to cover why we didn’t simply use one of the existing modules contributed to Drupal by the community. At the time, there was one prominent module group for implementing Solr search in Drupal 8. The Search API module in tandem with the Search API Solr Search module were really the most direct way to implement this advanced search on your site. These are great modules and for a different situation would have worked just fine. Unfortunately, the requirements we were working with for the project were more specific than these modules were equipped to handle.

There were three key things that we needed control over and we aren’t keen on hacking a module to get something like this done. We needed to have specific control over what was indexed into Solr. The Search API module allows for you to generically specify how fields are translated to the Solr index, but if you need some different handling you would either need multiple indexes or you would need to sacrifice some of that customization. The site also needed to make use of a fairly complicated feature of Solr, the more like this query. (Warning, incoming search jargon!) This query allows you to search the index for content relevant to another indexed piece of content. This relevancy is determined by fields you specify in the query and results can be limited to content that meets a certain relevancy score threshold.

The last thing we had to have in this was the ability to manage how often content was indexed. The existing modules allowed for this action to happen on a periodic cron, but wasn’t able to have the index updated as soon as changes were made to content. This project was going to have a lot of content updated each day and that meant we couldn’t afford to wait for things to be indexed and updated. With these three things creating hurdles to getting Solr implemented in this project it seemed like we were going to have to go another way, but after looking at some documentation we determined that creating our own implementation would not be so difficult.

Solr search with Solarium

Before we get too far ahead of ourselves, we should note that this wasn’t done with a contributable module in mind. That isn’t because we don’t like giving back the the community, we totally do, it was because it was created for a very specific client need. There will likely be a more generic version of this coming out down the road if demand is high enough. Also, we are under the impression that most use cases are covered by the modules mentioned above, so that would be where most would start. Enough with the disclaimers; let’s talk Solarium.

We went with Solarium as the Solr client to use for this. That is what most of the existing Drupal modules use and it seemed to be the most direct way to do this with PHP. Installing Solarium is pretty simple with Composer and Drupal 8. (If you aren’t using Composer yet, you really should be.) Using a client for communicating with a Solr instance isn’t specifically required. Ultimately, the requests are just simple HTTP calls, but the client saves you from having to memorize all of the admittedly confusing query language that comes with using Solr.

Installing Solarium can be done as simply as composer install "solarium/solarium". You could also do this by adding a line to your composer.json file in the require section for "solarium/solarium": “3.6.0”. Your approach on this part may vary, but this should be done from the root of your Drupal site so that this library goes into the global dependencies for the project. These instructions are also detailed a bit more in the official docs for Solarium, here. The official docs also have a bunch of example code that will help if you dive into this like we did.

For this implementation, we opted to create a Solr PHP class to do the heavy lifting and made use of a Drupal service for calls to it from the rest of the app.

The heart of the class is going to be the connection to Solr which is done through the Solarium client. We will make use of this client in our constructor by setting it up with the credentials and default settings for connection to our Solr instance. In our case, we used a config form to get the connection details and are passing those to the client. We wanted to use the configuration management system so that we could keep those settings consistent between environments. This allowed more accurate testing and fewer settings for developers to keep track of.

We are doing this in the constructor so that we don’t have to create a new client connection multiple times during a given call. In our case, we ended up using this as a Drupalservicewhich allows us to only have the Client object created once per call and gives a simple way to use this class throughout the app.

The next part is the actual search method. This does a lot and may not be clear from the code below. In this method, we take parameters passed in and build a Solr query. We have a helper function in this that does some specific formatting of the search terms to put it in the right query syntax. For most sites, this code would serve fine for doing generic searching of the whole index or having multiple versions for searching with specific filters

The code we’ve presented so far isn’t breaking new ground and for the most part does a similar job to the existing search modules available from the Drupal community. What really made us do something custom was the more like this feature of Solr. At the time that we were implementing this, we found that piece to be not quite working in one module and impossible to figure out in another, so we put our own together.

Thankfully with Solarium, this was a pretty simple query to tackle and we were able to have related content on the site without much other setup. We can create a new more like this query and submit an id so Solr knows which content to compare against for similarity. The rest of it behaves very similar to the search method presented previously. The results are still returned the same and we are able to do some other filtering to change the minimum relevancy score or number of rows.

We didn’t share all of the code used for this here, obviously. The point of this post isn’t to help others create an exact duplicate of this custom implementation of Solarium in Drupal 8. At the time of this writing, it seems that the existing Solr modules might be in great shape for most use cases. We wanted to point out that if you have to dip into code for something like this, it can certainly be done and without an insane amount of custom code.

You really want to upgrade that old site to Drupal 8. You’ve seen the improvements, the new features, and you even figured out how to pull off an upgrade. The only thing between you and sweet Drupal 8 goodness is your boss. They don’t see the need to upgrade and think it won’t be worth the time or money to make the jump. Maybe they do think Drupal 8 is a needed improvement, but aren’t convinced that it is ready for prime-time. Here is what you do.

No begging required.

Upgrading to Drupal 8 is no small feat, but you should be able to convince your boss without having to resort to groveling. We’re going to approach this without insulting anybody’s intelligence. The benefits gained from making the move to this platform should be enough on their own that we won’t have to get too desperate. It has been noted that providing Drupal drop shaped cookies and treats in strategic locations around the office can only help your cause, but this isn’t an argument to employ bribery.

What every boss is going to want to hear is the benefits of making the jump to Drupal 8. They need the details on why it is worth the investment and what the difference is between what you are using and Drupal 8. You are going to need to have a plan ready and you will want to detail out how much better life is going to be after making the move. Drupal 8 comes with a heaping helping of awesome features out of the box. That sounds like as good of a place to start as any.

Do more with less.

We’ve talked about this a bit before, but Drupal 8 has the complete package right out of the gate. Does the site need detailed content moderation? It has that. Does it need more robust media handling? Oh, you better believe that it has that too. Everything from publishing sites to administrative apps are going to find they are happier being built on Drupal 8. We at Ashday have found that we have to drop into code a lot less frequently for the basics than in any previous version of Drupal.

Does this mean that this version is just a bloated mess of features now? Not necessarily. What it has is the essential features for enterprise software. What else it has is the flexibility and mobility that comes with the new structure under the hood. If your boss cares about using modern web technology, then Drupal 8 has that in spades too. Thanks to a collaboration with Symfony, Drupal is positioned to make use of things that have become web standards without having to reinvent the wheel like it did previously. This all makes for more performant websites out of the box and we haven’t even touched on actual performance features.

Clearer upgrade paths ahead.

All of these improvements would really be going to waste if we were going to have to fret over upgrading again in a few years. What a hassle upgrading between Drupal versions was in the past. The upgrade from Drupal 6 or 7 to 8 is hard to call upgrading as you will more likely be migrating and rebuilding a decent chunk of the website, but have no fear! Before your boss can run away upon hearing about the battle to migrate, it should be noted that 8 marks the end of that battle. The upgrade path to Drupal 9 and beyond is planned to be a lot more simple. Most modules should be able to port directly from Drupal 8 with minimal changes needed, if any.

This means that your websites can be kept up to date with the latest technologies, security, and standards without a huge mess in the years to come. That stability means a lot to clients, shareholders, stubborn coworkers, bosses, and we think that is a pretty big selling point on its own.

The final word.

The upgrade to Drupal 8 is worth your while. It allows for sites to be better positioned for stability in the future and it can add some really nice features to any site out of the box. We’ve even found that creating custom features is much faster and easier now than ever before. The structure of the code is modern, the toolset is using industry standards, and your editors will be happier with things like inline editing.

If you or your boss are still unsure about making the jump to Drupal 8. Check out this article on what to consider when upgrading or send them our way. We started using Drupal 8 before it was officially released and we think we have a pretty good handle on when to use it. Not to mention, we are pretty fun to talk to if you get the chance.

We’ve covered this in previous blog posts, but I think it’s time we came back to this and gave the contenders another look. (It's only been three years since we last covered this, so everyone has probably been waiting with baited breath for this one.) Internet culture loves to pit things against each other to see which reigns supreme, so let’s do that for these two juggernaut content management systems.

Wordpress? More like Worldpress

It is no exaggeration to say that a lot of the internet (about 28% at the time of this writing) is made up of Wordpress sites. With that sort of share, it is no surprise that most everyone has heard of this blogging-tool-turned-web-platform. Among other CMS type sites, there is no contest as far as usage goes. Somewhere around half of all sites built with a CMS use Wordpress. You’ll find it as a suggestion on most shared hosting platforms and there are tutorials across the internet to help someone get started using it. This thing is everywhere.

Wordpress is currently on version 4.9.x right now and has the great reputation of making sure that most of its users are able to upgrade automatically without much threat of backwards compatibility issues. This is great from a stability standpoint. When you create a website you probably don’t want to worry that the next update to the platform will cause you to rebuild it more often than you are ready. That’s not to say it has a perfect track record when it comes to security. Not every site has a situation that allows for the automatic updates and even then there are thousands of plugins available that could have security holes.

Wordpress is everywhere and it has been for a few years now. It is not suitable for every web need though and that comes through the most when you need something that can’t be done by installing a few plugins and throwing on a premium theme purchased from somewhere. There are many places you can get a custom Wordpress site built, but the CMS itself isn’t well suited for sites with a lot of editors, permissions, and features that large enterprise sites might run into.

By making Wordpress into an easily accessible platform, it has precluded itself from being able to handle the scale that comes with more complex sites. Without diving into code, you can’t define a new role or give users a different set of limited permissions outside of what already is defined in the system. The same goes with the types of content you can create and the fields you will have available. Plugins can extend some of this, but the reliability track record isn’t the greatest from my experience.

Drupal is for big projects

When it comes to market share, Drupal is a sliver of the pie compared to the internet at large. What it lacks in sheer numbers it makes up in the number of large and significant sites that use it. Some of these sites include government sites, entertainment sites, and university sites. Drupal has a reputation of being complex and heavy to run. While that is true, it isn’t necessarily a bad thing all of the time.

Drupal 8 is a bit of a rebirth for the platform. Promises of better forwards compatibility with future versions means that it will be easier to stay up to date than ever before. This was a pain point with previous versions of the platform and the community has made it a point to improve. Drupal 8 makes life a bit easier with many more features ready to go when you install the site. You can craft a pretty good, simple, site with a vanilla installation of this version.

The real magic comes out when a skilled team of developers get their hands on Drupal. This platform has always been made by developers for developers and it shows through in 8. The new object-oriented approach to the code makes it simpler for those who aren’t as familiar with Drupal to get in there and make some changes. It is extended easily with the large number of modules that add specific features to a site. These modules are put through pretty rigorous review before they are deemed stable and it makes for more secure sites overall.

Drupal’s other big draw is the workflow experience for editors and site builders. With all of the different ways you can setup a Drupal site, it is possible to have moderated workflow between editors and whoever has the final say on published content. New editing tools include a better wysiwyg, responsive images, and dynamic data views.

Drupal 8 is easier than it ever has been, but that doesn’t say a whole lot when you think about where it came from. What separates it from the rest of the crowd is the ability for it to scale to whatever size is asked of it, but that only can happen in trained hands still and that is probably why it hasn’t taken over the market share just yet. Not every small project needs a whole development team to get it done. If you only have a few pages with some text, Drupal is going to be too much for the task. (Though it will work just fine, it’s just overkill.)

The winner is the web

There is place on the internet for both of these platforms, and while it may seem like this is a cop-out answer to come to after approaching this topic again, there is more to it. Wordpress has established itself as a useful tool for what it does best. It allows users to create a website and a decent one at that. It has replaced the old platforms of yore that helped build the early internet, but it isn’t the platform of choice for the largest sites that get the most traffic. Quantity of sites using Wordpress does not mean these sites get the most traffic individually. Drupal is built for scale and is ready to handle high traffic. Is it the obvious choice for every website? No, but should an enterprise size project be shoved into a platform meant to handle every other website or should it be able to have its needs met specifically by something meant for that task?

Drupal isn’t known as a particularly lightweight content management system and that is one of the reasons we love it, right? It is meant to handle large amounts of complex content. A problem occurs when you have a site that is just flush with content of different types, how do you get users to it? Navigation can only get you so far sometimes. We have personally seen this on everything from large-scale publishing sites to medical practice sites.

Having a site search of some sort can greatly improve user experience and has been a core part of the web for a long time now. It solves a few pain points that exist in sites from small to large. What are these pain points? Users don’t want to wade through navigation. You want to control what content is presented. (Meaning you aren’t leaving it to an external search engine like Google to get users to the right content) You want a pleasant experience for your users that they will actually use.

Don’t leave your content in a maze of navigation links

We can’t talk about search without getting into thesearch modulethat has been part of Drupal since version 4 ish. The vanilla search module in Drupal is a very passable solution for searching content and users in a Drupal site. It doesn’t take much to set it up either, so if you want to get to a working search experience very quickly, this might be your best bet.

The search page itself isn’t too configurable beyond that, but it does come with an advanced search built into the page. This gives users more control over how their search keywords are interpreted with things like changing the operator from contains to match their exact phrase. It will also allow them to search in whatever content types are configured on the site. If you want your users to have visibility of the different content types on the site and they have useful names, then this can be something that replaces a bunch of different search pages on the site. If that isn’t what you want, well, you are out of luck with the search module.

There are other search modules available for Drupal, of course. There are modules that can extend the usefulness of the search module, but they can’t change too much about the underlying architecture that has a few flaws that are difficult to overcome. It will slow down the site on large Drupal sites and it still won’t have a lot of configurability to the search. For a small site, the search module is a good fit, but it would be difficult to recommend it for larger sites or sites that want to have specific control over the search.

Using Solr for large sites can be a no brainer

So if having search on Drupal is a recipe for a slow site, what can you do? Drupal is known for being great at integrations and this is a good opportunity to leverage one of the more useful search technologies available. It would be a mistake to classify it as “easy-to-use”, butApache Solris powerful. It has a lot in common with Drupal if you think about it. It is meant for a large amount of content, has a steep learning curve, and incredibly scalable in the right hands.

If you aren’t familiar with Solr, then this doesn’t mean too much other than a fluffy description. Solr is search engine software that can provide indexing and search from a variety of sources. It allows for more in-depth analysis of the content that is indexed. It can translate content, exclude html, search against spelling errors, be case-insensitive, determine likeness between content, and a whole lot more. Some hosting providers, likePantheon, provide this service as part of the their hosting infrastructure. If you manage your own server, then you can install Solr on that server or another remote instance. There are also a few cloud solr instances that are available out there that work pretty well also.

One of the more powerful things that becomes available when you use Solr is the ability to search within documents. That means you can extend the search into uploaded pdfs to provide even better search results. We’ve used this on a variety of sites to get users to information that would otherwise be unavailable to other searches. Features like this make it hard to compare a basic search to Solr. The searching is just a small factor in how search results are generated and processed before you hand them over to a user.

The Verdict

This is going to sound like we are cheaping out a bit, but there isn’t a one-size-fits-all sort of answer for a topic like this. With all web projects there are variables to consider and specific requirements that will drive decisions, so it would be impossible to say generically that you should always use one thing or another. What we can do is present the things that impact the decision the most. If the site needs search and it isn’t going to have thousands of pieces of content, then the search module will suit that need just fine. If there are more complex search needs, constantly changing content, high quantity of content, and a desire to have specific handling for different fields and content types, then you should really consider a tool like Solr.

Drupal and lightweight aren’t words that have historically gone hand in hand. Drupal 6 and 7 had some hoops to jump through to get something not included in the box. If you wanted to use an external service for displaying content or adding features you would feel that pain. Drupal had apparently not heard the phrase, “Less is more”. Does using Drupal really mean that you have to always deal with every Drupal layer to accomplish seemingly simple things? Luckily with Drupal 8 this isn’t the case any longer.

Hooks, hooks, and more hooks

Drupal is an awesome box of legos, you can build just about anything you want with it, that’s always been part of the draw for the system. The problem is that you had to have a lot of Drupal around to do it. You could do without all of the Drupal in the way by getting around it, but very quickly you would end up with a site that is in a bit of a Frankenstein’s monster situation and inheriting it would be a nightmare. If you needed something installed through some sort of package manager, you would likely have to do a whole lot of work to get it to play nice with Drupal, or you would have to sacrifice some of the benefits of using that system.

If you aren't interested in writing your own code, you could make use of the many contributed modules that are available. These little nuggets of awesome are great for adding a variety of features to your site, but they are bound by the same rules as above. Everything had to be added in a specific Drupal way and that caused a bit of overhead. Not to mention that if you have to use four modules to accomplish the feature you needed, then you also have four more to keep updated for security and stability. Not a bad solution, but it requires a lot more investment than should be necessary to allow for what should be simple, right?

I’m sure you’ll remember how this all went together later.

Your hooks can’t hold me!

Drupal 8 is a bit different in how you can extend it. This time around Drupal has partnered up with other industry experts, likeSymfony, to make the system even more extendable and with less Drupal involved. That PDF converter library your friend likes that is installed withComposercan now be part of the project much more easily. You can even install Drupal itself that way if your hosting provider allows for that.

You can use many other libraries from a variety of sources, and they can integrate very simply while using very little Drupal code. This means you can easily add some other PHP, JavaScript, Python (if you’re into that), library and get the functionality you want without adding more reliance on other community contributed modules or deeper Drupal hooks. This opens the doors for using external services you might already be familiar with for things that Drupal already does as well. Want to useSolror Google for searching on your site? Easy. Need your files to be stored somewhere separate from the website? Done. Want React to replace the display of your site? You get the idea.

More community contributed modules are becoming available for Drupal 8 and they are also taking advantage of the ‘less is more’ approach that comes with the upgrade. If you aren’t as technically inclined or don’t have a team that can deep dive into Drupal easily, then these will be a great way to add more features to your site. You may still need a custom solution for your needs, but these may get you closer before you get to that point. Alternatively, you could find an outside vendor that already has this all down and could expertly judge when contributed or custom solutions will work. Where would you find one of those you ask?

Want to get more out of Drupal? If you don’t know your Symfony from your Composer and you are stuck on these hooks, then I would suggest you try working with a team of Drupal integration experts. Ashday happens to be pretty good at this sort of thing and we aren’t shy to talk about it either. We have been working with Drupal 8 since before it was officially released and we are pretty big fans of all the great things to come out of it.

Earlier this month Acquia put on a great webinar hosted by Angie Byron & Gabor Hojtsy titled All You Need to Know About Drupal 8.2 and Beyond (slides linked below).

There were many topics covered and I could not help but get super excited for some things we can look forward to in the upcoming release of Drupal 8.2 slated for October 5th 2016.

Below are some takeaways I found particulary cool and wanted to share:

Migrate in Core

Currently we have a migrate UI available to us as a experimental core module. I have not played with this much to date but as a sitebuilder I am really excited to see efforts being made to develop a UI for this and bring it into core. In previous migration efforts (using the migrate module) it was very much a job 100% slated for our devs and now I hope to be able to help with these efforts. In Drupal 8.2 the migrate modules are still experemental but it looks like there was some mojor upgrades and a focus is being placed to get this out of experemental and into core sooner than later.

Content Workflow

Revision all the things! (well almost all the things) The Content Workflow initiative is a result of Deploy and Workbench Suite of modules mantainers working together to bring this functionality into Drupal core. These tools allow us to create/manage revisions and approval workflows for our content. In Drupal 8.2 we are getting our first glimpse of this in core with the Content Moderation module added as an experimental core module for us to play with and provide feedback. There is some really cool C.R.A.P. (create/read/archieve/purge) slated for this initiative down the road with things like Full-Site previews with "Workspaces".

Block Layouts

Some of you may remeber back in the early D8 beta days there being some work done on Block Layouts but it was pulled aong the way due to it not gong to be ready in time for launch. Well in Drupal 8.2 we are getting a chance to see the some of this in action. Again this is being released as a experemental core module. In 8.2 we will gain the ability to place blocks directy from the front end of the site and not have to access the blocks administration page. This looks to be very much in line with how the inplace editor feels to an end user and an overall great usability improvement (especially for folks new to Drupal).

There are many other greats things in the works for Drupal core slated for 8.3-8.4 that were presented. API Improvements, Enhanced media management, Dream Fields/Data modeling, Pre Content Type Layouts, Swapable Layouts and Preview-First Views UI just to name a few.

Check out the video/slides HERE for a full rundown and ways to help with all of these initiatives.

Welcome to the third and final installment of our three part Drupal 8, Pantheon & GitKraken series. For more information on what this series will be covering check out our intro HERE.

The first installment of the series can be found HERE. For the second installment click HERE.

OK so now that we have our site all set up on Pantheon, Gitkraken installed and configured, and our remote repo cloned it's time to version control some of our work.

Step 1. Exporting our sites "Active" configuration

When making changes on your Pantheon dev site you are changing the "active" configuration. There are many things we can do to our site to change this but for this example I have created a new view. Once you have made your change the goal is to now take this active configuration, version controll it, and move it into our "staged" configuration:

1. In the admin menu go to Configuration>Configuration Synchronization and click the export tab.

2. With Full Archive selected, export the sites active config.

Step 2. Pull from the remote repo to our local repo

Now that we have our active config exported we want to do a Pull from the remote repo to ensure our local repo is up to date before we change the staged config.

1. In Gitkraken click on the "Pull" icon.

(*note: For this tutorial this step is technically not needed since we know no one has changed our site since we cloned our repo BUT it is very important to always pull before you push)

Step 2. Updating our local Repo's "Staged" Configuration

Now that we have our dev sites active config exported and we have pulled from the remote repo, we need to update our local repos staged config:

1. Extract all the files from the export and place them in the following directory of your local repo: sites\default\config.

Step 3. Stage and Commit our changes locally

Once we have these files in this directory we should see the changes in Gitkraken. and we can stage and commit them to our local repo.

1. Add a commit message (this is a brief description on what changes were made).

There is no doubt that a command line workflow is much faster and more efficient, but for me (for now) this is working and allowing me to collaborate with our more experienced developers. Some other benefits of learning some of these tools is I can now use Gitkraken to pull and push to other repos (not just Pantheon). Git branching and the entire repo in general is much more easily visualized which makes understanding the whole process a lot easier.

What's Next?:

So while this is working, having a local developemnt environment integrated in this workflow is ideally how I want to work. I have struggled for some time now fiding the best way to set up a local development environemnt on a windows machine without using any code, the command line, or having to edit a bunch of files on my local system. Just recently (yesterday) I have had much success with Acquia Dev Desktop 2 and plan on sharing how I integrated that into this workflow

I hope others have found this helpful and look forward to sharing more with you.

For those of you who know me well, you know I do not like to play around with code all that much or even use command line tools if I can avoid it. There are many reasons for this but mostly I am just not that comfortable setting up, maintaining and using these type of tools. That being said I do like to site build in Drupal….A LOT :).

Lately I have been creating and managing Drupal 8 sites with Pantheon and using a Git client called GitKraken to manage my version control workflow and I have to say the experience has been FANTASTIC!

With these three components I am able to:

Create a brand new Drupal 8 site

Export/Import my sites configuration

Have a fully version controlled workflow with dev, test and live environments

Generate SSH keys

Clone / create a local repository

Stage and commit changes

Pull & Push code to a dev environment

All without ever touching a line of code or a command line! Want to learn more??

If you said YES then you are in the right place.

Following this intro post there will be a three part weekly series where I will walk you through my experiences with setting up a new Drupal 8 site on Pantheon, managing configuration changes with Drupal 8, and managing a Git repository with GitKraken.

This is a great set up/intro for beginners looking to work with Drupal 8 and keep their work versioned controlled (which we should all do) or for folks like myself who would just rather use a GUI as opposed to command line tools.

Drupal 8’s improvements to contact form management and creation is one of my favorite site building upgrades that has been added to Drupal 8’s core.

We now have the ability to field contact forms in the same familiar way as many other entities and can have multiple form variations living at different urls on the same site.

- Need a phone number field? Not a problem.

- Want it to be required? Piece of cake.

- Looking to have a RFQ form as well as a contact form? Yup, we got that….all in core!

All of your forms are nicely managed in one place (/admin/structure/contact) and over all it makes for a much improved experience from previous versions of Drupal.

Recently while building a new D8 site I had a request to hide the “preview” button that is shown on all the contact forms. A task most commonly done with a simple form alter but not being a developer I wanted to see if I could do this without any code and not trouble our dev team as they were working on more complicated features.

Enter the Contact Storage module. This little gem offers some really useful enhancements to the already much improved Drupal 8 contact form improvements.

First off it solved my issue of hiding the preview button with a simple check box on the contact form edit screen.

It also allows for a redirect path to be set which is great considering I would have done this with the Rules module in the past, which at the time of this post is still in alpha for D8.

Another nice little feature is the ability to change the text of the submit button….a common request which is now very easily accommodated right in the UI!

As the name suggests the Contact Storage module also provides storage for all the messages submitted through the forms on your site as well as views integration to manage them.

The admin view is configured with the ability to look at all of the submissions at once or filter them by individual forms. The view itself is conviently accessible via a new "List" tab added to the contact form admin screen.

A big thanks to larowlan and all the contributors who helped put this module together and are currently maintaining it.

I have a feeling I will being using this one a lot more in the future!

A codebase can end up with a bunch of unused modules one way or another. Identifying unused/installed modules is tough, but identifying unused/disabled modules is pretty easy.
Modules and their status exist in the system table of Drupal. It's simple enough to query for disabled modules, but that will return results of modules which may have already been removed from the codebase.
In a case of a very large inherited D7 project, we had about 150 modules show up when querying the system table for modules where the status was 0, but only about 40 of those still existed in the codebase.
Here's how to quickly determine which modules are disabled, but still exist in the codebase.
Note, this isn't a matter of gaining performance, it's simply a method for a bit of house cleaning. This example assumes your contrib directory exists in sites/all/modules/contrib.
First open up a shell and navigate to sites/all/modules/contrib.

With clear weather and an ideal venue on Mission Bay in sunny San Diego California,SandCamp 2016 was a great way to spend a few days learning and gaining inspiration to dive deeper into everything new Drupal 8 brings to the table.
The camp opened on Wednesday Feb 24th, with 2 days of half and full day training sessions, some paid, some free. The topics for these in-depth sessions included Kalabox, OO PHP, multilingual sites, D7 module development/theming, Backdrop, and of course Drupal 8 module development.

Its an extremely flexible ecommerce framework largely built on rules which as a site builder makes me very happy.

It is above and beyond our current go-to platform for building ecommerce sites. However if you have ever built a site with Drupal Commerce you know that there are few main components, Product Types, SKU’s and Product Displays.

For those of you who are unfamiliar, when using Drupal Commerce you create a content type as a “Display” which will house certain “Product Types” via a product reference field. You can have multiple product types which will house all of your various SKU’s.

You can think of displays as shelves in a physical retail store. Once you have built your “shelf” you can then place your “shirts” on it. A “shirt” would be an example of a product type. The shirts on your shelf may be different sizes and different colors but they are all shirts. The SKU is what would differentiate the various size and color options. This is a common way we would explain this to new clients who we are building a Drupal Commerce site for that may not be familiar with the platform.

This concept of Displays, Product Types, and SKU's, although very logical, can cause a bit of confusion and can feel cumbersome. This is especially true since the creation of displays and products are managed in two different areas of the site.

Enter the Inline Entity Forms module.

The Inline Entity Form module adds a new widget type to the Product Reference field which when added to a Display allows for streamlined workflow for users to add/manage products all within the display!

To achieve a basic set up for this simply do the following (assuming you have Drupal Commerce installed and configured):

Install and enable the Inline Entity Form module.

Add a product reference field to your Display Content Type.

Select the new “Inline entity form - Multiple values” options as the widget for this field.

Select the product types you want to be referenced for this display.

Select Allow Users to add new products.

Select Unlimited on the number of values

Save

*There are some other options which are helpful in this set up that you can explore but this is what I would consider the basis to streamlining this process.

Now with this set up a user can add a product to their site by creating a display. Within the display there is a product reference section that will allow them to select a product type and add/configure individual skus of that type, for that display….all in one place :).

If they want to add existing skus to a display they can do that as well with some options selected in the widget set up.

We find this to be a great improvement to the product creation/management workflow and have had a better response from clients when rolling out new systems with this set up. I highly recommend you check out the Inline Entity Form module if you a builing a drupal commerce site. As always a big thanks to Ryan Szrama (rszrama) and all the folks over at Commerce Guys for building/maintaining such an awesome ecommerce framework & contributed modules to extend it!

We are excited about Drupal 8 and the many new front and back end features it is bringing to the table. Our block system has been completely rewritten and while blocks in Drupal are nothing new in Drupal 8 they are getting some serious upgrades!

Block Types

In Drupal 8 we now have the concept of block types. In previous versions of Drupal our blocks were pretty basic. They offered us a title and a body field. In Drupal 8 we can have various custom block types which are fieldable, very similar to content types. This provides a whole new level of customization to blocks that we have never had in the past.

Blocks in multiple regions

Another major change to the block system in Drupal 8 is the ability to place the same block in multiple regions. We can now choose to display blocks in different places on different pages etc.

View modes for blocks

We can also choose to have various view modes for our blocks. This allows us to customize what fields are displayed based on the view mode we select. This combined with Block Types and the ability to put blocks in multiple regions opens up a level of flexibility that is far superior to anything we have had to date with the block system in Drupal.

Display title check box

In Drupal 8 we now have a simple check box to turn the display of a block title on and off. No more having to type "<none>" if you don’t want the title to display.

New things are now blocks

We have some new blocks available to us in Drupal 8:

Site Branding

Page Titles

Tabs

Messages

Breadcrumbs

This gives us much greater control over where these items display. For anyone who has worked with Drupal in the past having the page title as a block is going to make life a little easier for us ;)

Blocks are now exportable

With Configuration Management built into Drupal 8 our blocks are now exportable. This was a big deterrent for us using blocks too heavily in the past as they did not travel well, or easily. Thankfully that is a thing of the past!

New Block Layout UI

There is a brand new UI for block management in D8. The new “Block Layout” screen shows all of our available regions and the blocks within them similar to the block screens in the past. One of the main differences is it gives us access to view and create custom blocks as well as manage/create block types via a “Custom Block Library” tab at the top of the page.

Another big change is we no longer have this massive list of every block on the site at the bottom of the page. Instead we now have a “Place Block” button that will open up a modal showing us all of the available blocks for us to place.

Within the modal we have search box which filters down our available blocks by title in real time making finding what you're looking for much quicker without the need for any contributed modules.

Overall the Block system in Drupal 8 is more flexible, functional, and manageable right out of the box. I am looking forward to building more with it and seeing how these new features play into customer requirements and new site architecture.

In the wonderful world of software development we have back end developers, front end developers, project managers, designers and a slew of other roles and titles that make it all possible and great! With Drupal came a new role…the site builder.

One of the most satisfying roles for me at Sego is that of a site builder. There is no better feeling than being able to implement a feature or build something from scratch without having to touch ANY code. This is of course the opinion of someone who is not a programmer by trade but I imagine this sense of satisfaction from creating something out of nothing is why most programmers do what they do….its an amazing feeling.

Up until my experience with Drupal I would consult with clients creating comps based off of their needs and then pass them along to our developers. The team would bring the product to life and turn these static comps into functioning pieces of software. It was satisfying to see the finished product but I always felt like I wanted to be more involved in the actual building of the software.

When we first started using Drupal I immediately began exploring all that could be done in the UI and quickly said “wow this is confusing”. As with most things Drupal it took practice, persistence, and a lot of help from the community but before I knew it I started understanding the lay of the land.

Shortly after that I began building out small pieces of projects with our devs. Setting up some content types, building out different menus, and little by little we started to realize that as a site builder I could reduce their workload and we could really push projects out quicker with this Drupal thing. I was building not just designing...without any code...awesome!

Many years later the power of site building is better than ever especially with some of the major upgrades with Drupal 8. This is one of the main reasons why we love building with Drupal. It allows for a synergy between site builders and developers that when done right can produce some power results in incredibly fast turnaround times. We have entire platforms that are fully extendable all though site building which allows for our devs to focus on more complicated issues while our site builders (me included) can extend these existing platforms.

If you are looking to get involved with technology and do not have a lot of, or any formal programming experience, I would highly recommend looking into Drupal site building. It’s open, has a great community, and when mastered will allow you to build some pretty amazing things all without ever having to touch a line code.

I’m gearing up to comment on Tom Geller’s recent grumbles about the Drupal free documentation, but first I feel that I should point out the obvious: Drupal has some great paid documentation. Some highlights that I know about:

People who want to know what all the fuss is about can pick up The Lullabots’ Using Drupal, which I’m using as light bedtime reading.

Javascript is a Drupal component, too. An increasingly important one, in fact. Which gives me an excuse to plug one of my favorite software books ever: Crockford’s Javascript: The Good Parts. A blessedly short but dense book. Just the sort of thing that Tom Geller might like, I suspect.

The open-source revolution has proceeded so swiftly that some people seem to have forgotten that all documentation used to come in big paper books that cost money. Yet that technology is still surprisingly useful! And it really isn’t that much money, compared to the medical expense of continually banging your head on your desk.

UPDATE: This system was an experiment and I no longer use it. I feel
it’s too complicated to be worth the effort.

Any programming project – including Drupal projects – should use a
version control system. My favorite such system is
git. If you haven’t tried it I recommend that
you learn all about it at the tutorial section of
github, or from Peepcode’s
git screencast.

Assuming that you understand the basics of git, let’s apply it to a
Drupal project. The simplest strategy is to create a single git
repository that holds everything in your project. You download Drupal
core and modules (using FTP, the
Update Status module, or
drush) and you check them into git
as you install them. Your custom changes get checked into the same git
repository.

Here’s a couple of hints:

Use branches to separate your code from contrib

You want to make it easy to distinguish changes that you make from
those made by others. Creating branches is a good way to accomplish
this. When you first set up your project, create:

A branch called core. You should check the Drupal core code into this branch.

A branch called modules, based on core. When you install a third
party module, you should do so in this branch. (Actually, it would
be ideal to create a separate branch for each module, but that’s a
bit of work to manage so I’ll hold off on recommending that. I’d
hate to scare you away on the first day.)

Branches for your site’s code, based on modules. You’ll probably
want a development branch (I tend to name this devel) and a
production branch (for which I often use master).

When you need to update core, you do so in the core branch, then
merge core into modules and any other branch that depends on
it. When you need to update a module, you do so by switching to the
module branch, performing and committing the update, and then
merging module into your development branches.

Tell git to ignore certain files

There are certain files in your Drupal installation that you should
probably not have under version control at all:

There are two ways to make git ignore certain files. One is to put the
names of those files in a file called .gitignore in the base
directory of the respository, right next to the .git directory. The
other is inside the .git directory itself: If you add the name of a
file to .git/info/exclude it will be excluded from the repository.

No matter which method you use, git won’t delete the ignored files –
it will just pretend that they aren’t there. You can ignore whole
directories, and you can use wildcards to make git ignore entire sets
of files with similar names.

How do you choose which ignoring method to use? The idea is that
.gitignore is part of your project: You check it in to git, and it
gets copied around wherever your project goes (e.g. to your
development server). So if you want to ignore a file across all
servers (like the files directory, which will exist everywhere you
install the code), you should put that file’s name in
.gitignore. Whereas .git/info/exclude is for files that only occur
in your local repository and aren’t expected to be anywhere else, like
editor settings files, or the directory beneath sites which
corresponds to your local machine’s test domain.

Example

Here’s a set of example commands for building a new project. We’ll
assume you’ve already downloaded the necessary Drupal tar files to
~/Downloads.

The blog has now been updated to Drupal 6. There aren’t a lot of
visible differences yet (unless you are an IE6 user… you folks have
been officially deprecated) – the very nice Drupal 6 theming
improvements made it pretty easy to duplicate my old style, while
cleaning it up a lot at the same time.

Some people have accused D6 of being both easier and harder to theme,
but so far all I can perceive is the “easier” part, perhaps because
I’ve been elbow-deep in the Drupal 5 theming functions and know how
complicated that was.

I might be crazy, but as I read Steve Yegge’s essay on the Properties Pattern I felt as if I was being introduced to something I already knew. And that’s not just because the essay describes Javascript. I think that’s because Properties lists are the fundamental Drupal data structure.

This line stuck out:

I’ve talked about the main problems imposed by the Properties pattern: performance, data integrity, and navigability/queryability. They’re all trade-offs; you’re sacrificing in these areas in order to achieve big wins in flexibility and open-ended future extensibility for users you may never meet.

Yep, that sure sounds like Drupal’s $node, $user, and $form objects to me.

I have only three things to say about the heroic efforts of Mark Boulton to come up with a design for a Drupal wordmark that will satisfy the entire Drupal community.

First: Mark is a brave man.

Second: I hereby officially delegate my opinion on the Drupal wordmark to Mark, Dries Buytaert, Barry Jaspan, and Angie Byron. If they like it, I like it, by definition. My desire to further influence the decision is more than trumped by my belief that such artistic decisions can’t be made by a giant, public committee.

Finally: Voting. Draw up three strong contenders, then let the community respond to a questionnaire. Don’t request too much free-form feedback in open forums during your design process. You will go stark raving mad.

The firm that recently redesigned my alma mater’s logo did a great job with this: The first I heard of the project was when I received an email link to an online questionnaire. The questionnaire took ten or twenty minutes to complete, featured three variations of the logo, and asked all sorts of fuzzy questions – I can’t remember any of them, but they were something like “does this logo express the intellectual qualities you associate with the university.” Or whatever. In retrospect, it didn’t really matter what the questions were – the important thing was that they asked a sufficient number of important-sounding questions to convince me that I was participating in a thorough, serious decision-making process.

Then, a few months later, the university announced the winner, and, lo! I was happy. Because, hey, the new logo looks pretty good! And because I had been asked.

As I was setting up a new Drupal site, I decided to try out the hilariously named phpass module. (I cannot read that as “PH Pass” to save my life. It always comes out as… something else.)

The good news about this module is that it builds upon a PHP project called, um, phpass to add better password hashing to Drupal. The traditional way to handle passwords is to ask the user for one, compute a hash function on it, and store the hashed version. Unix systems use the Unix crypt utility to make the hash. Some newer and more naive systems, like core Drupal, use MD5 hashing, presumably because it’s newer (and, therefore, niftier by definition) and also because it’s faster.

Unfortuately, neither my Mac nor my Ubuntu deployment box supports CRYPT_BLOWFISH, the encryption scheme that’s needed for all-out bcrypt support. So I am using the phpass fallback scheme for now. I could try to install CRYPT_BLOWFISH using the Suhosin PHP hardening extension, but would need to test this carefully to make sure I don’t break Drupal in the process.

In the meantime, I got halfway into the Suhosin downloading process before I decided to put it off until tomorrow. Part I of the process was to finally install Gnu Privacy Guard, which I have always resisted because it seemed to be a usability horrorshow with few actual uses. I only know two people who really seem to use GPG-signed mail, let alone GPG-encrypted mail. But it turns out that there’s now a handy set of instructions for installing GPG on a Mac using the MacGPG project. And I might even get GPG working with Mail once the GPGMail utility finishes being ported to Mac OS 10.5.