Nov 07 2018
Jay
Nov 07

Determining how content on your site should be cached isn't a simple topic. Last time, I covered cache contexts and tags. Today, I'd like to get into a couple more advanced topics: The use of custom cache tags and of max-age.

Custom Cache Tags

Drupal's built-in selection of cache tags is large, and some contributed modules add additional tags appropriate to what they do, but for really refined control you might want to create your own custom cache tags. This is, surprisingly, quite easy. In fact, you don't have to do anything in particular to create the tag – you just have to start using it and, somewhere in your code, invalidate it:

 \Drupal\Core\Cache\Cache::invalidateTags(['my_module:my_custom_tag']);

 As an example, to continue the scenario from part one about a page showing recent articles, there is one thing about this page that the tags we've already looked at don't quite cover. What if a new article gets created with a publish date that should be shown on your page? Or, maybe an article which isn't currently displayed has its publish date updated, and now it should start showing up? It's impractical to include a node-specific tag for every article that might possibly have to show up on your page, especially since those articles might not exist yet. But we do want the page to update to show new articles when appropriate.

The solution? A custom cache tag. The name of the tag doesn't matter much, but might be something such as my_module:article_date_published. That tag could be added on the page, and it could be invalidated (using the function above) in a node_insert hook for articles and in a node_update anytime that the Date Published field on an article gets changed. This might invalidate the cached version of your page a little more frequently than is strictly necessary (such as when an article's publish date gets changed to something that still isn't recent enough to have it show up on your custom page), but it certainly shouldn't miss any such updates.

This is a simple example of a custom cache tag, but they can be used for many other situations as well. The key is to figure out what conditions your content needs to be invalidated in and then start invalidating an appropriate custom tag when those conditions are met.Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

Rules for Cache Max-Age

Setting a maximum time for something to be cached is sort of a fallback solution – it's useful in situations where contexts and tags just can't quite accomplish what you need, but should generally be avoided if it can be. As I mentioned in a previous article, a great example of this is content which is shown on your site but which gets retrieved from a remote web service. Your site won't automatically know when the content on the remote site gets updated, but by setting a max-age of 1 hour on your caching of that content, you can be sure your site is never more than an hour out of date. This isn't ideal in cases where you need up-to-the-minute accuracy to the data from the web service, but in most scenarios some amount of potential "delay" in your site updating is perfectly acceptable, and whether that delay can be a full day or as short as a few minutes, caching for that time is better than not caching at all. 

However, there is one big caveat to using max-age: It isn't directly compatible with the Internal Page Cache module that caches entire pages for anonymous users. Cache contexts and tags "bubble up" to the page cache, but max-age doesn't. The Internal Page Cache module just completely ignores the max-age set on any parts of the page. There is an existing issue on Drupal.org about potentially changing this, but until that happens, it's something that you'll want to account for in your cache handling.

For instance, maybe you have a block that you want to have cached for 15 minutes. Setting a max-age on that block will work fine for authenticated users, but the Internal Page Cache will ignore this setting and, essentially, cause the block to be cached permanently on any page it gets shown on to an anonymous user. That probably isn't what you actually want it to do.

You have a few options in this case.

First, you could choose to not cache the pages containing that block at all (using the "kill switch" noted in part one). This means you wouldn't get any benefit from using max-age, and would in fact negate all caching on that page, but it would guarantee that your content wouldn't get out of date. As with any use of the "kill switch," however, this should be a last resort.

Second, you could turn off the Internal Page Cache module. Unfortunately, it doesn't seem to be possible to disable it on a page-by-page basis (if you know a way, please drop us a line and we'll update this post), but if most of your pages need to use a max-age, this may be a decent option. Even with this module disabled, the Internal Dynamic Page Cache will cache the individual pieces of your page and give you some caching benefits for anonymous users, even if it can't do as much as both modules together.

My preferred option for this is actually to not use a max-age at all and to instead create a custom, time-based cache tag. For instance, instead of setting a max-age of 1 hour, you might create a custom cache tag of "time:hourly", and then set up a cron task to invalidate that tag every hour. This isn't quite the same as a max-age (a max-age would expire 1 hour after the content gets cached, while this tag would be invalidated every hour on the hour) but the caching benefits end up being similar, and it works for anonymous users.

Up Next

Now that we've gotten an overview of how to determine what rules you should use to cache content on your site, it's time to get a little bit more technical. Next time, I'll be taking a look at how Drupal stores and retrieves cached data, which can be immensely useful to understanding why the cache works the way it does, and it's also quite helpful to know when fixing any caching-related bugs you might encounter. Watch this blog for all the details!

Offer for a free consultation with an Ashday expert

Oct 31 2018
Jay
Oct 31

Leveraging Drupal's cache effectively can be challenging at first, but the benefits for your site's performance make it well worth the effort. It all starts with figuring out what sort of rules your site should use to cache its content. The improved page load times that come from properly handling caching rules can help improve SEO and are generally more appealing to those that visit the website. In the right hands, the techniques outlined in this article can get a website into a much more specialized caching system.

I previously covered the fundamentals of how caching works in Drupal 8, including what the two core caching modules do and what cache tags, contexts, and max-age are for. If you're familiar with those things, then this post is for you; otherwise, check out my previous article and get up to speed before we dive into a slightly more in-depth topic: Figuring out how you should set up caching on your site.

If you're using a simple Drupal installation with no custom code and with well-maintained contributed modules, Drupal's Internal Page Cache and Dynamic Internal Page Cache modules will likely cover your caching needs. This article focuses on some more complex and custom scenarios which, nonetheless, come up with some frequency. 

The Guiding Principle

Perhaps the most frequent issue custom code has when it comes to caching is that it doesn't account for caching at all. This isn't ideal if you want to take advantage of Drupal's caching system to optimize your site's speed, and it points to one principle which can be tricky to learn and is critical to master: If you write custom code, always think about its caching implications. Always. 

Often, the implications will be minimal, if there are any at all. It's important not to assume that every bit of custom code will cache perfectly on its own - that's a mistake that could lead to something being cached either for too long or not at all. 

When to Disable the Cache 

Most everything Drupal renders as output (to a web browser, to a RESTful web service, etc.) can be cached. However, sometimes the development time to ensure that your custom code handles caching precisely outweighs the performance benefits that caching might provide. So the first question when you're writing custom code is, should this be cached at all?

Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

If you're building something like an administrative page that only a few users with special permissions will ever see, it may not be worth the time and effort to make sure it is cached perfectly, especially if the rules for doing so would be complicated. For these scenarios, Drupal has a "page cache kill switch" that can be triggered in code:

 \Drupal::service('page_cache_kill_switch')->trigger();

Calling the kill switch will stop both the page cache and the dynamic page cache from doing any caching on that page.

This should be used with caution though, and only as a last resort in situations where figuring out proper caching logic isn't worth the time. It should never be used on a page which is expected to be viewed by a large number of your website's visitors.

Rules for Cache Contexts

You should consider using a cache context if your content should look different when displayed in different situations. Let's look at a couple scenarios that benefit from using a cache context:

Say you have a site which can be accessed from two different domains and you want to display something a little different depending on which domain someone is looking at. Perhaps the site's logo and tagline change a little. In this case, the block containing the logo and tagline should be given the url.site context. With this context in place, Drupal will cache a separate version of the block for each domain and will show each domain's visitors the appropriate one.

Or, perhaps a block contains a bit of information about which content the currently logged-in user has permission to edit. This sounds like an excellent case for using the user.permissions context to indicate to Drupal that the block is different for each possible combination of permissions that a user might have. If two users have the same permission, the same cached version can be used for both of them.

There are many other contexts are available as well; take a look at the full list to see if one or more of them is applicable to your code.

Rules for Cache Tags 

Cache tags are probably the most important caching mechanism available to custom code. Drupal includes countless cache tags which can be used to invalidate a cache entry when something about your site changes, and it is also very easy to create your own cache tags (which we'll get to in a minute). For now, I'm going to focus on some of the cache tags Drupal has by default.

Say you're creating a page which shows the top five most recently published articles on your site. Now, Drupal sites can often make use of the Views module for this sort of thing, but depending on your exact requirements Views may not be the best approach – for instance, maybe part of the content has to come from a remote service that Views can't readily integrate with. The most obvious tags needed for this page are the tags for the specific pieces of content that are being shown, which are tags in the format of node:<nid>, for instance, node:5 and node:38. With these tags in place, whenever the content gets updated, the cache entry for your page gets invalidated, and the page will be built from scratch with the update information the next time somebody views it.

But that's not all there is to think about. Perhaps this page also shows what categories (using a taxonomy structure) each article is in. Now, the articles each have an entity reference field to their categories, so if a user changes what categories the article is in, the relevant node:<nid> tags already added to your page will get cleared. Easy enough. But what if somebody changes the name of the category? That involves editing a taxonomy term, not the article node, so it won't clear any node:<nid> tags. To handle this situation, you'd want to have appropriate taxonomy_term:<id> tags. If an article with ID 6 has terms with IDs 14 and 17, the tags you'd want are node:6, taxonomy_term:14, and taxonomy_term:17, and you'll want to do this for every article shown on your page.

Fortunately, most of the time, you don't need to worry about the specific tag names. Nodes, terms, and other cacheable objects have a getCacheTags() method that gets exactly whatever tags you should use for that object.

These are all simple entity-based tags, but there are many more available as well. There are tags for when various aspects of Drupal configuration changes as well as for things such as when certain theme settings get changed. Unfortunately, since the available cache tags vary from site to site, there isn't a ready-made list of them available for you to use as a reference. You can, however, look at the "cachetags" table in your Drupal database to see a list of all the tags that have been invalidated at least once on the site. This will be pretty minimal if your site is brand-new, but as people use the site it will start filling up.

The basic idea of tags is this: If you render something on a page, and there's a chance that something displayed on it might change in the future, there should be an appropriate tag in place to watch for that change.

Up Next

This is a big topic, but it looks like we're out of time for today. Next time, we'll delve a bit deeper into cache tags by seeing how to create custom ones that perfectly fit your site's needs and will also cover how to use max-age, including one important gotcha that makes them more complicated than they look.

Offer for a free consultation with an Ashday expert

Oct 24 2018
Oct 24

 Drupal Module Spotlight: Paragraphs

I really don’t like WYSIWYG editors. I know that I’m not alone, most developers and site builders feel this way too. Content creators always request a wysiwyg, but I am convinced that it is more of a necessary evil and they secretly dislike wysiwygs too. You all know what wysiwygs (What You See Is What You Get) are right? They are those nifty fields that allow you to format text with links, bolding, alignment, and other neat things. They also can have the ability to add tables, iframes, flash code, and other problematic HTML elements. With Drupal we have been able to move things out of a single wysiwyg body field into more discrete purpose-built fields that match the shape of the content being created and this has helped solve a lot of issues, but still didn’t cancel out the need for a versatile body field that a wysiwyg can provide.

Content creators yearn for the flexibility of creating a page that matches their vision for how they want the layout. Front-end developers and designers want to be able to rigidly style a site that always looks good, and that clashes with the unexpected markup that a WYSIWYG can produce. These differing priorities can resulting in a real mess of a page. It’s been a struggle as old as the CMS itself.

Solutions of the Past

As I mentioned above, the Drupal solution to runaway WYSIWYG markup is purpose-built fields to catch all specific sections of content that you can.Instead of allowing the whole page to be created in one WYSIWYG field, we would have a field for an image, a summary, some various highlight sections, etc. One problem still remains, content creators want to be creative and have various patterns of content depending on what they are writing about. This includes images floating in every which-way, videos in the middle of an article, quote blocks, content in columns, and the list goes on. You can’t just build a bunch of types of fields for this problem. In the past, I tried using Field Collections and custom form alters to build a user interface that allowed them to select and only see the relevant fields, but this still proved to be too rigid.

The Modern Solution

Enter Paragraphs, the Drupal contributed module that can ultimately solve this problem. I started using Paragraphs with Drupal 7 back around 2014 and it really changed the way I thought about editing and creating content on a Drupal site.

With Paragraphs you can define little entities of fields much like the Field Collection module but less static. The difference is that you can access all or some of the different paragraph entity types from a single field on your content type. This single Paragraph content field will replace your body content wysiwyg field entirely. The Paragraph content field will allow you to endlessly add in different paragraph types and provides a method to reorder after creation. Working with your content creators, you can determine an unlimited number of content patterns that they would like to use. For example, you can create paragraphs with the fields required to make a slideshow, embedded video block, accordion content, or another that is an entity reference field to related articles, and one more that is simply a text area field. With this toolkit of content patterns your content creators can build content in any array of patterns they wish.

Paragraphs will satisfy the creative control that the editors of your site desire and will make them finally admit that they too hate that weird little wysiwyg field. When the situation arises that they want to do something new, it’s just a small revision to create a new paragraph type. Your frontend developers and designers will also be happy that they can strictly control the visual aspects of the individual Paragraphs with specific template files and targeted SASS styling.

Extending the Concept

An overlooked but very powerful use of Paragraphs is using it without any fields at all. Let's say that you want to add a newsletter signup form in the middle of your article. Simply define a paragraph called Newsletter signup then with a bit of custom code write a signup form, you could even have it automatically pass the signup source of the article in a hidden field. Next, all the article writer needs to do is drop the Newsletter signup Paragraph wherever they want it to appear within the article content. Another example of a field-less paragraph that we have used in the past is an about the author section. There are no fields needed, just add the paragraph and write code to look up the article’s author and write a template file to display a bit of author info with a headshot, simple as that.

I could write on and on about the possibilities and use cases for paragraphs, but you should really just download it and give it a test drive. It’s like introducing a mini block system into an individual article of content. If you are planning a new build or have an existing Drupal site, don’t hesitate to add Paragraphs. Your content creators and editors will love you for it.

Oct 10 2018
Oct 10

image of team working to put pieces of a puzzle together The reality is that running a business is such a diverse and complex endeavor that managing complex and rapidly evolving software solutions needed to execute the mission can be an overwhelming component. It already takes enough energy and expertise to be proficient in managing people, knowing your vertical, regulating cash flow, envisioning new products, evaluating old products, and on and on and on. The problem, however, is that if you don’t leverage complex and rapidly evolving software solutions to handle processes, you end up drowning in inefficiency and inconsistency. So therein lies a significant and difficult problem because you likely didn’t get into business to become an informal senior software architect. And that’s where leveraging something like a robust CMS comes into play. 

Let’s look at some of the ways leveraging a modern CMS, like Drupal, for example, can significantly streamline your business and free you to, well, run your business.

CMS is more than a CMS 

So in simplest terms, a CMS is a Content Management System. Historically, that basically meant providing standard functionality for perhaps managing blog content for a public website. The truth is, however, today it’s far more than that. There’s a whole range of CMS options that vary from that ultimately simple blog scenario to enterprise level development frameworks upon which you can build nearly any kind of web-based software solution. So in its infancy, it may have been largely all about getting a simple “brochure” site up with some basic management, but today it’s being used to provide some of the most sophisticated enterprise web solutions that are critical to modern business strategy. And in many cases, it’s leveraged internally to empower the management of the business in a highly effective and efficient manner. We’ll cover some more tangible examples in a minute, but first we need to get an important question out of the way. 

Which CMS? 

A CMS is a broad-ranging category of systems, and there is still a ton of flexibility in choosing a CMS. In fact, we’ve written articles on this topic and built a little tool to help you figure that out. The different management systems cover a wide range of use cases, so it can be difficult to determine which is right for a given situation at times. There are a number of extremely simple CMS setups that can work great on a low budget, with very flexible requirements, and without needs for complex solutions like custom integrations. On the other end are systems like Drupal (our CMS framework of choice) that allows you do virtually anything you want as well as continue to leverage a whole lot of components included in the core system or built by those extending the system in powerful ways. It’s this latter category of enterprise-level customizable CMS that we will focus on here because that’s where the exciting power lies.

 Which CMS is best for your website?  Take our CMS Quiz and find out!

Real world scenarios

Let’s look at some specific examples of just what these systems can do. And this isn’t hypothetical. These are exactly the types of solutions we’ve built for our clients with an extensible CMS platform like Drupal as our starting point.

Employee collaboration

Email. Chat. Documents. Meetings. There is a lot of internal chatter and management that goes on within a corporation, and the magnitude of the management of that cannot be overstated. Who hasn’t found themselves almost daily wanting to just disconnect from the internet for 20 minutes to take a breather from all the chaos swirling around? Well, the right CMS can mitigate a lot of that. You can use a whole host of building blocks to build an employee portal where coworkers can chat, send notifications, collaborate on policy documents, receive corporate notifications, see a team calendar, reserve a conference room, assign tasks, etc - all with deep tracking and revisioning and all within one ecosystem that is accessible from the desktop, the laptop, and mobile devices. With this strategy, you find yourself having a whole different experience. No more depending on how different people like to store and organize their local copy of largely outdated documents. No more relying on email history to track a decision that was made or find a digital asset. No more walking around the hall looking for an empty conference room. No more being stuck solving an accounting problem because that person is on vacation and has a local spreadsheet on their laptop. Best of all - everyone uses the same tools and those tools are managed from a single infrastructure. Sounds great, doesn’t it?

Client management

Let’s be honest - managing clients is often more difficult than managing your own workforce because your clients aren’t in your building, on your schedule, or under your control. There are countless phone calls, emails, shared documents, meeting decisions, deadlines, and other elements that can make it easy to lose sight of the forest for the trees. And it can be overwhelming to manage and well, frankly, quite embarrassing when something slips through the cracks or someone who needs to know isn’t in the know.

A CMS based solution can provide a platform to minimize and consolidate client management needs into a system that depends far less on individual availability and manual process and allows for a much more robust client relationship. Using a CMS as a platform, you can build systems that allow sending an invoice in a few clicks, with automated reminders and tracking of unpaid invoices. That same system can allow clients to track progress on major requests, and send or request updates. It can also run reports on product subscriptions that are set to expire, or highlight clients that are typically late paying their bills, or prioritize requests that haven’t been responded to in the past x days. It can also allow clients to pay their invoices online, engage live chat support, access help documentation, or receive alerts about upcoming products - again, all tracked in a single ecosystem and in full view of everyone in your business who needs visibility of some or all of the client engagement. It can literally transform how things are done and has huge ROI potential because it literally may save you from losing clients and make the ones that stay happier.

Content or product management

So what about managing the products or services your company actually provides? A CMS can do that too. It might mean allowing those who manage the warehouse to manage inventory, which is immediately reflected on the public-facing ecommerce site. Or it might mean serving, tracking and reporting online ads. Or it may mean providing a robust content management workflow for new stories and white papers that you offer your customers. And it all can leverage the same building blocks for tracking, notifications, document management, user roles, and permissions, etc., that a modern CMS can provide. Better yet, multiple CMS systems can even be built to talk to each other so that perhaps your Client Management system can get info about products your client has purchased from your Product Management or your Employee Collaboration system can be told to set follow-up reminders for your employees based on the activity of their clients. Or maybe all of these systems are really just one system that gives appropriate access to all who need it. The possibilities are endless.

So where do we go next?

So we’re only scratching the surface here, but if you have a heavy dependence on manual processes, or a lot of duplication of effort, or a difficulty tracking all the moving requirements, conversations or documentation - then a robust software solution built upon a CMS could be a key opportunity to making your processes more efficient and effective and allow you to focus on building your business, not running your business. The web today is not the web it even was 5 years ago so taking the time to see what’s possible can really change your whole perspective on how your business can function. Exciting times!

image with text offering access to our free CMS Selection quiz.

Oct 03 2018
Jay
Oct 03

drupal 8 logo in spotlights

Although it can sometimes be easy to forget about that little URL bar at the top of your browser, what it contains for each page can be surprisingly important. Creating good paths (the part of the URL after the domain name) for your site content can have numerous benefits, especially for SEO, but doing so can be a bit frustrating. Usually, you end up needing to re-type most of the page title into Drupal's URL alias field, which isn't necessarily too bad on its own, but it's still an extra step whenever you create content. And what about when you update the page and change the title? This is where it gets very easy to forget to change the path, which can lead not only to worse SEO but also to your site's visitors not ending up on a page with the content they expected it to have.

Fortunately, the Pathauto module makes all such worries a thing of the past.

This module adds a whole host of new options to how you can configure Drupal's paths, perhaps the most important of which is path "patterns". Patterns allow you specify what you want your paths to look like for different pieces of content; for instance, if you have a site where each of its users can have a blog, you could set up a pattern for Blog nodes such as "/blog/[node:author]/[node:title]". Then, whenever a user creates a blog post, it will automatically be given an alias which includes their username and the title of the post, and it will even update the alias if the user edits the post to change its title.

If you already have a site which has inconsistent aliases, Pathauto can also be used to bulk generate new aliases for your content, which is also quite helpful if you ever decide you want to change the structure of your paths. The module also offers plenty of settings to configure exactly what the paths it generates look like, including the ability to use a wide range of tokens provided by the Tokens module.

Finally, Pathauto also integrates with the excellent Redirect module. If you have both modules installed, changing the title of your content won't just change the path, it will also create a redirect from the old path to the new one so that any links already out there to the old URL will continue to function as expected. This is a rather important bit of functionality, and thanks to Drupal's great selection of contrib modules, it's just a few clicks away from being set up and working on your site.

New Call-to-action

Sep 28 2018
Jay
Sep 28

Previously, we covered some simple tips that allow you to get more out of Drupal and I think we covered some basics. This time we are going to go a bit deeper to see what Drupal can really do. In the right hands, Drupal can be a very powerful tool for more than just content management. The following tips will take you through a few different topics to get more out of Drupal than ever before. Some of these tips are a bit more on the advanced side, but they are very useful.

Tip #1: Don't be afraid of caching

If you are at all familiar with website caching, then you know at least two things about it. It is useful for getting your pages to load faster, and it can be very complex. Caching is meant to speed up your site by putting your page together just one time and then simply redisplaying that rather than needing to build it anew every time. However, because of this, when something about how that content should display changes, that particular entry in the cache needs to be "invalidated" so that it doesn't continue to be used, which could result in it showing content that is no longer current.

Fortunately, Drupal 8 has a fantastic caching system, provided by two modules which are included in Core: Internal Page Cache and Internal Dynamic Page Cache. The former caches entire pages for users who aren't logged in, while the latter caches the individual components of pages (such as blocks and rendered nodes) for all users. On most Drupal sites, these should both be turned on. Drupal Core and most contributed modules are built with this caching already in mind, so it's easy enough to just turn on the modules and get a nice performance boost from doing so.

If you have lots of custom code which deals with how content renders, this may not be quite so simple, but it is still something worth looking into, especially if your site sometimes feels a bit slow.

Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

Tip #2: Remove modules you don't need

Drupal, by default, usually comes with a whole suite of modules installed, some of which not every site needs. These include, for example, the Tour module (for creating tutorial-style interfaces which highlight certain parts of your site in) and the Search module (which provides Drupal's default searching mechanism and is useful only when your site doesn't warrant a different search solution). If you don't actually need a module, uninstall it, and if it is a contrib module rather than a core module, you can then remove it from your site's code entirely.

Every unnecessary module you have on your site can add clutter to the admin UI which makes it harder to find the things you actually want, and since each module can have its own potential security risks, uninstalling the ones you don't need can even help improve your site's security and stability.

Other core modules which are good candidates to consider removing are CKEditor (for sites which don't need WYSIWYG content), Color (for when you're using a custom theme and don't need to change its appearance through the UI), and Comment (if your site doesn't allow users to comment on content anyway). And that's just core modules in the C's!

Just be careful not to uninstall modules such as the Internal Page Cache module, which may not be specifically required to provide the site's intended functionality but which are important for keeping your site working smoothly. Consider each enabled module individually (and then, do the same with enabled themes!) 

Tip #3: Use the latest version of PHP

Drupal is written in PHP and is designed to take advantage of the new features and performance improvements provided by its latest versions. Although Drupal 8 can run on PHP versions as old as 5.5, it is now optimized for and fully compatible with PHP 7.2, and so a simple PHP version update can be a great benefit for your site's speed and reliability. You can check which PHP version your site is on from Drupal's Status report, and your hosting provider should provide a way to upgrade PHP if necessary.

Important: Versions of Drupal prior to 8.5 are only compatible up to PHP 7.1. If you're on Drupal 8.4 or older, you should be sure to update Drupal (which is an important thing to do anyway to get all of its latest features, bug fixes, and security updates) prior to switching to the new version of PHP.

Tip #4: Manage config the Drupal way

We've spoken a bit before about configuration management in Drupal 8, but it's important enough it's worth mentioning again. Back in the Drupal 7 and earlier versions, deploying changes to a site typically involved recreating a whole bunch of "clicks" in the user interface, to arrange fields and blocks, API settings, user roles and permissions, and pretty much any other aspect of the site's configuration. Drupal 8 makes that a whole lot simpler with its configuration management system. Although managing config can get quite complex for some sites, for most it is simple. Once you've made a bunch of changes on your development site that you want to roll out to live, you can export those changes into a zipped collection of YAML files. You can then upload that zipped file directly to your live site to import the changes, or save the YAML files into your codebase and roll them out alongside your code changes. We prefer to use the latter method since it also has the benefit of keeping your config in your version control system, but either method works fine, and a direct upload of config can be a bit simpler to manage.

Tip #5: Join the community

Drupal is open source software and is built by a large community of developers and designers from across the world, and joining that community by signing up for an account at drupal.org can result in some tangible benefits for your site. One easy benefit of this is that if you come across a bug in Drupal or one of the contributed modules you are using, or even if you just find that some feature you'd like it to have is missing, you can post a message in the drupal.org issue queues to get a discussion started with the very people who can make the sort of improvements you want. Often, if you search the issue queues, you may even find that somebody else has thought of the same thing you have, and there might even be a patch already available to give you the functionality you want. 

If you've had to create any custom modules or themes for your site, and they may be the sort of thing other people may find useful as well, it may be good to consider contributing them. If other people start looking at and using your custom modules, they may find ways to improve it and may even submit patches to fix bugs or add new features. Then it's easy to update your module with their recommendations, making it even more useful both for you and for the rest of the Drupal community.

There you have it. Five more tips to get the most out of Drupal. Some of these might seem obvious, but they are some big wins you can make for yourself and your website. We’ve been working with Drupal long enough that some of these seem like second nature and in time they may also be that way for you. Stay tuned for more Drupal tips in the future!

Offer for a free one-hour consultation, make you next project a success

Sep 19 2018
Sep 19

Spotlights shining on the Drupal 8 logo

Webform in Drupal 7 was always one of the top 10 must-haves on any Drupal site. Then Drupal 8 came along, and Webform wasn’t in the picture at first. Luckily, Drupal 8 came with the contact module in core that took care of most form needs, and we lived without the Webform module.

In the meantime, Drupal contributor Jacob Rockowitz had been working on the YAML Form module, which was a module used to define webforms in YAML files. At some point towards the end of 2017 YAML Form switched to the Webform namespace and Webform in D8 was born.

The Drupal 8 version of Webform will feel familiar to those with experience in the Drupal 7 version, but this is a completely new module and code base. It’s a really great tool for content creators to use, by giving them the ability to create complex forms without having to worry about code. However, as a developer, I found it tedious to create long forms through the Webform UI. Those days are in the past now, since Webform is a descendant of the YAML Form module, you still have the ability to define a form using YAML in the source tab of the build screen.

Screenshot showing direct editing in YAML

Direct editing in YAML really speeds things up for developers, and content creators can still use the UI to create and edit. It’s the best of both worlds.

The Webform module in Drupal 8 is such a powerful and fully featured form builder, that it could be reason enough alone for some site owners to switch to Drupal 8. If you run a site that is in need of new or dynamic forms on at least a monthly basis, then Drupal 8 + Webform would be a lifesaver and a budget saver. Personally, I find that Drupal 8 with Webform rivals any of the standalone form building tools available. There are dozens of features and settings that you get out of the box, and it’s easily extendible if you need to integrate with an outside service.

Like most things in Drupal 8, webforms created with Webform can be exported and synced as config. Webform also plays nice with Features if that’s your thing.

We still custom build many forms in Drupal 8 using the Form API, but Webform is a great tool to keep in mind when things need to be editable by administrators or when you just need a simple solution. It already deals with storage, email, and so many other things out of the box. If you have any webform needs, don’t hesitate giving Webform a shot.

Sep 14 2018
Sep 14

Illustration showing multiple components of an SEO strategy 

Drupal has a bunch of great SEO tools. Here are several tips and suggested modules for fine tuning SEO within Drupal. Easy SEO wins can be achieved through configuring metatags and URLs. Don’t forget to setup an XML sitemap of your site and submit to major search engines. SEO isn’t a once and done effort, make sure to constantly research and update with search trends.

Yes, but is it good for SEO? This is a question we hear all the time when we mention all of the wonderful capabilities of a Drupal site. First off, let's dispel the myth that there is a CMS that automatically does magical SEO and makes all of your pages rank higher in search. If you want good SEO, the most important thing that you can do is write good and unique content that humans actually want to read. The CMS or web software has nothing to do with it. So let's assume that you already have great content and semantically perfect markup, there are tons of other little things that you can do to further boost your content in the eyes of search engines and Drupal is a great tool for implementing them.

To get the most out of Drupal SEO, you are going to want to download a couple of contributed modules from drupal.org.

The following is a list of our goto modules for SEO that I am going to talk about in this post:

Using Metatags to Help Search Engines

Metatags are important for search engines to index, categorize, and understand the content of your webpage. There are a lot of different metatags but a couple that really matter for SEO are the meta description and the title tags. Meta descriptions can be used as a summary in search engines, so it is important to write some compelling content here. It’s the first pitch to a potential site visitor so you may want to put a little thought into it. What if you have hundreds or thousands of pages on your site? The Drupal contributed Metatag module provides a way to dynamically set metatags based on content type, or on other content rules you may have. Working with the Token module you can have all of your metatags, including the description, generated based off of your content. For those pages that you are really trying to squeeze the SEO juice out of, Metatag allows you to override for when you need to fine tune things.

Which CMS is best for your website?  Take our CMS Quiz and find out!

If you want to take things further with metadata, you can also install the Schema.org Metatag module which extends the base Metatag module. You can read more about the Schema.org project here. In a nutshell Schema.org is making a push for people to further define what kind of content they are writing by breaking things into categories of content that a search bot can read. The types of content that they have defined is very granular with deep sub categories. Check them all out here. Having Schema.org metadata, can give you a leg up on your competition as more devices and services start reading and prioritizing web sites based on this content categorization data.

URLs Should be Informative and Human Readable

Having URL paths that make sense can go a long way for SEO. Search engines are able to parse relevance from the words in a URL. For example a URL that is “example.com/node/34” gives no information as to what the topic of the page is. Alternatively, this URL “example.com/store/shirts/blue-shirt” can tell a lot more to a search bot. The Pathauto module enables you to make descriptive URLs. Similar to the Metatag module, you can use this with the Token module to automatically build new URLs based on the type of content you are creating. These are referred to as “patterns” in the Pathauto module. Paths generated by Pathauto can also be changed on a one by one basis, so you can overwrite the generated name in favor of a custom one.

Another useful module related to URLs is the Redirect module. The redirect module does a handful of useful things. Every time you go and change a URL, the redirect module will create a 301 redirect from the previous URL to the new URL. This is helpful when you are updating a page that may have been bookmarked or linked to elsewhere. 301 is the status code that a web server sends when a requested page has been moved and tells the browser to redirect to the new page. 301 redirects are essential to having good SEO, search bots give a poor evaluation to sites with a bunch URLs that go nowhere and humans don’t really like it either.

The Redirect module also comes with a really handy utility page called Fix 404 pages. 404 is the status code that a web server sends when a requested page doesn’t exist. We have all seen these annoying messages from time to time. Sometimes the page has been deleted and sometimes it has simply been renamed and moved, with a 404 message there is no way to know where the page you are looking for is and will leave you thinking that maybe you just visited the page in a dream. The Fix 404 pages utility gives you a report of all of the 404 URLs that your site is sending, it also tells you how many times a URL has been tried and the last time someone tried to go there. This report gives you the opportunity to add a redirect for those 404 URLs and send those users to a relevant page. This is a big boost for SEO because 301 > 404 in the eyes of a search bot.

Provide a Sitemap to Better Direct Search Bots

Search bots work hard, 24/7 365 days a year they are out there crawling the web to make your search experience better. So make it easy on them and provide a roadmap for traversing your site. This is done with an XML sitemap. An XML sitemap is simply an outline of your site’s pages with priority and update frequency all wrapped up in the XML format. We typically build a custom solution for generating an XML sitemap, but there is a Drupal contributed module out there to help you do it without needing to know how to write XML. The XML Sitemap module allows you to configure your sitemap based on things like content types or menu structure. Once you have a sitemap, go ahead and give those search bots a jump start and submit it to the search engines. Each search engine has a different process for doing this, so make sure you submit to more engines than just Google, the XML Sitemap module has a built in tool for submitting to search engines as well.

Research and testing

Lastly, let's talk about Google Analytics and so I don’t have to write that out a bunch of times i'm going to refer to Google Analytics as GA. GA won’t do anything to help your SEO, but it is a crucial tool for analyzing how effective your SEO work has been. The Drupal contributed Google Analytics module makes it easy to set up on your Drupal site. A good SEO strategy is all about testing and adjusting. Make some assumptions about what topics or keywords you think will drive traffic to your site but don’t stop there. Turn your assumptions into tested data with GA. Your website should be a testing ground for new search words, as you see traffic spike up around a search term adjust the rest of your content to cater to those search terms. GA is currently the best tool available for tracking visitors on your site. With testing and study eventually you will land on the right terms and words to use so that the right people find their way to your amazing content.

 image with text offering access to our free CMS Selection quiz.

Aug 29 2018
Jay
Aug 29

Drupal, especially once you consider the many contributed modules available for it, is a vast system of open source software, and as with most such software, there are a lot of little things you can do to make sure you get the most out of what it has to offer. In this post, I'm going to go over a few such things and touch on how to make Drupal's admin interface more useful while also finding ways to improve site performance and stability.

Tip #1: Clean up your content forms with Field Group

It can be pretty easy to end up with a content type (or another type of entity) that has a whole lot of settings on it, and even if you organize the fields into a logical order, it can make the content forms a bit difficult to navigate. On most any somewhat content-heavy site, Field Group is one of the first modules we install. It allows you to group fields together in various ways, such as with a tabbed interface or collapsible fieldsets, and with it, you can have your forms better organized in no time. Your content editors will thank you.

Tip #2: Have a cup of Coffee (and Admin Toolbar) 

 

When it comes to making it easy to find what you're looking for in Drupal's admin UI, few modules compare to Coffee and Admin Toolbar (including its Extra Tools submodule).

Coffee adds a "Go to" button to the admin bar which, when clicked, opens up a search bar similar to the Spotlight Search on a Mac. Then you can just start typing to find whatever admin page you might be looking for. For those of you who prefer using the keyboard over the mouse, there's also a keyboard shortcut to open the search.

The Admin Toolbar module modifies Drupal's existing toolbar to use a series of dropdown menus, making it easy to find the right page without needing go click through a bunch of screens to get to it, and it also adds some quick links to do common development tasks such as flushing caches and running cron.

Since Coffee and Admin Toolbar both are designed to make it easier to get where you want to go in Drupal, you may only need one of them, but it's worth giving both a try to see what makes your workflow fastest. 

Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

Tip #3: Send emails your users can trust

Many sites have to send out emails of some sort – whether it's just for simple password resets or a more critical part of a site's functionality. Drupal can send emails on its own easily enough, but unfortunately, (especially if your site is on a shared hosting environment), there's a decent chance that the email may be automatically get marked as spam. There's an easy fix for this: First, you set up an account with an email delivery service such as Sendgrid or MailGun, then you add the SMTP Authentication Support module to your Drupal and configure it with the credentials provided by that mail service. And ta-da – now your site's emails are all delivered by a trusted service. No more ending up in the spam folder!

Tip #4: Limit the size of your images

Large images can take a long time for your site's visitors to load, especially if they're on a slower network. If they're too large, this can result in your visitors seeing blank space while the image is still downloading. To avoid this, ideally, images should be exactly as large as they need to be, and no larger. There are several great ways to accomplish this without needing to load up Photoshop for every image.

First, before even uploading your image to Drupal, use a tool such as Compressor.io to compress your image. This step is especially important for most JPEG images and photographs.

Within Drupal itself, there are a couple of possibilities available to you. If you are uploading your images to the image field of nodes, you can set restrictions on the field itself, such as maximum dimensions for the uploaded file (and Drupal can even resize the image to fit if you upload one that is too large). You should also set an appropriate image style for the image wherever you use it, which can include things like automatic cropping and centering.

Tip #5: Update often

New versions of Drupal and its many contributed modules are being released all the time, often bringing with them stability improvements as well as brand-new features. For Drupal Core and most contrib modules, each individual update is easy to apply (especially if you use Composer), but the further out of date your site is the trickier updating it can be, so keeping on top of updates means that updating stays simple. 

One other critical reason to keep up to date is that once in a while there are security updates necessary for Drupal, and if you're already on the latest version applying the security update is a fast and painless process. You don't want to end up delaying security fixes to the site because of difficulties in upgrading several versions at once. If you have a drupal.org account, it's worthwhile to go to your user account page and subscribe to their security notifications email newsletter so that you get alerted as soon as these important updates are released.

New Call-to-action

Aug 24 2018
Aug 24

Image showing the words Drupal Module Spotlight: Reroute Email“Excuse me, Mr./Mrs. Client, I’m so sorry but I accidentally just sent your 3000 users a fake purchase email receipt when I was testing.”

Ugh.

Big complex systems are a lot to keep track of, especially when it comes to email. There are emails for resetting passwords, emails for new users, email receipts, email notifications for workflows, etc, and it’s frankly a little terrifying to rely on yourself to remember all the implications of what’s going on when working on local environments, or test servers or anywhere but production. All you have to do to experience this pain is trigger an accidental FAKE email send to REAL people. 

That’s where modules like today’s spotlight comes in. 

We’re talking about the Reroute Email module, a simple plugin that allows you to override all outbound email sending and send them to a configured address, allowing you to both test that email content is working but not have to apologize to all of your users.

Installation is simply turning the module on and then going to the configuration page at /admin/config/development/reroute_email. From there, you can set the rerouting email addresses and even set whitelisting emails that are permitted to pass through the reroute.

Reroute email module screenshot

This is helpful for situations where you want to use test emails for specific purposes and you want the emails to go out as they will in production without having all email functionality enabled on your site. Pretty great. Lastly, you can even enter module key patterns so that emails coming from particular modules are the only ones being rerouted. Very flexible.

And a special note: On many of our sites, we set the config for the module in the local settings files for each environment so we can ensure, for example, that local or test environments never send real emails even if we pull code or refresh the database from production. It’s as simple as the following lines of code:

$config['reroute_email.settings']['reroute_email_enable'] = TRUE; 
$config['reroute_email.settings']['reroute_email_address'] = '[email protected]';

So there you have it. A great module that trades embarrassment for confidence. (They really should put that phrase on their module page!)

Aug 15 2018
Aug 15

Business person looking at Drupal logo, deciding on a CMS

You may have heard of Drupal in passing, but you have not ever been given a straight answer on what it is and why you should care. The truth is that even if you have worked with Drupal, you might not actually know what to say when asked what it is. Looking around there doesn’t seem to be a lot of great answers to this question out there either. It would be difficult to tell if you need Drupal as a solution for your website if you aren’t even sure what it really is to begin with. 

The Basics

To say we talk about Drupal a lot is an understatement. It’s non-stop Drupal all day long here at Ashday, but what is Drupal? Simply put Drupal, is an open source content management system. It's primarily built in the PHP programing language, and designed to create websites for use on a variety of different web servers.

Okay, but what is a content management system? A typical definition of a content management system or CMS is an application that is often used for creating websites that focuses on publishing workflows, user management, and content delivery. These dynamic and database driven websites usually allow for multiple editors and templating for streamlined content development. This is different than a plain old web page that is written in HTML and styled in CSS. A content management system allows you to compose and edit just the content without having to adjust the HTML. It makes it easier for non-technical users to publish text and images on the web to use that content in more than one place. With a CMS you can display your blog post on the homepage and in your blog, without needing to write the same content twice.

Which CMS is best for your website?  Take our CMS Quiz and find out!

What does it mean to be open source? Open source means that all of the core code that makes the software tick is free and open to view. Open source programs are typically free to download and use. They aren’t exclusively developed by one person or corporation and they rely on an open community of peers to maintain and improve the core code. This means that the software can be rapidly developed with a large pool of contributors. Another benefit of open source is the adaptability of custom code, since everything is open we can extend the core code to do more and behave based on the business needs of the project.

Other Popular Content Management Systems

There are many open source software CMS tools available on the internet. Drupal is often mentioned in the company of other popular CMS such as WordPress. It even gets lumped together with SaaS (Software as a Service) based site builders like Squarespace and Wix. While it's true that Drupal serves a similar role as a means to building websites, it is far different from these other systems. WordPress for example, is primarily a blogging platform but people have stretched it far beyond its intended use. Because of this, complex sites built with WordPress often consist of a lot of custom code of varying quality. Drupal’s real contemporaries are more along the lines of a framework like Laravel. These frameworks are much more customizable and robust, but often lack the pre-built setup of users, content types, and management features. This results in a much longer time to market for projects built on a bare framework.

What are the use cases for Drupal?

Drupal is best suited for building websites that are medium to large in size with a focus on future scalability. That isn’t to say that Drupal can’t be used for smaller sites, it does fine for this sort of thing all of the time, but it is built to handle much more and can incur more overhead than is necessary. It is a bit subjective to use terms like medium and large for a website, but when we think of large we typically mean websites used for enterprise applications.

Drupal is great at storing, managing and delivering huge amounts of content. If you have a lot to publish, then Drupal can’t be beat. The admin interface allows for creation of custom management tools that make the whole publishing workflow tailored to how your business runs. Drupal is built around being able to have many levels of users with defined roles. Permissions can be fine-tuned to create a system with a publishing workflow that won’t slow down content creators and will save time for editors and curators.

In the world of web apps, Drupal is king. Drupal 8 is a very extensible framework capable of integrating with the vast ecosystem of services offered across the internet. If you need to build a product for others to connect to, Drupal is a great choice with its core RESTful API. The object-oriented framework within Drupal makes creating large-scale applications inexpensive with a reasonable timetable.

Why do organizations choose Drupal?

Large organizations both corporate and non-profit trust Drupal to run their sites and applications. Drupal has earned this trust through its open source community that provides contributed modules and timely core updates. The security team, which is world class, keeps Drupal a bit safer by finding and writing patches vulnerabilities before they can become a problem. Part of the Drupal community is the Drupal association that pushes cutting-edge initiatives to keep Drupal modern, innovative and thoughtful.

The large open source community behind Drupal provides thousands of modules to extend the core functionality of Drupal, all for free. Contributed modules are reviewed by the community and given a stamp of approval if they are stable and safe to use. This is very different than many other open source communities where contributed code can be malicious or come at a cost. When you use Drupal and its contributed modules, you are benefiting from the hundreds of thousands of development hours from a giant group of developers across the globe.

How do I start a Drupal project?

Drupal can be used to run just about anything you would want on the web. Because of this flexibility, Drupal doesn’t do a whole lot on initial install without more configuration and setup. This is not a simple task for the amateur site builder, Drupal is not known as the easiest of the frameworks to learn. If you are building a medium to large site or a web application, you may want to hire professional web developers with the right technical skills. This can be accomplished by an internal team of Drupal developers or outsourced to a Drupal development agency. Check out this article we wrote to help you determine if you should build with an in-house team or outsource. 

Popular examples of Drupal websites

You have most likely seen or used a site built on Drupal and didn’t even realize it. There are a lot of very influential sites out on the web that leverage Drupal to deliver content. Here is a small list of those:

ncaa.com

Harvard.edu

Taboola.com

ed.gov

economist.com

Billboard.com

Drupal is very popular in higher education with many universities and colleges running their sites on Drupal 7 & 8. Drupal also has a large share in local government sites and in the publishing industry. Drupal is everywhere you look but its flexible structure allows it to power a variety of types of sites while being invisible and allowing the content it serves to be visible.

 image with text offering access to our free CMS Selection quiz.

Aug 03 2018
Aug 03

If you haven’t heard of the phrase “Natural Language Processing” by now, you soon will. Natural Language processing is an expanding and innovative use of technology to analyze large amounts of data or content and derive meaning from it, short-cutting a tremendous amount of manual effort needed to do that ourselves. It’s been around in some form for quite a while, but it was often relegated to complex enterprise systems or large corporations with a vested interest in automating the data mining of huge amounts of data to figure out what the patterns were, for example, in consumer purchasing trends or social media behavior. It’s a cool idea (it’s a form of artificial intelligence after all) and fuels a lot of our online experience now whether it’s product recommendations, content recommendations, targeted ads, or interactive listening services like Siri or Alexa. What’s even better is that this sort of thing is becoming more and more accessible to use in our own software solutions as many of these now provide services with APIs. This allows us to provide a more personalized or meaningful experience for site visitors on web projects that likely don’t have the budget or requirements to justify attacking natural language processing itself and can instead find accessible ways to benefit from the technology.

One such use case that we’re talking about today is using the Google Natural Language Processing APIs on our own Drupal sites. We can use it to analyze our own site content and even autotag based on a common taxonomy. We really dig integrations here at Ashday, so we’ve just released two new Drupal modules to help you get hooked up with Google’s service. They are the Google NL API and Google NL Autotag modules.

The Google NL API Module

This module is intended to be your starter module to get things going. It provides functionality to connect to Google's Natural Language API and run analysis on text, including sentiment, entities, syntax, entity sentiment and content classification. It doesn’t decide what to do with this analysis, but it provides a service with a number of methods to analyze your content and then you can decide what to do with the information. All you need to get going is a Google NL API account. Full details of installation and usage can be found here.

Here is a brief outline of what each method provides, provided by Google.

Sentiment Analysis

“Sentiment Analysis inspects the given text and identifies the prevailing emotional opinion within the text, especially to determine a writer's attitude as positive, negative, or neutral. Sentiment analysis is performed through the analyzeSentiment method.” (from Analyzing Sentiment)

Entity Analysis

“Entity Analysis inspects the given text for known entities (proper nouns such as public figures, landmarks, etc.), and returns information about those entities. Entity analysis is performed with the analyzeEntities method.” (from Analyzing Entities)

Syntax Analysis

“While most Natural Language API methods analyze what a given text is about, the analyzeSyntax method inspects the structure of the language itself. Syntactic Analysis breaks up the given text into a series of sentences and tokens (generally, words) and provides linguistic information about those tokens.” (from Analyzing Syntax)

Entity Sentiment Analysis 

“Entity Sentiment Analysis combines both entity analysis and sentiment analysis and attempts to determine the sentiment (positive or negative) expressed about entities within the text. Entity sentiment is represented by numerical score and magnitude values and is determined for each mention of an entity. Those scores are then aggregated into an overall sentiment score and magnitude for an entity.” (from Analyzing Entity Sentiment)

Content Classification 

“Content Classification analyzes a document and returns a list of content categories that apply to the text found in the document. ” (from Classifying Content)

The Google NL Autotag Module

This module is the first step in actually doing something with the natural language analysis results provided by the API module. It provides a Google NL Autotag taxonomy that you can attach to whichever content types you choose and then will automatically create the relevant taxonomy terms and relate content whenever that content is saved. So a few clicks is all you need to have a nice auto-classification system in use on your site. You can even configure which text-based fields on your content should be used for the analysis as well as specify the confidence threshold, which determines at what confidence level you consider a Google classification as valid. So Google may say that the content matches the category /Home & Garden/Bed & Bath/Bathroom, with a confidence of .4 (on a scale of 0 to 1). You can decide what confidence level is good enough to categorize your content since different use cases may justify different approaches. A full list of Google’s content categories can be found here.

That’s all this module essentially does, but it’s meant to be a simple solution for sites to easily start benefiting from Google’s natural language services. You can, of course, extend the service or add your own functionality to use these APIs however you find beneficial because it’s Drupal 8, and Drupal 8 rocks when it comes to flexibility. So install these modules and start tinkering and don’t hesitate to ask if you have any questions or suggestions for future functionality.

Jul 27 2018
Jul 27

Five Drupal Features essential to the publishing industry.

If you are in the publishing industry, you already know that Drupal 8 is by far the most useful CMS for publishers. It was great in Drupal 6 & 7 and with 8 it keeps getting better with each major release. Combined with the community contributed modules, Drupal 8 is the best platform for publishers yet. Here are five features in Drupal 8 that are essential to publishing.

1. Workflows

Moderation of content is crucial for quality when you have a lot of authors across multiple platforms. Drupal 8 has that solved out of the box with the core Workflow and Content Moderation modules. Check out this short post we did on Workflows in Drupal 8 core here for more info. Your CMS workflow should match your internal publishing workflow. Drupal 8 can automate most manual processes that you currently have. This is a prime example of getting your CMS to do some heavy lifting within your organization.

2. Integrations

Drupal is a fantastic framework for integrations. In the publishing business, you are going to require a decent amount of integrations. Google Tag Manager, Doubleclick for Publishers, HubSpot, and SalesForce just to name a few. Drupal’s object-oriented framework allows for integrations to be built quickly and efficiently. Plus, they can be custom tailored to your business needs. Many other popular CMS and site-builders are limited to the available integrations and options. Drupal is an open framework that can be custom built to do just about anything you need.

3. Content Management

Organizing, managing, and scheduling content is key to a successful publishing site. Drupal 8 builds on top of the fantastic content management system started in Drupal 7. Custom admin tools tailored to your business can be built on the fly using the core Views module. With custom tools you can build admin pages for any type of content you wish. You can even make an admin screen for niche needs. For example, if you want an admin screen for articles that were published in 2012 that were about cats, you can very easily make one. Content admin tools have the ability to be built around the permissions of the different roles in your organization. You can fine tune what access and permissions your editors, authors, admins, or others can have. This is all out of the box functionality in Drupal 8 and requires no custom code.

4. Asset Management

Like content management, asset management is fantastic in Drupal 8. Assets are treated much in the same way that content is. When I say assets I’m loosely defining them as any reusable element. Images, video, audio clips and other files are obvious assets, but you can also create some more obscure assets like tweets or Instagram posts. Assets are fieldable, so you can add additional data for display and categorization. Using the core Media module, you can manage all of your assets. Custom libraries can be created as well as custom selection widgets that are restricted to specific types of assets. This can be a huge timesaver for assets that are commonly used across many authors.

5. Web Services

Drupal 8 comes with a RESTful Web Services API in core. To put it simply, a RESTful web service can be a conduit to send your content from Drupal to another system like a native app. This can jump start a “publish once distribute everywhere” content model. For publishers this can be essential for content control and efficiency. There is an API first initiative actively going in Drupal 8 development which is pushing for new features in each version release. Besides the out of the box RESTful Web Services API, there are several contrib modules that include JSON API and GraphQL. These web services are also what gives Drupal the ability to go headless and communicate with a JavaScript front end such as React.

Drupal as the hub to a publishing ecosystem

We will cover more on this in the near future, but these 5 things really prove why Drupal 8 is a first class CMS for the publishing industry. Drupal 8 combined with great content, is a killer recipe for a successful publishing site. The out of the box features of Drupal 8 will save you time and money. If you are a publisher who is constantly struggling and fighting with your website, it’s time to give Drupal 8 a look. 

Offer for a free consultation to determine if Drupal is the right choice for your organization

Jul 25 2018
Jay
Jul 25

 image of spotlights focused on drupal logo

It is essential that content be well-categorized, especially on large websites. Drupal includes the Taxonomy module for doing just this, and it is able to account for most content tagging scenarios. However, when you actually go to categorize content, it can be a bit confusing.

Drupal offers a helpful autocomplete, but this doesn't always work as well as you might hope if you have a taxonomy tree which includes nested terms (for instance, "Cats" as a subtopic of "Pets"). In fact, the autocomplete doesn't show the hierarchy of these terms at all, which can get confusing if you have multiple terms with the same (or similar) names which are children of different terms. And although Drupal allows you to create new terms right from the content editing page, doing so always causes it to create the new term at the topmost level of the taxonomy, which often isn't where you actually want it.

What is Straw?

Enter Straw - the Super Term Reference Autocomplete Widget. We built Straw when we were working with a multilevel taxonomy and found that Drupal's default widgets just weren't cutting it. Now, we've made Straw available as a module for anyone else who might find themselves in a similar situation. Straw does two main things which make working with these taxonomies a breeze.

Find Matching Content Tags

First, both when displaying a selected term on the edit page and when searching to find matching tags based on what the editor is typing, the Straw widget shows the entire hierarchy of terms. That means that instead of simply showing "Cats", it will show "Pets >> Cats", and if you start typing "Pets" it will show both "Pets" and "Pets >> Cats", rather than only showing "Pets" like Drupal's default autocomplete would. This makes it much easier to see which exact term is being matched, and also makes it easier to find sub-terms if you don't quite remember their names.

screen shot of Drupal Straw Widget

Create New Terms

Straw makes it a breeze to create new terms on the fly. Say you're writing a new article for your site about a particular breed of dog, but so far your taxonomy only has terms related to cats. Without Straw, you could type in "Beagles" and it would create a new term of that name, but then you'd have to go to your taxonomy tree and create a "Dogs" term beneath the "Pets" term and then move "Beagles" into it. With Straw, this is much simpler… you just type in "Pets >> Dogs >> Beagles", and it creates all the necessary terms and puts them in the right place in the taxonomy relative to each other.

With Straw, tagging your content can be easier than ever before. It's easy to install (with only a little bit of configuration required) and then you'll be able to see right away how much of a difference it makes.

Offer for a free consultation with an Ashday expert

Jul 20 2018
Jul 20

Illustration of workflow concept

Did you know that setting up a content workflow is included in Drupal 8 core? It can be easily set up by simply turning on the Workflow and Content Moderation modules. The Workflow module gives you the ability to define a workflow and the Content Moderation module sets up a simple workflow for drafts and the ability to create more content moderation workflows.

Introduction to Content Moderation

If you aren’t familiar with content moderation in Drupal, let’s fix that with a quick overview of what that means. Without this module, Drupal content can only be in one of two states, published or unpublished. The content is either available to the public or it isn’t. Different users with different permissions can manage the publishing status certain types of content. All of this combines to make a pretty useful and normal experience. This should also seem like a normal experience for anyone that has ever used content management system.

Where the Content Moderation module comes in is when this workflow needs to be more than just on or off. This can allow for content to be placed into different statuses or states. With built-in states available, like Draft, content can be staged by one editor and then approved by a user with different permissions. In the publishing world, this matches workflows that exist for paper content, so this is an attractive feature for those in that vertical.

Set up in 5 minutes

Content Moderation in core provides a very simple but useful workflow. Simply turning on the Workflows and Content Moderation modules adds the Editorial workflow. The Editorial workflow adds the Draft state and sets up the content workflow to go from Draft to Published and provides an admin view for drafts that need to be moderated. Using permissions you can restrict authors to only be able to create and edit drafts. Then grant the "Transition drafts to published" permission to your editors and boom!—you have content moderation set up in a matter of minutes.

View of content moderation in Drupal core

 

If you are running a Drupal 8 site and have multiple content contributors that need feedback, there is little reason to not use moderation. The out-of-the-box Content Moderation should be able to handle most situations. If that doesn’t quite fit the needs of your content workflow then there is still good news, you can create a custom workflow.

Custom workflows

If you need a more complex workflow, you probably still don’t need to write any custom code. If it’s just content type, block, or paragraph based entities that you are building a workflow for, you can just create a new workflow based on the "Content" moderation type. Different states can be defined, for example let's say you have the states draft, ready for review, ready for second review, reviewed, and published. Next you need to define the transitions, for example one transition for the above states would be “move ready for review to ready for second review”. These transitions are going to be what you give different user roles permission to do. After that is set up, you and your team are ready to roll with your new workflow.

Setting up a complex workflow in Drupal 8 Core

 

Another example of a custom moderation workflow could be for a site that publishes to multiple platforms. A workflow could be set up to allow the editors of different platforms to approve content onto the system they manage. Let’s say you have a front-facing site, a native app, and an internal portal. You can create a workflow that goes through moderation for the front-facing site and then adds content to a queue to be published or declined for each of the other outlets. This is just one of the many possible use cases for a custom workflow.

Illustration of workflow in Drupal 8 Core for publishing to multiple platforms

If you need to extend Workflow further, maybe for a custom entity, you can write a WorkflowType plugin that covers your needs. This can be used for any entity that needs to change states, so think beyond the idea of content moderation. It could be used for steps in a manufacturing process, or steps for ordering in a restaurant app, the possibilities are limitless.

Do you need it?

Workflows are super powerful and moderation comes mostly ready to go with Drupal core but does that mean you should always use them? On some sites with only a handful of admins and not a lot of roles, it may be more cumbersome than useful. Just because workflows are an option, it shouldn’t be implemented unless your users understand the human element of a workflow. Moderators should know their role in content moderation. If most of your authors have admin privileges and can just push content straight through the flow, then your workflow is mostly standing in the way of being efficient. Every good workflow should start with a meeting of your entire editorial team, and have things worked out on a whiteboard or Slack channel first. Workflows are amazing as long as everyone understands their role in the publishing chain. 

New Call-to-action

Jul 18 2018
Jay
Jul 18

drupal 8 logo featured alongside drupal logos showing the growth of Drupal

Now that Drupal 8 has gained some momentum, it is time to start planning out your upgrade strategy. You want to upgrade to get the latest benefits and take advantage of the future stability that comes with the direction that Drupal will be taking from here on out. Before upgrading you will want to consider some things about what your current site has. In this article we will be covering some of those questions with some context to assist in the decision making process. Let’s determine if you website is adequately serving the current needs of your business and which content will need to be brought over to the new Drupal 8 site. There may be a difficulty in the switch, but being prepared will put you in position to handle whatever comes up.

So, you have a nice Drupal 7 site that's been running happily for years, and maybe you're thinking it's time to upgrade – or, if you haven't given it much thought yet, there's certainly plenty of reasons to do so now. But, Drupal 8 is a pretty big step forward from Drupal 7. What exactly is an upgrade going to entail? What do you need to consider before you do so? We've upgraded numerous sites now, and today I'd like to go over a few things that I think are important to know before starting on such a project.

Before You Start

Just because you've decided to upgrade, doesn't mean that you can do it right away and be done with it by dinner. Unfortunately, there isn't any one-click solution to take your site from Drupal 7 to Drupal 8 (although future upgrades should be closer to reaching that level of simplicity). Here are a few things to consider before you touch the first line of code or content:

Do you still want the same site? Doing a large upgrade such as this is an excellent time to re-evaluate your site's functionality and appearance. Now that you've had it for some time, is there anything you want to change? Any new features you want to add that maybe weren't feasible before because of how the old site was built? Although upgrading can be done in such a way that everything stays almost exactly the same for your site's visitors, it's good to at least consider what potential improvements you could make, perhaps by leveraging some of Drupal 8's great new features. Maybe your site just needs a facelift, or has some long-standing bugs you want to fix, or you want to take advantage of new CSS or JavaScript technologies which weren't available when you first built the site. Upgrading is the perfect time to take a fresh look at things.

How are you migrating? One critical part of most upgrades is to migrate content and user information from the old site to the new one. Databases for Drupal 8 are structured differently than they were in Drupal 7, which means that to upgrade the site you can't just swap out the code while keeping the same database… you have to actually move the content into a new database as well and adjust it to fit Drupal 8's slightly different structure. This is a pretty big departure from how Drupal upgrades worked in the past.

There are two main ways to do this migration. Drupal 8 includes a Migrate API, which is perfect for some simple sites. However, not all contributed modules have the plugins necessary to migrate their data in this way, and any data you might be storing in some customized way certainly doesn't. Although it is possible to write your own plugins, in our experience it's easier to take a different approach by writing an entirely custom migration. This does however require having some more familiarity with Drupal coding than the Migrate API route does. Generally, what a custom migration involves is writing a script and appropriate queries to first retrieve your information from the old database, and then to write it to the new Drupal 8 database in the appropriate format.

Do you know enough Drupal 8? If your site is mostly built using core and contributed modules and themes, you'll probably be good to go. Drupal 8's admin UI does have some changes from Drupal 7's, but none of them are very difficult to get used to and most introduce new ways to navigate and improve your site. However, if your site uses much in the way of custom modules or if it has a custom theme, then before upgrading you should make sure your developers and themers are familiar with Drupal 8, perhaps by working on some other simple Drupal 8 project first or by getting some training on the changes, either in-person or through an online course. The changes in how you code custom modules and themes in Drupal 8 are significant, so they may take some getting used to, but ultimately they are the foundation of what makes Drupal 8 leaps and bounds better than its predecessor. Knowing how to use them effectively is key to having a Drupal 8 site that continues to be maintainable for years to come.

Still Not Sure You're Ready to Upgrade?  Learn more about the benefits and our upgrade process. 

What to Expect

Alright, so you've gotten everything figured out. All that's left to do now is to, well, actually upgrade the site. Here are a couple of things you should plan for when starting most any upgrade.

Expect to have a few difficulties: Even if the upgrade seems like it will be a simple one, you should go into it expecting to have a few unexpected challenges come up, because they almost certainly will. Maybe it's one particular type of field that doesn't have the same settings in 8 as it does in 7. Maybe it's a combination of contrib modules which used to work together one way and don't anymore (one example: The Context module can no longer be used in conjunction with Metatags to set metadata in contextual circumstances). Maybe it's that your site uses a lot of different webforms, and although the submission data can get migrated without too much trouble, recreating the forms themselves can't be done automatically. 

Regardless of what it ends up being, plan to have some unexpected difficulties during the upgrade. In my experience, these challenges tend to be fairly easy to fix or work around through some combination of contributed modules and custom code, so although they can add some complexity to the upgrade it's rare to find a dealbreaker so late in the process.

Expect to have two sites for a little while: Your new Drupal 8 site is completely separate from your old Drupal 7 site, and that means that it needs to be installed somewhere other than where your old site is, and it probably has to have its own domain so you can access it during the upgrade process. You'll be able to keep your old domain though - once the upgrade is done and your Drupal 8 site is ready to go, all you should have to do is change your main domain's settings to point to the new website rather than the old one.

When you first start the upgrade, your Drupal 8 site is likely to be almost empty. If you have lots of custom modules to recreate or anything and the migration itself isn't done yet, then maybe it has some placeholder content to start with. Then, once the migration is done, all the relevant content from the old site gets migrated into the new one. At this point, your content and user information is being stored in both sites. It also means that, from now until the new version of the site launches, any changes you make to the content of the old site won't be automatically reflected in the new site and will be lost when you deploy the upgrade. For many sites, this problem can be mitigated by having a period of time in which changes get made to both sites, instead of just to one of them.

Still, it isn't ideal to have to enter new content twice for an extended period of time, so to solve this, one thing we like to do is to actually have two migrations. The first migration happens early on in the development of the Drupal 8 site, and we use the content from that migration while finishing most of the upgrade. Then, shortly before the upgrade goes live, we do a "final migration" to get any changes which have been made on the Drupal 7 site since the original migration. If all goes well, this results in only a day or two (or zero!) during which changes have to be made in both sites.

Once the upgrade is finished and your domain name settings adjusted so that the new site is live, it's worthwhile to do one last check of the old site to see if there are any recent changes or user registrations that may have been missed. Depending on how your migration script works, these could be migrated again with that, or they could be replicated manually. Once that's done though, huzzah! Your newly upgraded Drupal 8 site is finally ready for the world to see.

 Offer for a free consultation with an Ashday expert

Jul 13 2018
Jul 13

Omeda and Drupal are a perfect match for managing customer relationships

As you may have figured out by now, Drupal is a great platform for 3rd party integrations. Whether it’s eSignatures with Hellosign, more sophisticated search with Solr, or a host of other options, Drupal works best when it’s not trying to reinvent every wheel and is instead used to leverage existing business tools by tying them all together into a robust and useful package. Today, we’re going to take a look at a new set of integration modules that Ashday has just contributed back to the Drupal community: Omeda, Omeda Subscriptions and Omeda Customers.

The Omeda Solution

If you haven’t heard of Omeda by now, let’s take care of that. They are a family-founded company who have been around for over 30 years and offer a host of Audience Relationship Management tools meant to properly leverage modern technology to properly segment and target your customer base. They are on top of their game and really know their stuff (they even collaborated on the brainstorming of these new modules). And best of all, they offer a very complete and well-documented API, which is key to any good integration.

While their API is extensive, much of it can be very tailored to a particular customer’s needs so we set out to build a contributable integration that covers some great typical use cases as well as allow for custom development where necessary. So far, this has taken the shape of three modules that potentially can be extended later on.

Omeda Base Module

The Omeda base module is meant to be a simple core module to get you wired up to Omeda so you can start doing things. It has settings to configure your connection to the API as well as a setting to work in testing mode. At its heart is a Drupal service that is meant to be injected into other contrib modules that can tackle specific Drupal solutions. This service provides the Comprehensive Brand Lookup, which the module uses to cache your Omeda brand config daily, as well as a generic utility for making API calls, which has the benefit of consolidating some basic error handling and formulation of HTTP requests. Here’s a little example of how simple it is to call the API using this service:

 

$brand_lookup = \Drupal::service('omeda')->brandComprehensiveLookup();

 

So that’s pretty easy, right? If anything is wrong with the API config or the service is down or something along those lines, the service throws an exception with a helpful message. Otherwise, it returns the Omeda API response to the caller. Again, it’s simple but provides the base functionality you need everytime you wish to connect with Omeda.

Omeda Subscriptions Module

The first module to leverage the Omeda base module is the Omeda Subscriptions module. This module adds a My Subscriptions tab to the user profile, for the roles you select, where users can manage their deployment subscriptions. You can also configure which Omeda deployments you wish to allow your users to manage. The available deployments come from the stored Comprehensive Brand Lookup data cached by the base Omeda module. This module includes a new Omeda Subscriptions service that adds functions to fetch a logged in user’s opt ins and opt outs as well as allow the user to opt in or opt out of a deployment. It’s a simple, specialized module (which is the best kind) to provide an out-of-the-box solution for the most common Omeda user subscription management needs.

Omeda Customers Module

The Omeda Customers module is another extension to the base Omeda module that allows you to map user fields to your Omeda customer entities and sync them on user updates. You can choose which roles will sync and which user fields will sync. Since field mapping can get quite hairy, we provide a solution for simple use cases where you need to simply tell Omeda that “this field = that field”. If it’s a standard base Omeda field like “First Name”, those are called base fields and are meant to be a simple hand off of the Drupal field value to Omeda. If it’s an email, phone number, or address field, you can choose that type and we will then ask you to determine which contact type it represents so that it gets into Omeda properly. It should be noted that for addresses, we only support Address fields from the Address module since mapping a bunch of individual Drupal fields to a single Address entity in Omeda is more complicated and likely needs a custom solution.

This mapping config also provides a simple solution for Omeda Demographic fields, which are more complex and dynamic fields that store IDs instead of literal values. It allows you to choose which demographic field a Drupal user field maps to and then create a mapping of possible Drupal field values with available Omeda field values. So if you have a field on the Drupal user called “Primary business role”, but you want to map it to the Omeda “Job Title” demographic field, you can do that. You would then hand enter a mapping that indicates that a Drupal field value of “President” maps to the Omeda value of “President / CEO” so that we can send Omeda it’s desired ID value of 5******* instead of the literal text of “President / CEO”, which would be invalid. Again, this is for more simple use cases; if your Omeda fields don’t map 1-to-1 to Drupal fields, the necessary business logic is wide-ranging and you will likely need custom programming. The great thing though is that we’ve included support for a custom hook (hook_omeda_customer_data_alter) to inject your own adjustments into the data mapping process and provide your own custom alterations.

In Conclusion

Hopefully these modules prove useful to you - especially if you’re already an Omeda client with a Drupal site - and the goal again is to provide some basic functionality that doesn’t require developer resources to integrate with some basic Omeda functionality. We ourselves have custom needs beyond what the modules can offer and find that it’s quite easy to extend them to do what we need for particular customer solutions, largely thanks to Drupal 8’s architecture. As always, if you need assistance please feel free to contact us and if you’d like to offer any module patches or report a bug, feel free to use the issue queues for each project and we’ll check it out!

 If you need to integrate Drupal with anything, talk to us! We can integrate just about anything with Drupal

Jul 11 2018
Jul 11

Coffee is a magical thing. It gets you going, clarifies your thoughts, makes you feel all warm inside. I don’t know what I’d do without it. So when we consider installing the Drupal module named after this irreplaceable daily beverage, we see that it has a similar effect. It just makes things better. Am I overstating things? Probably. But I haven’t had enough coffee yet today and I need to get this blog going with some pizzazz.

So simply put, the Coffee module gives you a Mac-like live search experience of the Drupal admin menu. It is triggered by the shortcut of Alt+D on the Mac, or Alt+ctrl+D in Windows IE. When the search bar pops up, just start typing and you can do an ajax live search of that deeply nested admin menu and get to things in a hurry! 

Screenshot of Coffee Drupal Module

Now, it’s not perfect. It can’t dig beyond certain levels, such as actually finding the settings of individual contact forms, but it gets nearly everywhere in the first couple of layers and can save you a lot of clicks when in development and site building mode. Even cooler - you can add your own custom coffee commands in your custom module to make your actions discoverable. That’s great flexibility. 

So there you have it! A simple module that shaves off a few seconds of time all day long. Pretty awesome!

Time to refill my mug.

Jun 22 2018
Jay
Jun 22

One of the many things Drupal excels at is integrating with other services. Some popular integrations are made even easier by the existence of contributed Drupal modules (such as the one for Google Analytics). But, many times, there isn't a ready-built solution, or the one that's available doesn't quite suit your needs. At Ashday, we've built many integrations between Drupal and other systems, and although every integration is different, there are some things we've learned that are good to consider when writing most any integration.

Do You Need to Build Something New?

Even if there is an existing Drupal module for the integration that you need, it's important to determine if you actually want to use it. Sometimes, integration modules are written for certain use cases, which may not line up with exactly what you need the integration to do, and could in fact make things more complicated for you than not using a pre-existing module at all.

For instance, when we created a Solr integration, we had to evaluate whether to use the existing Search API Solr module or write our own integration, and in the end, we decided to write our own. Why? Because when we were evaluating our options, we found that the module wasn't designed to index the content of our site in the particular way we needed it to, and it also didn't quite properly support the "More Like This"-style search which Solr itself is capable of. Because of this, we only had a few options.

  • We could modify our site to fit the capabilities of the module, but most of the time, as in our case, that isn't really an option.
  • We could use the module and try to adapt it to our needs. This would mean not only installing the module and figuring out how to use it, but also digging into how it was written in order to make changes to it. With some modules, such as Search API Solr, this can be a pretty big task. It's a large, complicated module, and figuring out where and how to make the necessary changes can be a challenge… and that's assuming that the module is structured in such a way that the changes are easy to make.
  • We could write an entirely custom integration.

We wound up going with the third option. "But wait," you might wonder, "If the existing module is so complicated, wouldn't writing your own integration mean needing to create all of that same stuff yourself?"

And the answer to that is no. Whereas a Drupal contrib module usually has to be designed in a rather generic way, so that it can suit as many people's disparate needs as it possibly can, an entirely custom-coded integration can focus solely on the functionality that is needed for your particular use case. Just because the system you're integrating with supports something, doesn't mean you necessarily have to. With the Solr integration in particular, building exactly what we needed as a custom integration wound up being much faster and more maintainable than it probably would have been to take the existing module and modify it to suit our needs.

How Much Drupal Should You Use?

Depending on what sort of integration you're writing, one thing to consider is how much it should rely on Drupal. Drupal includes numerous powerful tools, such as its service architecture and Form API, which can be leveraged to make your integration more flexible, and even save time in the process. At the same time, tying your integration to Drupal makes it less portable. For instance, if you were creating an integration which would display content from a remote system on several different websites, and only some of those sites actually use Drupal, then it may be worth creating the integration mostly using regular ol' PHP. By creating the integration as a set of classes or functions that don't depend on Drupal, each site can then use those same functions, and add just the few things that are needed to make them work well on that site; for instance, a Drupal site may need routes and permissions set up "the Drupal way" separate from the reusable part of the integration.

Creating a more generic integration in this way can also make it more compatible between different versions of Drupal. If your main integration doesn't rely on Drupal, it will work on Drupal 7, 8, 9, and even more, with only the minimal code to make it actually work on each site needing to be changed between them.

Another example: Say you're integrating with an analytics tool. You could either create a complex configuration form that fits into the Drupal administration interface and uses Drupal's form API, config system, and permissions, or you could just hardcode the specific settings you need somewhere in your codebase. The former way is the more "Drupal" way of doing it and is more configurable (this is the approach taken by the Google Analytics module), but the latter method can be very fast to code, and if you only rarely need to change anything about your configuration, it can be a great time savings over creating a complex Drupal-specific integration module.

Can This Be Contributed?

If your integration ultimately does make use of Drupal's helpful built-in features, great! Now it's time to ask "Can I contribute this module so that other other people can use it on their own Drupal sites?" If you are integrating with some tool or remote system that other people might also want to integrate with in a similar fashion, then the answer should probably be yes.

Contributing your custom integration module to Drupal.org can have a number of benefits—not the least of which is that it is an excellent way to give back to the Drupal community as a way to say "thank you" for all they've done to make Drupal possible. But there's another benefit as well: If you contribute a custom integration module, that means that other developers may start using it, looking at the code, and making improvements to it. Maybe your integration is fairly small, and only accounts for the handful of use cases that you need. The next person who uses the module thinks that something could be added or changed to improve the module. Suddenly, you have other people making suggestions or even writing code for you, which you can then benefit from by including such changes in the integration you're already using.

This is what we did with our HelloSign module for creating eSignature requests; we built it for one site which needed such functionality, then we contributed it. Once we did so, other developers started looking at the module and helping us to make all sorts of improvements to the module, and some even submitted patches to help improve the module. We also got free t-shirts out of it, so hey, who knows what might happen when you contribute!

Conclusion

There are many things to think about when you're building a Drupal integration, and although I've only written about three of them today, I think they are the guiding questions which help to determine how your integration is built. If you can answer all three of these questions before getting too far into writing your integration, you're much more likely to end up with a system in place that will serve you well long-term, even if the exact requirements for the integration eventually changes—which, in my experience, they almost certainly well.

If you need to integrate Drupal with anything, talk to us! We can integrate just about anything with Drupal

Jun 15 2018
Jun 15

As you may or may not have noticed, we’re having a lot of fun over here at Ashday building Drupal sites with React. Check out our own site, for example. We are really digging this new direction for front-end and you can learn more about why we did it how we approached it in other articles, but here we are going to talk about how we approached the Drupal editorial experience, because honestly - we just didn’t find a lot of great resources out there discussing how this might be done well in a decoupled experience.

Something about Gift-Horses

While we can’t speak with authority on the potential detriment of literally looking gift-horses in the mouth, we can speak to the idea that we should be grateful for what we’ve been given, and Drupal has given us a lot! If you were in this industry when most of us built everything from scratch, you’ll know that it’s a crazy pile of work to do the most basic things and nothing is taken for granted. Need a login form? Sure thing. Oh, now you need flood control? Um, ok. Captcha? Boy. Password reset? Ugh. Ok, I need a week just to get user authentication in place.

Drupal does so much out of the box and we aren’t about to throw it all away so we can call ourselves fully decoupled, which is the idea that Drupal isn’t providing any of the front-end at all. It’s worth noting that some are pursuing the concept of “Progressively Decoupled,” where only select components of the front-end site are managed with React, but we don’t prefer that approach in most cases because we don’t want the overhead of taking on traditional Drupal theming and a React build out, yet with less obvious design constraints, potentially extra hosting, multiple development workflows, duplicated styles, etc - leaving us short of many of the benefits of going decoupled at all.

We prefer to an approach that we’ve, for the moment, dubbed “Deliberately Decoupled.”

Deliberately Decoupled

What we mean by “Deliberately Decoupled” is that we aren’t decoupling purists, who see ourselves just as much evangelists of a particular approach as we are just software engineers, and we also aren’t operating by a FOMO (fear of missing out), where anxiety about not being on a bandwagon drives our decisions. We prefer to leverage what we think is beneficial for our clients and the site, and secondarily abide by our preferences. A good example is the Open Source philosophy. We love open source! But we aren’t for a minute going to bypass a proprietary library that does something really cool just because it’s not open source. It’s the same with decoupling. We want what gives us good bang for the buck - either in the deliverable, or the cost, or the UX, or whatever else is impactful - and it helps far more than it hurts. So, for the largely public facing ends of our sites, we hands-down love what React is giving us and rarely find Drupal’s out of the box front-end solution to be easier or more flexible. On the back-end? For the editorial and admin experience, we really have no interest in trying to replace everything Drupal provides unless there is a major overarching requirement or clear benefit that can justify hundreds or thousands of hours of additional work. There are some projects that do merit it, such as when you have highly dynamic and interactive forms, but if that’s not the case Drupal can do the job on its own.

Considering Outsourcing? Consider Ashday!  Request your free consultation today. 

One prime example of leveraging cool stuff in Drupal is the use of Paragraphs for content. If you haven’t heard of Paragraphs, you really must check it out. It’s been our favorite way to give editors the ability to create interesting and dynamic content creation without the cringe-worthy experience of complex WYSIWYG and HTML source editing, especially when it comes to the mobile experience. Nearly all of the Ashday.com pages are built with paragraphs, so that means an editor can do parallax, add related content boxes, throw in some CTAs, etc. Pretty cool! And as you’ll see later, we leverage React for our pages, but Drupal’s admin for editing the paragraphs and it creates a clean and intuitive editorial experience.

So does all this mean for editing we just hand over Drupal Admin accounts to our users so they can swim through the Sea Nettle-like admin experience say good luck? Hardly. Let’s get into the nitty gritty.

Our Philosophy - Less is More

Generally speaking, Drupal doesn’t matter much to the user. Of course Drupal matters, but not really to the end user just trying to do their editorial work. Not as far as they are aware. And they shouldn’t have to be “aware”. Do you remember when you first looked into Drupal? Do you remember how weird the world was as you learned that a “node” is “content”, but then so is a “block” (kinda), and a “view” is a query but maybe with a page attached, or a “taxonomy” is hierarchical data, but with display pages? All frameworks have to be abstracted sufficiently, which means making up generic terms and concepts that only make sense when you’ve spent time with them. Well, guess what? Most users would really rather not just learn all of those concepts and instead just easily write content and update their site. The key to that is to reduce, simplify and obfuscate.

Drupal’s admin is very friendly to developers, but unnecessarily verbose when it comes to editors. They don’t need half the contextual menus, vertical tabs, sidebars, etc most of the time. And the stuff they do need should be stripped down to the obvious and helpful. So let’s hide tons of help text on a WYSIWYG with multiple text format options and use Paragraphs + a simple WYSIWYG instead. Let’s rename any buttons or links that have the word “node” in them because really, who cares if it’s a node? Let’s put our field labels inline to save vertical space and use something like Field Group to organize them cleanly. And let’s take away that rats’ nest default Drupal menu and create an alternative that just gives them what they care about. Here is an example of what we’re talking about.

From this…

Example of Drupal admin showing contextual menus, vertical tabs, and sidebars.

To this. 

Example of streamlined Drupal Menu. 

In addition, let’s take the coolness of contextual admin, like Drupal provides, and make it more intuitive as well. If you hover over a block you can edit it or configure it. If you’re on a node page, you get view and edit links in the tab bar. And you can even sometimes use the new inline editing features in Drupal 8. The problem, though, is that once again the user has to understand what each of these elements are and why they’re all different in terms of the triggering UX. We are having a lot of fun in React finding more consistent and creative ways to manage content without understanding it.

So here’s a rudimentary example using Ashday.com.

Example of Drupal contextual admin, showing node page.

You see some sorting icons and some edit icons. That’s it. Technically, those sortable sections are paragraphs, which - thanks to React - can be sorted inline - but are also editable individually apart from the others. The “Free Consultation” button in the header is a React button tied to a few settings stored in some custom Drupal configuration in the back-end. Further, that edit icon in the page title area can be used to edit the entire page at once so you can change the page title and things like meta tags, although the next step is to probably provide more direct access to edit those things so that you don’t have to know what all is buried in a node form. So the goal here is for the user to have just some basic concepts to think about, like edit and sort, instead of Edit Node vs Configure Block vs Edit Block vs Sort Paragraph vs Some Other Drupal Configuration Buried Deep In the Admin or Form.

And by the way, here’s what happens when you click the edit link on the header button, vs the first paragraph. 

 

Edit link on header button

Intuitive Drupal 8 admin

  

Edit link on first paragraph

Screen shot of admin interface for Drupal page built with React.

 

So despite varied back-end architectural implementations, the user has a very similar experience contextually editing something. A simple page mask + offcanvas + clean form. Its cool stuff, all made easier with the ability to re-use display elements in React all while still getting a ton out of Drupal’s back-end for content management and forms. Simple, kinda easy, and totally user friendly.

Looking to use react for your next digital project? Find out how Ashday can use React to make your project a success.

Jun 08 2018
Jun 08

Ashday Interactive Systems logo and React logo

Decoupled Deschmupled

Like many folks in the Drupal space we've been closely following the Decoupled Drupal conversation for the past few years, and occasionally a part of it.  And, again like many folks in the Drupal space, until recently we had felt that it was somewhat in its infancy and a lot of tough questions still remained as to whether it was even a good idea. The SEO implications have not been entirely clear, the impact on estimation has also been very hard to nail down, which decoupled framework to go with has not at all been a consensus, and what Drupal’s exact role is in the decoupled site has not been clear either. 

Choosing a JavaScript Framework: React vs Angular vs Ember

So like Stryder shuffling through the grass and reading the signs of what had happened to two of his favorite hobbits, we started to sense in the past year that maybe Decoupled Drupal was becoming suddenly not an odd-ball proposal but possibly a truly beneficial solution with a backbone. A key component for us? React. Heard of it? Probably. It’s been around for a few years now. The critical difference for us with this was momentum. After all, if you want to train up your staff on a whole new technology you better be certain it’s not dead in 12 months.

Let’s take a look at some Google Trends.

This is the last two quarters of 2017 Google Trends for the terms Angular, React and Ember, which were the three most talked about decoupled js libraries/frameworks at DrupalCon Baltimore last year.

Graph showing interest in Angular, React, and Ember in 2018.(blue = Angular, red = React, orange=Ember)

Result? Angular is solidly in first, React is reasonably behind in second, and Ember is a distant third. Hard to know where things are headed exactly, and coupling that with the fact that the theme in Baltimore was that Angular has the most attention, but people seemed divided about whether it was the long-term solution because React and Ember (and others) were growing trends. 3 distinct trending choices? Not sure which is best? And many were unsure this was even a good move, as were we. Better hold off a bit.

Now let’s look at the trends for 2018.

Google Trends graph demonstrating increased interest in React in 2018. (blue = Angular, red = React, orange=Ember)

Notice a difference? Look at that little red bar now. That’s React. So even though just a year ago Angular held a reasonably strong lead, it definitely held true that some newer frameworks were gaining momentum, and React has already caught up with Angular. And further, Ember has fallen further behind. When you factor in how much of Google searching is people looking for support for something they’ve already built, which heavily favors the 5-years older Angular, that makes the React climb even more impressive. Does it mean Angular is dead? Far from it. But React is exploding.

Then there’s this: https://dri.es/drupal-looking-to-adopt-react. Yep, those chiefly interested in and responsible for Drupal are favoring React as well. Further, the general feel on the interwebs was that across all web technologies, decoupling was growing as a plausible solution in leaps and bounds. Great ideas were being kicked around about specific solutions to the hard decoupling problems. And above all, we’ve been looking for an excuse to give it a whirl. Well that just about solves it. If we’re going taking the plunge on this decoupling adventure, let’s just roll up our sleeves, install React, aggregate and distill our two years of thoughts on the matter, and cannonball into the deep end of Decoupled Drupal.

Brainstorm your next development project with  an Ashday expert!  Request your free session today. 

React and SEO

When you decide to decouple - even if you’ve already picked a js foundation to build it on - you quickly realize that the solutions are as varied and complex as they are on the back-end of sites. If you’re going with React like we did, then that fortunately becomes much simpler still requires a lot of investigation, learning, experimenting and decision making. In order to not be plagued with decision paralysis, we decided our top priority was ensuring that none of what we were about to do was going to hurt our SEO. The flare and flash could come later. This was probably the one real deal-breaker for us in this endeavor.

SEO these days is rather complex and somewhat arbitrary, but there are some easy-to-overlook SEO principles when it comes to page rendering that must be addressed in a decoupled architecture. No one wants to tweak the heck out of their site and push on content editors to make sure everything is SEO friendly only to implement an architecture that keeps people from finding you. While a bit oversimplified, let’s look at three key principles that are to be followed when delivering page content if you don’t want to be punished.

  1. The content needs to be delivered to search engines and users even without JavaScript.
  2. The content needs to be delivered to search engines that do run JavaScript (i.e., Google), but won’t wait for asynchronous APIs to load.
  3. The content delivered to search engines needs to match closely what site visitors receive so that we don’t get punished for cloaking.

There are a few approaches to this problem. And while “I quit” was certainly on the table for us, we pushed through and are glad we did. So let’s take a look at our more courageous options.

Client-side Rendering

This is effectively the coolest part of React, but you have to be careful of the implications, especially when content is dynamic. So for example, you can load your whole front end “shell” in React nearly instantly and then let things like dynamic header menus, page content, footer content, etc all load asynchronously as soon as it’s available. This creates some neat opportunities to improve user experience. The problem is the SEO implications. As stated above, you really can’t do asynchronous rendering and have it delivered that way to search engines, so now you’ve got a problem. For us, this meant choosing to use client-side rendering approaches where it benefitted actual user interaction and leave the rest to the server.

Pre-rendering

In this approach, your site is rendered statically on a Node.js server somewhere and the pages are served to the end user with no JavaScript required for initial page load. This leads to blazing fast pages as it’s just raw HTML/CSS/JS and no API calls on the fly, but it also leads to some significant downsides depending on your requirements. For example, in pre-rendering you are caching entire pages so if you have thousands of them, perhaps with varied caching control on various pieces of the pages to optimize performance, you now have a very heavy pre-rendering load. This means the task of updating your pre-rendered pages whenever any element of that page might change can become substantial and also complicate your CMS. For us, this wasn’t an option because even in building Ashday.com, we wanted to work with an approach that we felt could be adapted to our biggest clients.

Server-side Rendering

This is ultimately where we landed for ashday.com and we’ve been quite happy with it (so far). With server-side rendering, your pages are still “live”, but they are generated on the Node.js server when requested so that search engines and users get the same experience. It also allows us to handle the caching of various API calls separately so that we can get great performance. It’s not going to be quite as fast as pre-rendered, but then again we also don’t have to tackle the complex task of figuring out how any element of the site might affect a rendered page and be sure to appropriately - and in timely fashion - re-render all of those pages. So on a site with 50,000 articles, a change to a menu link in the header would mean re-rendering every page when using pre-rendering, but with server-side rendering, it just means a cache reset on a single API call to get menu links. It’s a fair trade off, we think.

So with all of that, we decided to build a React app using Next.js. It’s not all that different from straight React, but it offers a few bells and whistles, notably the added synchronous getInitialProps lifecycle method, that make server-side ren

dering a snap. Other approaches, such as using the default Facebook React app, seem much more suited for static non-API-based websites because you really end up needing to implement your own server-side solution where you separate your server configuration from your client configuration. Given that there are already so many new problems to solve and new concepts to learn, we settled on Next.js for now so that we could move forward and get our hands dirty without killing our Google juice.

As a side note: We’re pretty stubborn about wanting the best experience here though so we’re actually hoping that either the upcoming version of Next.js that includes React Router or else another evolving React-based solution will make it much easier out-of-the-box to build a React-solution that both renders server-side for initial page loads and lets the client run the show after that. As of yet, it’s a bumpy road to get there with existing tech and you have to evaluate the cost and overhead of trying to make that work.

Looking to use react for your next digital project? Find out how Ashday can use React to make your project a success.

Jun 01 2018
Jay
Jun 01

Illustration of a person signing a document electronically.

Previously, I wrote a bit about the HelloSign eSignature platform and how it can be integrated into a Drupal 7 website. As promised, a Drupal 8 version of the integration is now available and ready for use on cutting-edge websites everywhere. But this new version is much more than a one-to-one upgrade of the original module— we've leveraged some of Drupal 8's great new features to make using HelloSign with your site even easier than it was before. Here are just some of the highlights of the new release:

Composing Your Site

Installing the old HelloSign module could be a bit of a pain. In addition to needing to download the HelloSign module for Drupal, it was also necessary to download a separate HelloSign PHP SDK and put it in the right place in your site's code. Now, the HelloSign module can be installed easily using Composer. Instead of downloading two files from two different sites, unzipping them, and carefully making sure to put them in the right place in your site code, all you have to do is run one simple Composer command:

composer require drupal/hellosign

That one command will install the module in the right place, and it also installs all of the module's dependencies, including the HelloSign PHP SDK and the Encryption module (more on that in a moment), making it even easier to get started with HelloSign in Drupal 8 than it was in Drupal 7.

Need to Integrate Drupal with HelloSign, or with Anything Else?  Request your free consultation with an Ashday Drupal integrations expert today. 

Security by Default

Many Drupal modules are available which, like the HelloSign module, help make it simpler to integrate with other services. One thing common to most such modules is that they add a configuration form on the Drupal site, which administrators can use to set up the integration by entering essential information such as credentials and API keys. The HelloSign module is no different; integrating with HelloSign requires the use of an API Key and a Client ID, and the module provides an easy way to set these (and other useful settings) through the administration interface.

One thing that often gets overlooked by integration modules, however, is the security of this saved information. Once the API key is configured, it is stored as plain text both in the database and (if you are using Drupal 8's configuration management feature) in the code of the site. Unfortunately, that means that if any ill-intentioned person somehow gained access to most any part of your site, they'd have access to your secret API key.

To mitigate this common issue, the HelloSign module in Drupal 8 makes use of the Encryption module to store this private information in a secure, encrypted format, decrypting it only when necessary to interact with the HelloSign API. This feature is on and enabled by default and, in fact, can't be disabled, because having such an option would make for inherently weaker security.

Built for the Modern Web

One issue with Drupal 7 was that it was not, on the whole, built with modern object-oriented PHP coding practices, and the modules built for Drupal 7 often followed suit. Drupal 8, however, is a whole new object-oriented world, and that's as true of the HelloSign module as it is of Drupal Core.

The Drupal 7 version of the HelloSign module had most of its features buried in a number of disparate functions, many of which were ultimately just wrappers for functionality made available in an object-oriented fashion by the HelloSign PHP SDK. For Drupal 8, we've simplified this. The HelloSign module provides a

service which, in addition to allowing the creation of signature requests, also provides direct access to the rest of the HelloSign API. Instead of making assumptions about what bits and pieces of the API's many features a site might need, now, all of it is available. The service also automatically establishes the necessary connection info, so that your developers never have to worry about how to connect to HelloSign.

In Conclusion

The HelloSign Module for Drupal 8 has all these improvements (the use of composer, enhanced security, and a modern object-oriented design) and many more, including vastly expanded documentation and more granular permission handling. We hope that it will be of use to you on your next Drupal project which needs to support eSignatures.New Call-to-action

May 25 2018
May 25

Illustration of search function on a website.

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.

Brainstorm your next development project with  an Ashday expert!  Request your free session today. 

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.


namespace Drupal\my_module\Solr;
use Solarium\Core\Client\Client;


class SolrExample {

  /**
   * Connection to the solr server
   *
   * @var Client
   */

  protected $solr;
}

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.


/**
* Solr constructor.
*/
public function __construct() {
 $config = \Drupal::config(‘example.solr_config’); //Normally we’d inject this, but for this example we’ll ignore that
 $settings = [
   'endpoint' => [
     'default' => [
       'host' => $config->get('host'),
       'port' => $config->get('port'),
       'path' => $config->get('path'),
       'scheme' => $config->get('protocol'),
       'http_method' => 'AUTO',
       'site_hash' => TRUE,
      ]
    ]
  ];
 $this->solr = new Client($settings);
}


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 Drupal service which 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

/**
* General Search functionality
*
* @param array $params
*
* @return mixed
*/
public function search($params = []) {

 $query = $this->solr->createSelect();

 $default_params = [
   'start' => 0,
   'rows' => 20,
   'sort' => 'score',
   'sort_direction' => 'DESC',
   'search' => '*:*',
   'time' => '*'
 ];

 $params = array_merge($default_params, $params);

// Building a proper solr search query with the search params
 $search_string = $this->getTextSearchString($params['search'], $params['time']);

 $query->setQuery($params['search']);
 $query->setStart($params['start'])->setRows($params['rows']);
 $query->addSort($params['sort'], $params['sort_direction'] == 'ASC' ? $query::SORT_ASC : $query::SORT_DESC);

 try {
   $results = $this->solr->select($query);
   return ['status' => 1, 'docs' => $results->getData()['response']['docs']];
 }
 catch (HttpException $e) {
   \Drupal::logger('custom_solr')->warning('Error connecting to solr while searching content. Message: @message',['@message' => $e->getMessage()]);
   return ['status' => 0, 'docs' => [], 'message' => 'Unable to reach search at this time. Try again later.'];
 }
}

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.

$query = $this->solr->createMoreLikeThis();
$helper = $query->getHelper();
$query->setQuery('id:' . $id);
$query->setRows($params['rows']);
$query->setMltFields($params['mltfields']);
$query->setMinimumDocumentFrequency(1);
$query->setMinimumTermFrequency(1);
$query->createFilterQuery('status')->setQuery($params['queryfields']);

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.

MIKE OUT

New Call-to-action

May 22 2018
May 22

Hire-Programmers-vs-Outsource.jpg

Well sure, ok, maybe we might be slightly biased on this. We are, as it turns out, a consulting firm in the business of selling outsourced programming. Ahem...

But, nonetheless, I’ll try to be reasonably fair and balanced here. As a consultancy I think we have, in fact, a unique vantage point on such matters, since we spend each day of our lives straddling both sides of this topic: That is, we sell outsourced programming to organizations for whom outsourcing is a good fit; whereas we ourselves hire in house staff programmers, i.e. we are an organization for whom outsourcing is not a good fit.

Ergo, our very business model is a demonstration of the fact that there is not a single “right” answer to this question. Some organizations should hire programmers as employees; some should outsource their needs to development shops. Some should maybe do both. How do you know which kind of organization you are? To answer that you’ll need to dive deep into 4 prerequisite questions.

1) For Your Organization, is Programming an End or a Means to An End?

For Ashday, the core essential product we produce and sell is programming. It’s our thing we do. As such we really want to have full ability to craft, manage, and perfect every aspect of the development ecosystem (more on this below). Some agencies in our industry outsource most or all of their programming needs to freelancers or subcontracted companies; we do not (and I can’t imagine wanting to). For organizations, small or large, whose end product is programming, a very strong case is intrinsically made for direct employment. If that’s you, read no further, go hire some programmers and find a way to make it work. (Or click over to that thing Clint wrote five years ago about tomatoes and taxonomies.)

But what if programming related actives are not your core business offering, just tangential to it or necessary for its operations? What if you produce electricity, or refrigerators, or news, or surgeries, or legal fees? And you just need programming to get that done…. Then the next question is:

2) Is it Cost Effective?

This one can be tricky. On the surface, it would generally seem that in-house programmers cost less than outsourced, if you compare the hourly rate of a dev shop to the salary of a developer divided by the number of work hours in a year.

That’s an oversimplification though. Remember that salaried programmers are not producing code 100% of the time. They also take paid vacations and holidays, go to conferences, sit through meandering meetings, and take extended breaks for ping pong tournaments. They need to spend time learning new technologies, which is a more or less continuous part of the job. They need to fix stuff that breaks on their computers. Etc.  So you’re probably doing well if they’re actually producing code 75% of the theoretical 2000-ish hours in the work year. Also the costs in play are not simply for salaries. You need implied costs of any benefits, training costs, general space and infrastructure costs, and the various costs of tools (more on tools below.)

Brainstorm your next development project with  an Ashday expert!  Request your free session today. 

Also, some percentage of your hires aren’t going to work out. You may roll with somebody several months or more before your realize they're not a fit. The cost of failed employees needs to be averaged into the average cost of successful ones. And, of course, even the ones that work out may eventually leave, taking with them a lot of investment that you’ve made.  There’s also a non-intuitive factor here pertinent to the question of which is more “stable”: we have had, multiple times, the experience of being in multi-year relationships with clients which outlast their relationships with all of their in-house programmer staff ... complete staff turn-over, but the vendor (us) is still there.

Additionally, on-site staff (at least for smaller internal teams) may need to be jacks-of-all trades, versus outsourced firms that are able to let their dev staff specialize more. Thus the output per hour on a particular task can be far greater from the outsourced firm, who is able to assign specialized staff to tasks appropriate to their expertise so as to maximize efficiency.

When it’s all said and done, it’s not particularly obvious that the end cost of outsourcing is higher or lower than that of staff, despite the apparent surface difference in hourly rates. It really can vary. It can be, and often is, the case that it’s much cheaper to outsource.

Nonetheless, it is of course possible to have a cost advantage in-house, as is demonstrated by the very fact that programming firms exist in the first place, and (ideally) operate a profit. The profit margin is not typically huge, but done well it’s certainly present. That margin plus any efficiencies gained (such as through avoidance of duplicative operational/marketing/sales etc staff and costs) is the financial benefit potentially available to be saved by bringing a team in house. This requires a certain scale of operations and ongoing needs, and the savvy to pull it off, but at some point it can be significant.

3) Will the Time Frames Work?

Generally, unless you’re a huge company, a dev firm will probably have more developers and therefore development bandwidth than your internal team will. If quick turnarounds of large projects are important, a firm probably is best. 

On the flip side, dev shops are juggling more than just one client.  If you tend to have myriad small needs that come up frequently, and must be tended to almost immediately, it can be hard for an outside firm to accommodate because they may be in the middle of a big thing for some other client which they can’t just drop. Internal staff though can often turn on a dime, because it's your dime. That is, they effectively just have one boss (you) setting and modifying their priorities, versus competing clients.

4) Can You Build and Maintain a Healthy Development Ecosystem?

A final key question to ask if you are considering hiring devs, is whether you are able to build and maintain a healthy development ecosystem. By this I mean the harmonious instrumentality of four critical things: staff, tools, processes, and culture. A bit on each:

Staff

This is your would-be in house developers/programmers (as well as, depending on size and scope, architects, designers, testers, UX experts, etc.) AKA the geeks (I'm using that term, self-referentially, in only the most loving of ways). These folks need to be focused, smart, honest, and very knowledgeable in their field. They need to have brains that are wired for rigorous logical thinking plus creativity plus attention to detail. 

Such people can be exceedingly hard to find.   Therefore once found, you’re going to want to keep them around.  So they need to be excited about their job, and paid well. It’s important to remember, for morale and retention, that developers (good ones at least) love to solve problems. That’s why they got into this field. Now solving a problem one time is fun, but solving the same problem one hundred times is not so much.  To keep the interest level up, you’ll need to be able to provide a steady stream of interesting new challenges, or at least opportunities for abstractions of the previous challenges.   And you’ll need to make a continuous investment in ongoing education – technology is always evolving and developers want to evolve with it.

Considering Outsourcing? Consider Ashday!  Request your free consultation today. 

Tools

Abraham Lincoln famously said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” (Though I’ve just done some research and it appears it was probably not actually Honest Abe, but an anonymous lumberjack who said that. In my next post we’ll investigate the increasing evidence that an anonymous lumberjack delivered the Gettysburg Address.) 

Point being, having good, sharp tools is important. The developers’ primary tool of course is his or her brain. But I’m talking here about the bevy of other physical and virtual tools that must be put at the disposal of said brain (and that of its encasing body).

For instance, you want to provide really good computers (newer Macbook Pro’s are usually a hit), multiple large monitors (high resolution), and expensive ergonomic chairs (versus the free kind available out back near the dumpster). Adjustable standing standing desks have been very popular with our staff (Veridesk Pro Plus 48).

Equally important is the vast constellation of software tools that the are the stock on trade of this game. IDE’s, data inspectors, ticketing systems, continuous integration engines, vm provisioners, browser simulators, design introspectors, Star Wars meme generators, etc.

Process

If you’ve nailed it on staff and tools, great. But you also need to be able to run their operations. That takes proper processes. Great staff and expensive tools can utterly fail if the processes are wrong. You need to think about processes for general software lifecycle (Agile school of thought is helpful here), dev & devops, quality assurance, etc. 

And, in general, you need processes at every level that implement intelligent “systems thinking” to effectively control the various complex systems that you will be building and managing. More thoughts on that here.

Culture

This final one, culture, is harder to define. Lots of people try to define it, but I’m not sure they ever succeed in a comprehensive way. Maybe it’s similar St. Augustine’s take on defining time – “If no one asks me, I know what it is. If I wish to explain it to him who asks, I do not know.”  

But definable or not, it’s exceedingly important. It has to do with corporate values, and a sense of dignity and purpose in labor, and relations between people, and respect, and beliefs about software philosophy, and leadership philosophy. It has to do with how people talk and dress and smell. It has to do with what’s hanging on the walls, and what music is playing, and whether the fridge is full of energy drinks, beers, or kombucha.  It’s myriad things collectively creating the “feel” of the place. No two are the same.  Somewhat ethereal, somewhat elusive, and yet you’ve got to get it right for programmers to be happy and stick around.

So Now What?

If you navigated through all four of these questions, and feel like in-house make sense, then it very probably does. You can start advertising for programmers in places like Stack Overflow, and Indeed, and on your own site and social networks. You can start networking in local programmer groups - checkout Meetup. Maybe even start making relationships at a local university’s C.S. department to look toward the long term future; free pizza & programming night or something.

Or if, after all that, in-house isn’t for you then find a good dev shop and let them get to work. 

New Call-to-action

May 18 2018
Jay
May 18

Illustration of finger selecting 5 stars

Drupal 8 has been available now for more than two years, but if your site is up and running on Drupal 6 or 7, you may be wondering… why should I upgrade? And why now?

Well, if you're on Drupal 6, the answer is easy: Drupal 6 is no longer an officially supported platform, which means that in addition to not getting the latest and greatest Drupal features, your site may be vulnerable to serious security issues and you will have to find backports of the latest security patches from the community or attempt to create your own.

But if you're already on Drupal 7, then security updates and occasional small new features are still being made available for your version. So… why upgrade? Well, I can think of five great reasons to do so, and for why now is a better time than ever.

Contrib Is Ready

One common hesitation about upgrading to Drupal 8 has been that many key contributed modules from Drupal 7 were not yet upgraded, and many sites depend on having such modules. It's taken a little while, but especially over the past year we've seen a huge increase in the number of modules ready for use on Drupal 8… and many of them are even better than they were on Drupal 7. Consider, for instance, the popular Webform module. Not only is it available for Drupal 8, but it's been rebuilt and redesigned from the ground up. The interface for managing your webforms is much more intuitive than it used to be, while also having many more options. At this point, if there's some feature you want your form to have, then Webform can probably handle it.

Of course, Webform isn't the only major module that's ready. Popular modules such as Drupal Commerce, Domain Access, Paragraphs, and Metatag are ready to go. And let's not forget that many vital Drupal 7 contributed modules, such as Views and Media, are now included in Drupal 8 by default, so you don't even have to install anything extra to use them.

Considering an Upgrade to Drupal 8?  Claim your free consultation with a Drupal expert!

Easier Migrations Than Ever Before

One thing that may have had some people holding off on upgrading to Drupal 8 was that Drupal's new migration features weren't quite ready, and writing a custom data migration or working with a buggy migration tool can be quite a challenge. Well no more! The Drupal Migrate module is finally stable. This module is included with Drupal and is designed to make it as easy as possible to move all of your content from a Drupal 6 or 7 site to your shiny new Drupal 8 site.

One caveat: If your site is multilingual, then you might have to wait another version or two for the last few bugs with multilingual migrations to get worked out. But, that doesn't mean you have to hold off on building your new Drupal 8 site! Now would be a great time to get the new site built, and once the multilingual migration bugs are fixed, moving your content over at that point should be a comparatively trivial task.

New Features in Drupal Core

Using the most recent version of Drupal means that your site can easily start making use of the many new features that are always being added to Drupal core. For instance, Drupal 8.5 includes a whole host of new features, such as the Media module being included by default, a new Layout Builder module, and enhanced interfaces and settings for managing content and site configuration… and that's not even talking about the many significant bug fixes and other minor enhancements which are detailed in the full release notes. With feature releases such as these, sites built with Drupal 8 get fantastic improvements twice each year essentially for free.

By comparison, although Drupal 7 sites still get security fixes and the occasional other bugfix, the last time that there was a significant update for Drupal 7 was back in June 2017 with Drupal 7.55, and even then, the handful of improvements made were still small compared to the rate of improvement Drupal 8 has been seeing. Upgrading to Drupal 8 means you get more new features, more frequently, in addition to being able to use all of the great new features added to Drupal 8 in the five feature releases it has already had.

Ease of Upgrades

I've written a bit about this before, but I think it bears repeating: Once you've upgraded to Drupal 8, the greatest upgrade challenges should be over. Because of how Drupal 8 is designed, future upgrades to Drupal 9 and beyond should be a much simpler transition than moving to 8 from older versions.

This is important to realize because, prior to Drupal 8, many people would "skip" a Drupal version… going from 5 to 7, or from 6 to 8, since the older version would be supported with bug fixes until the new version was released. Many people may be in a similar state now, waiting to upgrade from 7 until 9 is released, but at this point, holding off like that really shouldn't be necessary. If the upgrade from 8 to 9 should be a simple change, like Drupal creator Dries Buytaert has said, then there's no need to skip 8 entirely and miss out on all the great improvements that it can bring to your site today.

Upgrade While There's Time

There's a balance to be struck when deciding when to upgrade to Drupal 8. Doing it right after Drupal 8's release may have been tricky for many sites, due both to some bugs present in the new version and to the many important contrib modules not yet having been upgraded themselves. At the same time though… the longer you wait, the closer you get to your Drupal 7 no longer receiving critical security fixes. Although it's not yet clear when official support for Drupal 7 support will end, it's easy to see that it will happen at some point, and you'll want to already have upgraded by the time it does.

To me, right now feels like the ideal time. Drupal 8 is ready (and better than ever!), and there's still enough time left for Drupal 7 that if you have a complex site, you can take the necessary amount of time to upgrade without being rushed. The worst situation to be in would be to start upgrading a complex website when there's only a month or two of Drupal 7 support remaining, since then you might have to rush the upgrade and end up with more bugs (or things missing from your site) than you'd have if you took the time to upgrade now.

Conclusion

All of this is to say: It's time. Even if you weren't able to upgrade before, due to lacking contrib modules or the need for the Migrate module, those should no longer pose a problem. You can upgrade today and get countless major improvements over previous versions of Drupal (with more coming all the time) and you can even rest easy knowing that the next "big" upgrade shouldn't be anywhere near as daunting as they have been in the past.

It's been more than two years, but finally, Drupal 8 is ready for your site. The question now shouldn't be "Why upgrade?"... it should be "Why wait?"

Is there another reason why you are waiting to upgrade that we didn't mention? We can probably help, schedule your free consultation today.Offer for a free one-hour consultation, make you next project a success

Apr 13 2018
Apr 13

Illustrated character showing the benefits of upgrading to Drupal 8

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.

Considering an Upgrade to Drupal 8?  Claim your free consultation with a Drupal expert!

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.

Offer for a free consultation with an Ashday expert

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.

MIKE OUT

Apr 06 2018
Apr 06
image of the Drupal and Wordpress logosWe’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.

Which CMS is best for your website?  Take our CMS Quiz and find out!

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?

MIKE OUT

image with text offering access to our free CMS Selection quiz.

Mar 23 2018
Mar 23

Why Squarespace Will Replace Wordpress, Wordpress Will Replace Joomla, and Drupal Will Replace Drupal

When the open source WordPress blogging platform first came out, it opened up the world of internet publishing to the masses. Sure, there were website builders out there like GeoCities and Angelfire, but they lacked much and were very ugly. When WordPress came along it gave voice to those willing to overcome the barriers of setting up web hosting and installing the software. These days there are much better website builders for the common person. Squarespace being a standout of the group even has an easy to use e-commerce option. Because of this, the roles of many popular Content Management Systems (CMS)s are shifting.

Squarespace is the new WordPress

While WordPress usage is higher than ever, it seems that a large portion of the DIY and personal site market is shifting to services like Squarespace. It makes sense, since Squarespace and its ilk (Wix, Weebly, etc) are often easier and cheaper in the long run. With hosting and support rolled into one cost, it simplifies everything. People building personal sites and even small business sites have been migrating over to these kinds of site builders more and more every year. The trend is sure to keep rising as these services start to offer e-commerce and other business tools.

Which CMS is best for your website?  Take our CMS Quiz and find out!

WordPress doing more than ever

WordPress really hasn’t changed all that quickly over the years, but what has changed is the ways in which people are using it. It’s still deep-down a blogging platform, but people have extended it to be much more of a full CMS. The sheer number of developers familiar with WordPress development is what has pushed it to be the top open source CMS on the web today. WordPress is now the CMS of choice for most small to medium sized enterprise sites, and it is increasingly capable of more on more complexity, potentially pushing middling tools like Joomla more and more into the fringes of the the market and perhaps eventual irrelevance. WordPress is probably going to continue to be the top CMS for at least the next few years as more web design and marketing agencies make it a cornerstone of their services. WordPress at it’s core doesn’t seem to be doing much to accommodate this new kind of usage that is beyond the blog. We are already starting to see the bubble burst as these sites are requiring more functionality than WordPress can handle and many end up being more custom code than WordPress. It will be interesting to see if WordPress adapts or loses share in the enterprise world over the next few years.

Drupal framework more of a framework

Drupal has always been viewed as more of a framework than a CMS. With the release of Drupal 8, Drupal has doubled down on the framework concept incorporating the Symfony PHP ecosystem into it’s core. Drupal 8 has become the perfect option for large Drupal 7 sites that have begun to outgrow what Drupal 7 can do. Drupal 8 has positioned itself to be a viable option for many web based apps and can easily beat out non-CMS frameworks such as Laravel in terms of development speed and scalability. Drupal 8 is filling the functionality gap that WordPress just can’t do. I predict that enterprise migrations from WordPress to Drupal 8 are going to be on the rise over the next couple of years as businesses require more of what the internet has to offer. 

Which platform you go with will depend on your website needs. Small brochure type sites will easily find a home on one of the instant site builders and those with strong WordPress understanding might continue to use Wordpress. We at Ashday strongly believe that Drupal will be able to serve a wide-range of needs for a long time to come. The stability and scalability has only improved with the latest iteration and in the hands of the right team it can be made to do just about anything.

image with text offering access to our free CMS Selection quiz.

Mar 02 2018
Mar 02

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 the search module that 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”, but Apache Solr is 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.

Solr Logo

 

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, like Pantheon, 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.

Up Next: A deep-dive into our recent Solr integration. 

MIKE OUT

Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Dec 13 2017
Jay
Dec 13

In this day and age, it is rare to find a truly "standalone" website. The web as a whole was fundamentally built upon a concept of having different sites connecting together. At first, this was just done with hyperlinks from one page to another, but those simple days are long gone. Almost every website in this day and age has some integration with other websites or web services, and fortunately, Drupal is the perfect tool for creating a well-integrated website.

Analytics

Analytics are among the most basic integrations. Tools such as New Relic and Google Analytics can be leveraged on almost every website, and they are invaluable tools for website owners to learn how people are actually using the site and, therefore, how the site can be improved.

Using an analytics tool is often as simple as adding a tiny bit of code to each page on each site, and doing that is as simple with a Drupal site as it is with any other site. Where Drupal shines in this regard is in how easy it makes more complicated use of some such tools. For instance, the Google Analytics module not only makes it easy to add Google Analytics to the site, it also provides an immense number of configuration options so that you can tailor your use of Google Analytics specifically for your site. And where there isn't a module, there are other options: Web hosting company Pantheon provides free access to New Relic Pro for every Drupal site built on their platform, and using it is only a few clicks away.

Brainstorm your next development project with an Ashday Drupal expert! Request your free session today. 

Searching with Solr

For how common it is, searching can be a surprisingly difficult feature to implement. Many sites have a built-in "site search" feature to help with browsing the site, but building such a thing - especially with the quality of search results that people have come to expect from search engines such as Google - isn't an easy thing to do.

By default, Drupal includes a Search module which can be used for simpler sites, but a more robust solution is often needed for more complex sites. There are many options available, but at Ashday, we tend to use Solr when we need to add search functionality to a website. With a Solr integration, the site stores information that somebody might want to search for on a Solr server, and then when somebody searches the site, it lets Solr do the searching. Since Solr is well-optimized for searching large amounts of content quickly, this can give both faster and more relevant results than an entirely custom search. There are some pre-packaged Drupal solutions for searching with Solr, such as the Search API Solr Search module, but if that doesn't quite suit a site's needs, then a custom Solr integration can be built using Solarium instead. One great advantage Drupal 8 has over Drupal 7 is the ease with which it is possible to make use of code "libraries" such as Solarium.

Data Management

Everyone has different data management needs. Sometimes, Drupal's standard content and user management is all that is needed, and this works quite well for many standalone sites.

However, many websites aren't standalone. They share their data with other things - perhaps, the site is tied together with a custom mobile app, or it is part of a whole suite of related websites. In either case, there are two main options: Either Drupal is at the center of the system, managing the data itself, or it connects to some other site that's fulfilling that role.

Using Drupal at the core of interconnected systems such as this has not always been easy, but Drupal 8 has made it much simpler. Out-of-the-box, Drupal 8 contains a number of features and modules designed to make this use a breeze. This also enables the use of "headless Drupal", where Drupal is used for data management only, with other software connecting to it even on the main website.

Also common, is Drupal being used to display and manipulate data stored elsewhere, and for this there often isn't an out-of-the-box solution, due to the sheer number of different possible things that Drupal might be integrated with. No two integrations are quite alike. Where Drupal shines, here, is in the tools it provides developers with. A mixture of Drupal, custom code, and integration-specific libraries can be leveraged quite effectively by a skilled developer to meet whatever needs a site may have.

eSignatures with HelloSign

While things like analytics, searching, and data management are all common tasks that are used by many sites, sometimes an integration is more specialized. One example of this is integrating with HelloSign or other eSignature services. This sort of integration is rare enough that no ready-to-use Drupal solution typically exists, but it is also important enough to the sites that use it that the integration has to be done right. 

Back when we were using Drupal 7, we created a Drupal module for this particular integration, which can now be used by other Drupal 7 sites which need to receive digital signatures from users. Now that Drupal 8 is out, we're looking forward to working on another project that needs a HelloSign integration so that we can update the module and take advantage of Drupal 8's new features.

Customer Engagement

In our experience, most customer engagement tools work great with Drupal! Often, a company's Drupal website is the main way people interact with the company online. As such, it is the perfect place to do collect potential leads and to keep in touch with people. For companies with separate CRM systems, Drupal provides all of the tools necessary to send data on from Drupal to that system. If somebody update their Drupal user account, or fills out a form, the relevant information can also be sent to wherever it needs to go.

What's more, Drupal can be leveraged to help keep in touch with customers directly. While Drupal itself can send emails, this often isn't the ideal setup. Instead, Drupal can be used to create the emails, using the content and customer data that it has, and then it can send that email off to a separate service to send it. That service - perhaps the mailing features available from Knowledge Marketing - can then actually send that email out and manage things like email lists and subscriptions. Although Drupal could be used for such things, using Drupal alongside a specialized tool designed specifically for email management can create a much more flexible system at a fraction of the cost.

Conclusion

Although Drupal isn't perfectly able to do everything on its own (what system can?), the ease with which it can be integrated with other tools more than makes up for it. At Ashday, we've created countless Drupal integrations - some of them used by many of our sites, some by just a single site - and they are some of our favorite projects to work on.

Offer for a free consultation with an Ashday expert

Dec 06 2017
Jay
Dec 06

Illustrations showing a person signing a document from their tablet

As more and more companies make the leap to having entirely-digital communications with their customers or clients, some things have a tendency to stay on paper.  One common thing which lags behind the rest of the digitization process is the signing of legally binding documents... but no more. Now, services such as HelloSign are able to fill this void, and thanks to the HelloSign API, Drupal websites can fully leverage that service to make this important task easier both for you and for your customers.

Why HelloSign?

One common question about eSignature services is simple: Why use one at all?

Using eSignatures can be a great time- and paper-saver compared to conventional document signing. With eSignatures, you can still print a hardcopy if you want, but it's not strictly necessary to do so... no more needing to keep a painstakingly organized file cabinet! It's also just what people have come to expect. If somebody is signing up for access to a web application, for instance, needing to print and send in a document feels archaic by comparison. For these reasons and more, the benefits of eSignatures seems clear.

But, why use a service for it? Can't you just add a checkbox to the registration page of your website that says "I agree"? Well, perhaps, but depending on your use-case that isn't always a suitable solution. Imagine, for instance, that the thing being signed is an apartment rental agreement. When somebody fills out a document like that, you want a signed PDF at the end... something for your own records, and something that the renter can refer to later to review the terms, so an eSigned document if much better than simply recording that somebody clicked a button.

Furthermore, you also need the signature to be legally binding. Unless you want to navigate all of the laws to figure out how to make an eSignature be just as binding as a physical signature, using a service that has already figured out all of those details is a fantastic solution.

At Ashday, we like HelloSign because, in addition to meeting all of these needs and having many other useful features, we can use the robust HelloSign API to integrate the eSignature process directly into websites that need it.

Interested in a smooth, hassle-free HelloSign Integration?  Request your free consultation with an Ashday Drupal expert today. 

Drupal 7 Integration: Overview

Our first HelloSign integration was with a Drupal 7 site, and with that, we created and released the initial version of our HelloSign module for Drupal. This module can be used by any Drupal 7 website to facilitate the integration of HelloSign with that site.

Since this is an integration, somebody using the module still needs to have a HelloSign account that includes access to the HelloSign API and, for the best user experience, its embedded signing feature. What this module does is help get your Drupal 7 site connected to your HelloSign account and provide some useful tools for creating and managing eSignature requests.

The way the module works is simple. Once it is enabled on your site, there will be a page available on your site to enter your HelloSign API credentials. This page also has a useful "Test Mode" option to toggle whether eSignatures on the site should be "real" or just tests, which is very useful for when you are making changes to your eSignature functionality and want to be sure that it all works before people start signing any legally binding documents.

Once the HelloSIgn connection has been established, you're ready to actually use the module. Some Drupal modules create a full-fledged user interface for interacting with them, but since eSignatures can be used for so many different things, we didn't want to make any wrong assumptions about what people would want to do with the module. As such, what this module provides is a set of useful PHP functions that greatly simplify the creation of a HelloSign integration, rather than building a whole UI that might not work for all sites.

Drupal 7 Integration: The Details

If you hire a company like Ashday to build your website, of if you have software engineers at your company, they'll be the ones using the module to create an integration with the HelloSign API. In this case, you can probably skip this section. If, on the other hand, you're writing the code yourself, then this section is for you! The module's README has more details, but this should give a good overview of the overall process for using the module to integrate with the HelloSign API.

The heart of the module is the PHP function hellosign_generate_esignature_request(). All this function needs is the location of the PDF file to be signed, the names and email addresses of everyone who should sign it, a title for the document being signed, and a subject line for any emails sent regarding the eSignature. You can also create the eSignature in either "email" or "embedded" mode; we'll use "embedded" mode, since that usually makes for a better user experience. With this information, the function connects to the HelloSign API and starts the eSignature process. Assuming that all goes well, the function returns the ID of the signature request as well as information about the individual signatures needed. The request ID can then later be used by other functions to do other things related to the eSignature, such as cancelling the request, and the signature information can be used to move on to the next step: Building a page where the user can actually sign the document.

Perhaps surprisingly, this is one of the easiest parts of the integration.  The module includes a function called hellosign_get_embed_url(); give it the ID of a particular signature that you want, and it will return the URL for an iframe which you can include on whatever page you want users to go to to sign their documents.

Now, this is a Drupal 7 module, and what would a Drupal 7 module be without hooks? This module provides a single, vital hook: hook_process_hellosign_callback().  Any implementations of this hook that you create will get called whenever HelloSign notifies the site about a signature request being updated. This way, your site can know when a document gets signed or completed, and can do anything that it needs to. Need to save a copy of the signed document to your own server? The module has that covered as well. Just use hellosign_fetch_esignature_document() to get exactly the file you need, and then save it wherever you want in the file system.

Finally, if you need other, more advanced features of the HelloSign API, the module ultimately uses the HelloSign PHP SDK, so you can leverage anything you need from that even if the Drupal module doesn't specifically include functions for it. In theory, you could even create a HelloSign integration using just the SDK, but the Drupal module handles many common eSignature needs without ever needing to delve into a much more complicated utility like the SDK.

What's Next: Drupal 8

Of course, at this point, Drupal 7 is old news, and Drupal 8 is what all the cool kids are talking about. Well, don't worry: We're currently working on a new version of our HelloSign module for use on Drupal 8 sites. We've been using Drupal 8 for more than two years now (since before it's first official release!) and at this point we're pretty comfortable with the Drupal 8 way of doing things, so it's high time we brought the HelloSign module up to date. Since Drupal 8 is a much more robust and object-oriented system than Drupal 7, we're fully leveraging that to improve the structure of the module. This makes it both more flexibile to use and easier to add new features to as new needs crop up. Expect another blog post once the module is ready for use, and you can see all the improvements for yourself.

We're looking forward to building HelloSign integrations in Drupal 8 sites ... stay tuned.  

Free offer, talk to a seasoned Drupal expert.

Nov 08 2017
Nov 08

diet-Drupal.pngDrupal 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?

Server shown with many cables tangled together.

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, like Symfony, to make the system even more extendable and with less Drupal involved. That PDF converter library your friend likes that is installed with Composer can 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 use Solr or 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?

Brainstorm your next development project with an Ashday Drupal expert! Request your free session today. 

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.

MIKE OUT

Offer for a free consultation with an Ashday expert

Nov 01 2017
Jay
Nov 01

drupal-upgrade-crisis.jpg

The Drupal Upgrade Crisis is Over

Back in March 2017, Dries Buytaert, the creator of Drupal, published a blog post entitled "Making Drupal upgrades easy forever" in which he confirmed what we here at Ashday had already suspected: Drupal 8 has laid the groundwork for seamless upgrades to future Drupal versions. But what exactly does that mean, and what benefits could this have for your website?

The Dark Age of Upgrades

Prior to the release of Drupal 8, Drupal releases broadly followed a policy that included minor releases and major releases. Minor releases (such as upgrading from Drupal 7.18 to 7.19) were usually fairly simple updates. They would fix bugs, add in some small new features, and resolve security issues, but ultimately, it was rare for a minor update to cause any problems for a well-built Drupal site.

However, major releases (such as upgrading from Drupal 6 to 7) were a whole 'nother matter; they're basically different systems entirely.. Standard policy with major updates was that most anything that needed to be changed could be, even if doing so would make it impossible to seamlessly update a site from one version to the next. For instance, Drupal 6 included a feature by default that allowed each of a site's users to select what theme they saw the site in (changing the site's overall look and feel). In practice, not many sites made use of this feature, so it was removed in Drupal 7 so that developers could focus on the more frequently-used parts of Drupal. Of course, if a site used this feature, it couldn't be upgraded to Drupal 7 without either losing that functionality or having new development done to add a replacement. The Drupal way to make progress was to not tie the potential of the future to the decisions of the past.

What this has lead to, however, is that oftentimes, once a site has been built on one version of Drupal, it doesn't get upgraded to the next version without good reason. In fact, there are many sites still out there running on Drupal 6 simply because upgrading to Drupal 8 would be too expensive and time-intensive of a process.

Fortunately, the dark age of upgrades may be at an end.

Enter: Drupal 8

When Drupal 8 was released, the paradigm shifted. Drupal 8 is very different from Drupal 7 (even more so than 7 was from 6), and so upgrading a site to Drupal 8 presents many of the same difficulties as upgrades in the past. But, thanks to the hard work of the Drupal developers and everyone else involved in the project, future upgrades should be much simpler. Drupal 8's code has been written to make good use of web development standards in ways that past versions never even tried. Because of this, Drupal 8 is fundamentally a foundation that can be built on by future versions without needing a complete overhaul.

What that means is that any site which is kept up to date as minor releases come out should continue to work on Drupal 9 with minimal effort needed to upgrade it. Instead of everything changing at once like it did going from Drupal 7 to Drupal 8, old code and little-used features can be phased out slowly as better alternatives are developed and implemented.

And that leads us to the final result of this change of approach: Prior to Drupal 8, a site could be built and then be minimally maintained with security updates until the next version of Drupal came out, at which point it had to be rebuilt entirely. Now, a Drupal 8 site can be built, and if it is minimally maintained until Drupal 9, there might be a few adjustments needed to remove deprecated features, but there will certainly be fewer than in the old way. But what's more, if that Drupal 8 site is actively maintained, it may not even be using any deprecated features at all by the time Drupal 9 comes out, allowing that upgrade to be made with ease.

What Does This All Mean for You?

From a technical perspective, these are all great changes, but what does it actually mean for your website? Several things:

If you are on an older version of Drupal: Now is the time to upgrade. Upgrading from 6 is long overdue (it doesn't even get official security updates anymore!), but upgrading from 7 makes sense now as well. Before Drupal 8, it was common to skip versions… for instance, a Drupal 5 site would skip Drupal 6 entirely and get rebuilt on Drupal 7. But upgrading a Drupal 7 site to 9 shouldn't really be too different from upgrading it to 8… so, why wait? Upgrading now will help avoid any last-minute scrambling to update the site when Drupal 7 eventually stops getting security updates.

From a business and marketing standpoint, there's another hidden advantage as well. Before, redesigning a website often got tied to the need to upgrade Drupal. There wasn't much reason to do a big redesign, if you'd have to upgrade from one major release of Drupal to another just a year later, so the changes would get bundled together to avoid having to do two rebuilds. But what's more, taking on all the concerns of a site redesign alongside the technological challenges of a Drupal upgrade could make doing both at once a challenging task in itself.

Once your site is on Drupal 8, major releases should no longer require rebuilding the site… which frees up your Drupal developers to be able to do a redesign whenever it makes sense to from a branding or business perspective. Drupal 8 gives you the power to decide when a website overhaul should be done, rather than tying such upgrades to the technology the site happens to be built with.

Offer for a free consultation with an Ashday expert

Oct 23 2017
Oct 23

Drupal sometimes gets a bad rap for being overly complex, but aren't your site needs also complex? If they aren't, you can stop reading here, skip over WordPress and go straight to Squarespace. If Squarespace can’t cover all your needs, keep reading.

Okay, if you are still reading, then you have complex web needs. The good news is that Drupal has you covered. But simply saying your web needs are complex is too generic, so let's break it down and see how Drupal deals with different kinds of complex needs.

Do you have a lot of content?

Drupal doesn’t care how much content you have. With its out-of-the-box tools, Drupal gives you a nigh-infinite number of ways to organize and manage your content. 

The built-in, customizable admin tools allow you to have large amounts of content in an easy to use management system. On the frontend, a well-executed content driven design will give your users a great experience even if you have hundreds or thousands of pages to navigate. Having a good Drupal partner is the key to establishing a content plan on both the backend and frontend. 

Brainstorm your next development project with an Ashday Drupal expert! Request your free session today. 

What does your content look like?

People tend to think of content as being pages on a website, but this isn't quite accurate. Most websites have pages that are part static and part dynamic. Consider, for example, Amazon.com. Very few of the “pages” on Amazon.com are set in stone; instead, most of them are result of a search combined with filtering to show the user lots of individual pieces of content in a single view.

Instead of thinking of entire pages as pieces of content, let's break it down further. Content is:

  • Text
  • Images
  • Files
  • Products
  • Items
  • Locations
  • Data Points
  • People

The list goes on. Drupal doesn’t care how you define content, it simply gives you the tools to define it in any way you need to. Drupal then takes all of your different types of content and gives you the power to manage and display them together in countless configurations and displays.

For example let's say you have products and locations, each defined as individual pieces of content. Using Drupal, we can display the products that a location stocks on the location’s page and we can also display the locations that a product is available at on the product’s page.

Drupal allows you to publish the details of each type of content in one system and then use and remix that content across multiple pages. You can't do that with a single WYSIWYG (what-you-see-is-what-you-get) field on a page, like you would get with an out-of-the-box WordPress site.

A good Drupal partner can help you define the shape, size, and types of content that your website needs.

Do you have users on your site?

Having users on your site is always going to crank up the complexity of the site. Fortunately, Drupal is built to deal with support for user accounts right out of the box. You can have many types of users by assigning them different roles, and you can have hundreds or thousands of individual users. Drupal handles users much like it does content, with near infinite flexibility. Each user role has its own set of permissions and rules to follow. This allows you to do things like turning user memberships into products, relating users to content, and configuring what your internal team members can do to edit the site content.

Your Drupal partner can help determine what kind of users you need.

Do you want to grow?

Even if your needs aren’t quite as complex as described above, Drupal may still be the right fit, especially if you intend on growing. Drupal is built to scale. Defining types of content and users in your system now will save you from needing to do so in the future.

Your site may be just an idea and a few pages at the moment, but when it's time to grow, don’t let an inflexible website stand in your way. Today you may be selling your goods on a simple website, but tomorrow you may get that big wholesale order that needs to connect with a large datasystem to get product details and specs and even automate reorders.

A good Drupal partner will help build your small site with the foundations to become a big site.

You need Drupal

A good Drupal site is an indispensable business tool, but I would not recommend taking on building an enterprise or complex Drupal site on your own. Having a good Drupal partner is key to a successful Drupal site.

There are a lot of articles out on the web that make the case that Drupal is too hard or complicated. Drupal isn’t hard or complicated for Drupal people... and we are Drupal people. Drupal is complex but that complexity allows us to tailor your Drupal site to match your business.

We will handle the complexity of Drupal, and you can handle the complexity of your business.

Offer for a free consultation to determine if Drupal is the right choice for your organization

Oct 17 2017
Oct 17

when-drupal-is-bad-fit.jpg

My instinct is to say never….but if you are still wondering “Should I use Drupal?”, read on and we will take a look deeper to see if we can find some cases where Drupal may be a bad fit.

Brochure and small websites

Drupal can be overkill if your site needs consist of a page or two and maybe a webform. I would agree that the overhead of Drupal may be a bit much here, but you should also consider your future needs. Your simple site may need to grow into something that requires users, e-commerce, or more complex data handling. If that is the case then you would save money in the future by investing in a solid web framework early on.

Legacy Systems

If years of your data is tied up in a legacy system, it may be too risky to try to switch a site over to Drupal. That is understandable but you should also calculate the costs of maintaining the old system, the added time it takes to add new features, and the vulnerabilities that come up in older depreciated software. It takes a lot of planning and can be a bit tedious but a migration to Drupal 8 may actually cost less in the long run.

Small Budget

Drupal development costs due seem to be a bit higher than development on other popular content management systems. But I would say that the difference in cost is negligible, especially when you have a lot of custom needs. Drupal will actually save you money once it comes time to build custom features.

See our article on Drupal vs. WordPress for more details when comparing the true costs of a WordPress site.

If you truly have a tiny budget and many development needs, it is probably time to face reality and scale back to what you can truly afford, regardless of which CMS you choose. If you have a small budget and you can’t accomplish everything you need with a WiX website, then it may be time to re-think your web presence entirely.

No Drupal Experience

If your internal development team or development partner has no previous experience in Drupal, then it really might not be the best choice for your project. It is definitely worth the effort to learn, but be prepared to make big increases to your project timeline. However, this can easily be solved with supplementing your existing team with an experienced Drupal shop like Ashday.

It turns out that there are a few instances where Drupal may not be the best fit, but most of them can be overcome with some planning and evaluation of future needs and requirements.

If you want to build in Drupal but don’t have the right team for the job, you are in luck! Ashday can help with that. 

Offer for a free consultation with an Ashday expert

Oct 11 2017
Oct 11

web-development-vs-app-development.jpg

Smartphones have had an immense impact on the way we both interact with websites and how they’re built. In the early days of Android and iOS -- or even further back to flip phones that could access the internet -- websites weren’t designed to fit well onto a small screen. Mobile browsers did what they could to make them work, but it really wasn’t all that long ago that you had to double-tap on some text just so you could zoom in and read something.

There was an app-craze when the smartphone boom happened. Everyone needed to get an app. But is that still the case? Responsive web design is an alternative that many see as more appealing than investing in a site and an app, but can a responsive website fully replace a mobile app?

Responsive Web Design vs Mobile Apps

The vast majority of internet browsing is done on mobile devices now instead of on desktops or laptops, so it makes sense wanting to put time and effort into a finished project that will display well on a smartphone. But what exactly is the difference between a responsive website and an app? If you design a site responsively, users will be able to access it from any device with an internet browser and it should be able to adjust itself to fit whatever resolution and screen size they’re using.

A mobile app, on the other hand, has been specially designed to work on certain operating systems (Android and iOS being the big two) and at specific resolutions. Apps can also make use of things like QR codes, augmented reality, voice recognition, and more. Internet browsers are helping to bridge the gap here, though, and you’ve likely noticed features like Click to Call, User Location, and access to your phone’s accelerometer and gyroscope becoming more common when using your phone’s internet browser.  

Do I need a mobile app if I have a responsive website?

If you dive into data regarding how we all use our phones, you may see some compelling points for going with a mobile app. For instance, 90 percent of mobile activity is spent using apps. But let’s dive a little further into the data. Out of that 90 percent app usage, Facebook (specifically) commands a huge piece of the pie, as do things like messaging/social apps, games, and entertainment -- leaving very little room for anything else.  

A responsive website, on the other hand, is easier to access and share between users (no downloads needed!) and will help build a mobile presence that can be found via search engines. Responsive design will also be more friendly on your wallet and will take less time to build from the ground up than an app would. Going with a responsive website over an app also provides accessibility to more users. Apps can be a barrier for some older users who may be reluctant to download apps but are very familiar with accessing websites via their mobile devices.

Responsive web app as a replacement

Modern responsive websites are more than traditional html and css, they utilize robust frameworks that are closer to an app than a static website. Sites like this are known as web apps. It may have the same appearance of a mobile app, as well as most of its capabilities, but a web app doesn’t require a user to download it -- it just loads in-browser in place of the regular website. Historically, a weakness of a web app would be that it can’t access things like your camera or GPS, but hybrid web apps are now able to gain access to your phone's API, similarly to a regular mobile app.

Having a responsive web app also eliminates the need to submit your app to the proprietary Apple app store for Apple devices and Google Play for Android devices. On top of that, there is no need to post updates for each device type or worry about compatibility beyond standard cross-browser testing.

How to choose between a responsive web app and a mobile app?

In the end, you need to look at what will best serve your needs best. A mobile app makes sense for a platform like Facebook since they need to efficiently deliver tons of content and media, rely heavily on a positive user experience, and don’t need to worry about discoverability.

If having access to device APIs for your users is something that will greatly increase their overall experience but you don’t want to invest the extra time and money that a mobile app necessitates, then a hybrid web app may be the way to go.

You may also find that a standard responsive website offers everything that you need, and can forgo the added overhead and time that building a web app that accesses device features requires. Building a mobile site first also gives you the option to someday extend it to utilize device features.

If you’re not sure what the best solution is for you, feel free to reach out and we can help you kick around options.

Offer for a free consultation with an Ashday expert

May 24 2017
May 24
Drupal logo used in Ashday Blog

In Drupal 7, site deployments could be rather difficult on ambitious sites. Some database level elements were worth programming out in hook_updates (turning on modules, reverting views, etc) and some usually weren't (block placement, contrib module configuration). I remember days where a deployment involved following a three page long Google doc of clicks that had to be carefully replicated. Ugh.

A New Hope

So if you've taken the dive into Drupal 8, you'll quickly discover one of it's most prominent features - Configuration Management. Drupal 8's ability to manage configuration with yml files is absolutely amazing! It's nearly akin to watching Star Wars and thinking "Hey, I can do anything with a lightsaber! Fight bad guys, cut holes in doors, remove my hand cuffs. Sweet!"

The Empire Strikes Back

Here's the rub. Managing Drupal 8 configuration in complex real world apps is akin to building a real world laser sword after watching Star Wars only to promptly burn your face off and lose two limbs as soon as you try to fight with it. "Ambitious digital experiences" essentially equates to "arduous development concerns" and even config management can't save the day simply by existing. You must use it for good. You must unlearn what you have learned. I blogged a bit on this shortly after Drupal 8 released, but oh how much I learned since then!

We've been doing Drupal 8 pretty heavy for about a year and a half here at Ashday and had both the fortune and misfortune of needing to manage a more complex set up which quickly revealed our deficiencies in understanding how to properly manage config.

Here's the scenario: A client needs a site that will become the model for many sites, but they don't want them to be a single site with multiple domains and they also don't want it to be costly or complicated to keep them mostly similar from a functional perspective. Given that our preferred hosting solution is Pantheon, this quickly turned into an obvious Upstream project. And that means figuring out a new way to manage D8 config other than just import/export of the whole site.

If you aren't familiar, a Pantheon Upstream works nearly identical to their core updates - you have a remote repository that, upon code getting pushed to it, notifies you through the dashboard of your updates where you can apply them in the same way you do Pantheon core updates. It's pretty slick because it provides an easy way to have a big shared chunk of code and apply updates to many sites with a few clicks (well, except when nearly every update is major and requires hands-on management - but I'm not bitter).

The Phantom Menace

Our first try at this was to give the Features module a go, but at the time the interface was just too buggy to give us enough confidence to rely on it, it auto-selected what we didn't want and didn't select what we did, and it didn't support some key things we needed like permissions. As a result we decided to home brew our own solution. We knew these sites were going to have a lot of config in common, and a lot of config unique, and we needed to deploy to many of them all in different states without tragedy striking. So to accomplish this, we concocted the following procedure that we would run at deployment time, all from a single drush command.

  • Export the current site's live config (using drush) to the config sync folder
  • Copy all config files (with uuids removed) in our cross-site custom module over top of the config sync directory
  • Copy all config files (with uuids removed) in our site-specific custom module over top of the config sync directory
  • Import all config.

What this allowed us was the ability to allow each upstream site to stray a bit as they needed to, but we could be assured the config we cared about was prioritized in the proper stacking order. The approach ultimately wasn't that different than the goal of Features, but we were in control of the process, it was all live and it was relatively quick. And you know what? It worked! For a while...

And then it didn't. You see, the method we used caused Drupal to see every config file we were tracking (upwards of 300) as changed simply because of the missing uuid. So if only 8 config files changed in a deployment, Drupal was attempting to import hundreds of config files every time. This meant that it started to slow significantly over time as the site grew in complexity and eventually, we started having timeout issues and long deployments. We also started to run into issues when there was a significant core update (ie: 8.3) because so much config was being imported unnecessarily that wasn't compatible in that moment with the new code because db updates hadn't run yet. Not good. It was time for something else.

Return of the Jedi

The Jedi in question here is again the Features module. Or maybe it's Mike Potter. At least it's not me anyways. At DrupalCon Baltimore, I was set on speaking with Mike about how we were handling config because I simply knew there was a better way. If you don't know, Mike is one of the founders of the Features module and ran a great BOF on config management in Baltimore.

So I found this delightful man and laid out what we were doing and he reacted exactly as I had hoped. He didn't say that what we were doing was terribly wrong, but it made him visibly uneasy. After a chat, I discovered that Features had come a long way since we initially tried to use it and we should really give it another shot. He also explained some of the configuration of Features to help me better understand how to use it.

So we returned to Features now and are much happier for it. The thing is though that I don't think I would have really known how to manage it if we hadn't taken the deep dive into config and figured out how it needed to work. It all helped us a lot to decide how to incorporate Features properly for this particular situation so that I actually feel good about relying on it again. And that's how most good Drupal development goes. You really should know how something works before simply relying on a contrib module or someone else's code to take care of everything because otherwise you won't really know how to deal with problems - heck, you might not even know you have a problem! I personally don't prefer spending weeks writing code and then depending at a critical moment on a mysterious piece to make it all successfully roll out to production.

So as it all played out, we now understand what Drupal puts in config, what we care about and don't, what belongs in the upstream vs our site-specific modules vs no where, etc. Here is our current process after this 6 month long journey.

  • Revert the global base feature
  • If needed, revert the site specific feature
  • Run our previous script outlined above, but now on only the 5 or 6 role config files so we handle the permissions in the same fashion

So there you have it! For how long-winded this turned out to be, I'm glossing over a lot of details that are pretty critical to understanding Drupal 8 configuration (ex: blocks are a mix of config and content), but I recommend you do the same thing we did and really get your hands dirty and understand what's going on so that you don't get bit at rollout. After all of this, we feel even moreso that Configuration Management is an astoundingly useful component of Drupal 8 and now we find ourselves a bit sad when we update our Drupal 7 sites (a version we absolutely loved!) where we don't have this amazing tool. 

So good luck and don't hesitate to drop us a note if you have any questions or thoughts on this stuff. I'll probably change my mind on all of it anyways tomorrow. That's why this job is awesome.

P.S. I apologize that I didn't find room to incorporate Attack of the Clones, Revenge of the Sith, The Force Awakens or Rogue One, but the reality is that I just didn't have time to modify our whole approach to configuration in order to make this blog post more cohesive.

Offer for a free consultation with an Ashday expert

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web