Drupal

Which Base Theme We Use (and Why)

JD Collier — Tue, 16 Dec 2014 14:34:45 +0000

Which Base Theme We Use (and Why)

JD Collier Tue, 12/16/2014 - 8:34am

There are so many website themes, frameworks and opinions out there ... how do you decide which is the best foundation for your next project?

You can purchase a ready to use theme, start from a base theme with as much or as little foundation as you like or you can build your own HTML from scratch and then add Wordpress or Drupal API code to your HTML.

I have personally used all of these approaches across various projects, but I have a strong preference these days for Bootstrap as the foundation for every website I build on Drupal, Wordpress and small static pages.

Why I don't use the other approaches any longer

Of course, there are more reasons than I can list here, but a few notes on why I don't start projects without Bootstrap:

Ready to use purchased theme: There are many thousands of Wordpress ready to go themes and fewer (but still many) Drupal ready-to-go themes. My biggest reason to avoid these has to do with the design being mostly locked in already. These themes are usually complete designs just waiting for a logo, copy and images. I find I have to argue with the theme too much to bend it away from the built-in design. Some of these themes are so complex they actually change the CMS core functions, but I need consistency across projects in the CMS so my content editors can work across client sites.
Build your own HTML: For years, my preferred approach was to build my own perfectly clean HTML/CSS. This has the benefit of being clean and exactly suited to the needed design. In recent years, though, I have fallen out of love with this approach due to the need to reinvent the wheel with every project. Now that every website needs to be responsive and work across browsers and devices and websites requirements include sophisticated CSS3 effects, jQuery magic and HTML5 sophistication—it just doesn't make sense to start over with each project.
Wonderful frameworks like 960 grid and others don't include all the LESS/SASS mix-ins that I have at my fingertips with Bootstrap.

Why I use Bootstrap

Before I begin, I should include a quick disclaimer—I have used and also love Zurb Foundation. Bootstrap and Foundation have pretty good feature parity these days. We chose Bootstrap when Foundation didn't have as much Drupal support, but Foundation has pretty robust Drupal support now so in the end you can choose by features meaningful to you.

Boostrap includes all the documentation and code to work across browsers and devices.
Bootstrap includes tons of mix-ins that allow sophisticated content even inside the WYSIWYG. I also use it in template code and event in Drupal views and Drupal Display Suite.
Bootstrap has mobile functionality built in. Whether I'm mobile-first or desktop-first, I am pleasantly surprised when I'm styling a page and then check other breakpoints and almost every time, it is already 95% there ... I just need to add a few adjustments here and there.
Many common advanced widgets are already included: buttons, carousels, accordion lists, tabs, and more are already included and just require you to add some classes to your html output.
Lots of documentation already exists. If I run into an issue, I can check the Bootstrap website, Stack Overflow and Drupal theme support issue queues.

Drupal-specific modules used to help create a Drupal Bootstrap site

Drupal Bootstrap theme
Display Suite Bootstrap Layouts (I'm a ds person, but I know there are Panels helpers too)
Views Bootstrap: This module adds displays to Views to allow you to output Bootstrap grids, accordions, carousels and more.

What do you think?

If you've tried one of these methods and have other opinions, please chime in. I seem to check out themes and frameworks like a hobby. I often find myself downloading and playing with a new framework or theme and constantly evaluating it against what I do now. Have you found something better?

Submitted by WorldFallz on Tue, 12/16/2014 - 2:48pm

Totally agree! And have recently also switched to a complete bootstrap operation. I'm in the process of migrating all my sites so it.

The efficiency gained from learning and knowing just ONE theme system is worth it's wait in person hours, lol.

In addition to the modules also mentioned, checkout:

https://www.drupal.org/project/panels_bootstrap_layouts

and

https://www.drupal.org/project/bootstrap_tour

Submitted by Rajab Natshah on Wed, 12/17/2014 - 6:48am

Bootstrap theme is the way.
But I find the Open Framework is another way.

https://openframework.stanford.edu/
https://github.com/SU-SWS/open_framework/tree/7.x-3.x

Submitted by JD Collier on Wed, 12/17/2014 - 10:03am

I haven't been able to use Open Framework because I've found Bootstrap 3 to be a vast improvement ... I would probably not use Bootstrap if I was stuck with v2 for what I need.

I just did a quick search and saw a fork or two but didn't see anything supported. Do you know if they ever ported? I'm wondering if Stanford might be slow to act since Bootstrap moved to MIT licensing.

Any openframework on v3?

4 Challenges With a Webforms Project, Part IV

Travis Flatt — Wed, 03 Dec 2014 16:27:03 +0000

4 Challenges With a Webforms Project, Part IV

Travis Flatt Wed, 12/03/2014 - 10:27am

Welcome to the fourth and final part of my in-depth look at customizing some default behavior in Webforms, and in this installment, Drupal’s Bootstrap theme. Today we’ll look specifically at repurposing bootstrap alerts and some more general minor DOM manipulation.

(Here’s Part I, Part II, and Part III for easy reference if you’re late to the party.)

Challenge #4: Thank you, come again!

So, at this point in the project, the form behaves as desired right up until a successful submission.

As we start looking at the form’s confirmation behavior, it’s currently reloading the page and giving us a pretty generic bootstrap alert box with some confirmation text. This is with the basic webform setting of sending a confirmation to the same page as the submission form. We could also redirect to another page, but in this instance we don’t want either of those things.

The desired behavior is for the area with the form to remain open upon submission, and have the form be replaced with a thank you message box that can be closed in much the same way as the form itself (much like the toggle effect here, to refresh your memory).

Before we do anything, we want to be sure we’re on an actual confirmation page. Our bootstrap theme has us set up here by putting an element right there on the page for us, even though we don’t want to look at it. In this instance, I’m just going to add a class to that particular bootstrap alert’s parent, which will already be set up in CSS with display: none.

$('.confirmation-message').parent().addClass('form-confirmation');

Customize that confirmation

At this point our confirmation page is just getting a hidden bootstrap alert div sent to the page. We can use that as our condition for triggering the confirmation behavior, but first we check to see if that particular alert box exists.

if ($(.form-confirmation).length) { // Do things here }

Once we know that we’re working with a completed, validated, and confirmed form entry, we’re going to place our confirmation message right there in the toggle area where our original form once lived.

if ($(.form-confirmation).length) {

$('.form-div').before("<div class='alert alert-info alert-dismissible signup-confirmation' role='alert'><button type='button' class='close confirmation-corner-button'><span class='close-button-text '>Close <span aria-hidden='true'><i class='fa fa-times' ;></i></span></button><h2>Thank You!</h2><p> Your message has been sent. Thank you for your interest.</p><div class=' close-button'><button type='button' class='btn close-confirmation-button'>Close</button></div></div>");

This creates a new alert box more in the area of where we want it. In addition to the “X” in the upper right corner, we’re also adding a more explicit “Close” button in case the purpose of that “X” isn’t immediately obvious to our user.

Also, we’re going to scroll to the thank you message.

$('html, body').animate({ scrollTop: $(".signup-confirmation") .offset().top - 100 }, 500); }

Closing things up

Now all that’s left to do is to ensure that our two “Close” function buttons do the same thing. We want them both to close the form/confirmation area and slide back up to the original position on the page.

$('.confirmation-corner-button').click(function(e) { $(this).parent().slideUp ('slow'); $('html, body').animate({ scrollTop: $("html") .offset() .top }, 800); (e.preventDefault) ? e.preventDefault() : e.returnValue = false; });

This should look familiar — it’s pretty similar to the slide code we used back in Part I to open the form in the first place.

Finally, we just force the second button’s click action to trigger that of the first instead of its own.

$('.close-confirmation-button').click(function(e) { $('. confirmation-corner-button').trigger('click'); (e.preventDefault) ? e.preventDefault() : e.returnValue = false; });

JSFiddle with some simple shared click event functions can be found here.

[Image: EduardoEquis]

Product Review: New Relic APM for Drupal Performance Tuning

JD Collier — Tue, 07 Oct 2014 15:36:12 +0000

Product Review: New Relic APM for Drupal Performance Tuning

JD Collier Tue, 10/07/2014 - 10:36am

New Relic APM (Application Monitoring) is an amazing tool to help you tune the performance of your Drupal website.

Application Monitoring allows you to trace Drupal performance. You can deep dive into Drupal tuning with analytics on the performance of Modules, Hooks, Views and much more.

I can quickly scan the data to determine which module has the slowest average call time. I can peer into the running website to determine where the roadblocks to performance are coming from.

One of the most useful pieces of data is the average load time for a page and the Apdex score for the site. The Apdex is a complex algorithm which measures user satisfaction of application performance / response time.

There is a mountain of data in this tool, but here are a few highlights that affect Drupalistas the most:

Modules that are the most time consuming for the server
Which Hooks are consuming the most resources
Views that take the most time to run
Most time consuming / slowest queries
Measure page views as a percentage of total page load times
Ajax performance bottlenecks
Javascript error analytics
Page load statics by browser

The list really could go on and on. You are able to drill into almost any metric to get more detailed information.

How to get it

We love Pantheon for Drupal hosting and most plans come with New Relic APM. You can also sign up on newrelic.com for their SaaS APM solution.

4 Challenges with a Webform Project, Part I

Travis Flatt — Tue, 23 Sep 2014 13:42:59 +0000

4 Challenges with a Webform Project, Part I

Travis Flatt Tue, 09/23/2014 - 8:42am

I like Javascript. There, I said it. It’s all out there floating across the internet, and no doubt my kids will mock me for it twenty years from now when they’re busily developing code via direct brain-link. For now, though, I find it to be a remarkably versatile problem solver for things that just aren’t quite handled by the default behavior of your favorite framework or CMS.

A recent Drupal project allowed me the opportunity for some Javascript/jQuery troubleshooting, which I usually find to be the fun part of any given day. Even when I’m not technically at work.

Computering until this point, basically.

I was originally thinking this would make for a single quick post, until I started explaining things. I’ve broken it up into four easily-digestible bites, each focusing on a specific problem that needed to be handled and its solution. First, we begin with...

Challenge #1: Hide the form

I was working in Drupal for this particular project, but the jQuery methods I’m going to talk about are pretty platform agnostic.

In this case, we wanted the form to not immediately appear on the page. The desired behavior was the appearance of a shiny button, which when clicked would display our glorious webform.

This is a pretty common general usage, and easily accomplished with a display: none in CSS.

.hide-this-element { 
  display: none; 
}

With the element stealthily hiding on the page, we need to take over the behavior of our button. In this case, I’m going to use jQuery’s slideToggle()method just to give the added functionality to open or close the form with the same button.

var button = $(‘.button-selector‘);
var form = $(‘.form-selector');

button.click(function(event) {
 form.slideToggle(‘slow');
 if (button.text().trim() === ‘Default Text') {
			button.text(‘Different Text');
		} else {
			button.text(‘Default Text');
		}
 event.preventDefault();
 $('html, body').animate({
	 scrollTop: form.offset().top
	 }, 800);
	 form.addClass('open');
});

So, there’s a few extra things going on here. The function itself is living inside a jQuery .click()method that’s telling the browser, “When this thing is clicked, do these things.”

An important element of event listeners like this is that event.preventDefaultbit. For most modern browsers, event.preventDefault()will work just fine in keeping the browser from doing the default behavior associated with the element. Usually this is a link. We don’t want the browser to look for an href attribute or redirect the page here, so we block that behavior.

(The actual production code is a bit heavier for some things, and preventDefault()is one of them, as it doesn’t work with IE8, but if I start turning this into a discussion of what doesn’t work on IE8 we’ll never get anywhere.)

There are a handful of options with slideToggle, but we’re keeping it simple here, only passing it ‘slow’. This refers to the speed of the animation when the element we’re hiding or displaying is revealed or hidden.

The conditional isn’t something that made it into production, but I threw it back in for the sake of building a more interactive event handler for this discussion. By using slideToggle(), the button has hide and show functionality. I like the idea of changing the text of the button to refer to whatever its current action will do.

The last bit is using the .animate()method, which has enough options to fill a book. Here we’re using it for a bit of user experience consideration. A big form has just opened, so we’re going to assume the user actually wanted to use said form and scroll the screen down to where it begins.

Working example here.

Next time we’ll talk about problem #2: Hide the form some more — which turned out to be a significantly different problem than the title might imply. We’ll cover some default webform rendering behavior, the problems it can cause, and ways to work around it.

[Images: Simon Pow, Patrick Gensel]

A module I've been wanting for a long time — insert a block in WYSIWYG

JD Collier — Tue, 01 Jul 2014 13:35:43 +0000

A module I've been wanting for a long time — insert a block in WYSIWYG

JD Collier Tue, 07/01/2014 - 8:35am

Sometimes what you are looking for is right in front of you. I have been searching for a module to allow me to insert a block into a WYSIWYG field. I tried looking for a Drupal implementation like Wordpress Shortcodes, perhaps the SimpleAd module would do what I'm wanting, maybe there is a Ckeditor plugin written for this? I came up short.

Suddenly, the obvious choice

I need to be able to insert small bits of content into WYSIWYG that can be edited once but placed all over the site. In this case, I needed a call to action that only appeared on certain pages and I wanted the CTA to be inline and not outside the content.

It suddenly hit me to start searching for "insert a block into WYSIWYG" and I felt stupid. The second result is a module called "Insert Block." I quickly spun off a testing environment of my site and installed the module. It works beautifully.

How it works

After you install the module, there is an administration screen where you can adjust permissions (the default worked just fine for me). Before you start using the module, you just need to access the Text Format and turn on the "Insert Blocks" filter.

The code is [block:module=delta]

Look Greek? It actually isn’t. Lots of modules can produce blocks; in this case I am making a simple text block using the block function itself. This means the module is named "block." The delta is just fancy Drupal-speak for which one to display.

You can find the block delta by hovering over the configure link for the desired block and the delta will be listed in the URL path. For a block created in the blocks screen, it is a number. If the block is created by Views or another module, it could be a string.

Insert [block:block=10] into the WYSIWYG editor and voilà! The block is inserted and if you change the block content, it will change everywhere it is used.

Give it a try! What do you think? Also, I've love to hear if you found another solution.

[Photo credit: Jeff Harris]

Submitted by Danny on Wed, 07/02/2014 - 9:41am

And what happens when you have 1000 nodes with block tokens inside and you want to disable this module because you no longer want to use its functionality? :)

Submitted by JD Collier on Wed, 07/02/2014 - 9:45am

What happens? I would imagine silent tears in the corner of my office.

But ... there are plenty of things that if they might happen, would create a lot of work on every site.

Submitted by Håvard Pedersen on Mon, 07/14/2014 - 7:26am

If you want to display those nodes, you ARE still using its functionality.

Varnish, Memcache — Cache All the Things BUT Still Run Dynamic Code

JD Collier — Tue, 03 Jun 2014 13:23:14 +0000

Varnish, Memcache — Cache All the Things BUT Still Run Dynamic Code

JD Collier Tue, 06/03/2014 - 8:23am

There are quite a few caching options out there, and we frequently combine several services to cache every little piece of a site. Think about it: standard Drupal cache, Varnish, Memcache, Redis, various files coming from CDNs, and more.

What if you want something unique?

These are great tools to create peppy websites, but what happens when you want to change a menu based on a cookie value or create a view with a random sort? There are lots of valid use cases for small pieces of unique content.

You will run into issues where the content is cached and once the page is rendered and cached, it will continue being served up with the same render for every subsequent person — the random sort, the randomly loaded image, the unique output based on a cookie value will not work.

Here are two quick options:

Move the dynamic content from PHP to JS

If you move the execution of the dynamic content from PHP (which gets compiled and cached) to jQuery, the unique code gets rendered by the browser and not the server. This allows you to display custom code on the page without it being cached.

Use the Ajax Blocks Drupal module

Another way to do when I need or want to code this in PHP and I don't want it in jQuery visible for the world to see is to use the Drupal Ajax Blocks module.

I had a scenario where I had a cookie written by a web application on a subdomain and a different server and the servers Varnish cache was very strict with what I could do with cookies. I needed to pull in encrypted data from the cookie and use the openssl_decrypt PHP function to decrypt and display unique data for users of the app, but anonymous to Drupal. Varnish would cache the page and there was no way to edit this vendors Varnish config to allow my content to run.

Ajax Blocks saved the day. I had my code run in a block .tpl file and set the block to run from Ajax Blocks; the page rendered and then my code was pulled in via Ajax and wasn't cached.

You can also use Varnish ESI (Edge Side Includes), but that didn't work for me in this server environment.

Cache all the things! Use all the aggregation and caching tools at your disposal — you can still serve small bits of uniqueness on the page.

[All the things image and meme originated from Allie Brosh]

Crawling vs. Indexing: Robots.txt and sitemap.xml

JD Collier — Tue, 15 Apr 2014 14:55:05 +0000

Crawling vs. Indexing: Robots.txt and sitemap.xml

JD Collier Tue, 04/15/2014 - 9:55am

Sometimes you need to prevent a site, page or everything at a particular path from showing up in Google search. I've heard people say to just disallow the page in robots.txt file. This is actually incorrect.

If you simply add a disallow to your robots.txt file, then it is true that Google will not "crawl" that page, but if you have that page in your sitemap.xml file then the page will still be submitted to the Google Index.

You will find your disallowed content in Google search.

For example

Scenario:

I have created a view with client logos and I don't want each node to be seen. I only want the nodes to appear inside my view.
The nodes are at a /clients path.

In this scenario, I will do just one thing:

Add noindex to the page

A common error I've seen is for people to add:

disallow: /clients to robots.txt

I've seen people perform this update and think this will prevent the page from showing in Google search. However, if you are using the sitemap.xml module to create your sitemap.xml file, chances are you also have it set to auto submit your index to Google and possibly other search engines.

Crawling vs. indexing

You have prevented Google from crawling your site, but you may have just allowed your sitemap module to autosubmit the url to be indexed. It will not crawl further after this link, but it has still been indexed.

Note: You should also configure your sitemap.xml module correctly, but that is another topic.

Robots.txt tells Googlebot and other crawlers what is and is not allowed to be crawled; the noindex tag tells Google Search what is and is not allowed to be indexed and displayed in Google Search.

One step further

This part hurts my brain, but there seems to be consensus that you should not add items you want to prevent from search to your robots file. Instead, you should allow them to be crawled and have a noindex tag on them to then ensure Google knows not to display them.

Development environments

On a development server, this is much simpler. You can tell Apache to globally disallow all files. In the Apache httpd.conf file, add this:

# Globally disallow robots from the development sever Header Set X-Robots-Tag "noindex, noarchive, nosnippet"

You can also do this in an htaccess file to add this header in a more granular scenario.

What do you think? Agree, disagree, or duh? :)

[Image by giorgio raffaelli]

Submitted by kalabro on Wed, 04/16/2014 - 9:05am

Both robots.txt and sitemap.xml are recommendations. Usually you need to configure 403 HTTP status for non-public data.

Submitted by Your Name on Mon, 04/21/2014 - 6:51pm

Nice post. It's a duh and a jeh all in once. We see a lot of things go wrong with robots.txt and sitemaps because somehow all website developers, hobbyist and pro alike, need to do some seo it seems. They then turn to the usual suspects that are top of mind resulting in people putting in regular expressions in the robots as well. So the want to disallow a url and end up take down a whole tag or category with 40 valuable pages on it.

Truth of the matter is that the real masters of the crawl and indexing process do not use robots.txt nor a xml sitemap. A well designed and structured site should provide ample breadcrumbs for the spider to follow starting with an effective menu and navigation structure on the front page for every website as not doing this causes a chain reaction like effect on the indexability of a site as a whole. When we do not cut corners we manage to get millions of pages indexed in the first year for new websites. How? With with followed links on to targets we choose and for the rest it’s never cutting corners.

Submitted by Stefan on Sat, 07/05/2014 - 3:26pm

Commands in a robots.txt file are requests, not commands, to web crawlers, which they hopefully choose to honor.

However malicious crawlers will actually look for the locations of hidden content in robots.txt - which they would otherwise not have discovered if the robots.txt file was not present.

That is why I believe it is better not to specify the location of hidden pages using robots.txt, but instead with a meta robots tag with a noindex value (or other solutions f you have access to server configuration.)

Submitted by ahmed on Wed, 08/06/2014 - 9:17am

so what if i submitted both xml sitemap and submitted another sitemap (for videos for example) in robots.txt? are both of them gonna be indexed? or one will override the other? here's exactly my confusion...

i actually have my sitemap in the root of my site, and i am in process now for making my content rich by adding videos and implement video SEO for it, so the video seo tool is advising to add 1 line to robots.txt to point to the sitemap that is hosted on their servers for videos, i am not sure what to do now.. i wish if i have separate sitemaps, but not to index them in one file, i want to keep the default way for videos to be added to robots and leave my other sitemap as it is, how could i perform that?

Why I Love Pantheon for Drupal Hosting

JD Collier — Tue, 25 Feb 2014 14:55:29 +0000

Why I Love Pantheon for Drupal Hosting

JD Collier Tue, 02/25/2014 - 8:55am

We have been using Pantheon for several months now and I am ready to declare it a strong winner for us. If you haven't experienced it, Pantheon is a hosting platform that is optimized for Drupal.

I've used so many hosting platforms — from tiny GoDaddy hosting plans to beefy dedicated servers with Rackspace Cloud Sites and Rackspace Cloud servers in betweeen. I love several things about Pantheon and that is what I wanted to focus on today.

Time-savers

Dev -> Test -> Live

Every site on Pantheon gets a Dev, Test and Live environment.

You edit your files and database and then migrate with a click into the Test environment. Then you can migrate to the Live environment.

At each stage, you can choose if you want to migrate only files or if you want to also migrate the Drupal database.

Of course, I can do this on my own on a server where I have command line and use Drush. It is simple with Drush as well, but it is not quite so point and click easy.

The biggest benefit comes from zero time setting up a server. I just fill out a wizard to create the new site and environments and the rest comes with it.

Git version control

Git is baked in...with flexibility to use SFTP as well.

I can add theme files and modules through Git workflow and quickly add them via SFTP; Pantheon inserts the files into the Git workflow for me. I love this!

When I upload a file with SFTP, Pantheon sees it immediately and asks for the commit message to add the files into Git. Then, I can migrate the code from Dev to Production.

Status checks

Pantheon automatically runs a number of status checks on your site. This is much more in-depth than a Drupal Status Report. It reports on Database usage, a few best practices in Drupal setups, caching (Pantheon uses Varnish), modules best practices, Views caching status, and error log warning.

The great part about this is the fact that they aren't just warnings. Each warning lists instructions and recommendations on fixes to your site.

Backups

Backups are a simple click and they begin daily backups for Drupal, the file system and the database. A click or two — that is all it took.

Drawbacks

I've only run into two issues so far with Pantheon.

First: Their Apache Solr implementation. The way Pantheon has Solr set up, you aren't able to modify the stopwords.txt files and a couple of other Solr settings. I can't imagine this being a large issue for 99% of the sites out there, but I have one where the word "will" is included in the stopwords.txt file that cannot be edited. This website has a lot of information about "Wills" (like after you die, you leave a will). Solr stop words help prevent common words from being searched like "I will" (used as a verb). Pantheon support says they have a solution for this issue coming in a few months.

Second: Pantheon's Varnish implementation is especially aggressive. This makes sites very responsive and that's awesome. On the downside, those outlier scenarios where you need customized data based on a cookie value require a little extra effort. They do have a few ways to bypass cache, but they don't work for all scenarios. I have a site where I had to implement ESI (Edge Side Includes). ESI seems to be working, but we're still testing.

Third: Price. There is too much of a jump in price between the $25 plan and the next plan at $100/month. If you have a super simple site that happens to need SSL, you have to bump up to the $100 plan and then also pay $30 more for static IP, which can be too much for some clients.

Conclusion

I expect a few issues in any server situation, and I love so many features of Pantheon that the few issues are not show-stoppers.

Submitted by Digett: Why I … on Tue, 02/25/2014 - 11:32am

[...] If you haven’t experienced it, Pantheon is a hosting platform that is optimized for Drupal.read more drupal, drupal answers, drupal king, drupal modules, drupal stack exchange, drupal supportShare [...]

Submitted by Jeff on Wed, 02/26/2014 - 1:43am

You can get equivalent service and performance with better limited SSH access and the full power of Aegir staging at a much lower cost from omega8.cc and koumbit.org. Pantheon limits you to one site per account at which point I did a U-turn. For some reason these alternatives don't get as much attention but they're worth a look. An honest comparison: https://omega8.cc/compare

Submitted by Scott on Sun, 03/02/2014 - 12:24pm

I have recently switched several sites over to Pantheon also. It is a pretty awesome platform. But like all tech, not without flaws. Several of which are mentioned above. I haven't hosted on Omega8 or Koumbit, but I am very familiar with Aegir and use it to host and develop many sites also. Aegir is also an awesome project, but Aegir and Pantheon work very differently.

Pairing Static Websites with CMS

Mark Figart — Thu, 16 Jan 2014 13:00:00 +0000

Pairing Static Websites with CMS

Mark Figart Thu, 01/16/2014 - 7:00am

I’m going out on a limb by saying we may be on the cusp of a revolution as it relates to how we build, deploy and manage websites. That’s a strong claim, but witness the new Reese’s candy of web technologies: Static files combined with the content management system.

Separately each has a certain charming flavor along with any number of nutritional deficiencies. Together, though, they create a compelling recipe for the future of the web.

Static files

Static websites are built with HTML, CSS and maybe a few javascript files. The websites are “static” because the web server doesn’t dynamically assemble pages before serving them up to a requesting browser.

The files are served up as-is straight from the file system…right from where the webmaster put them after the files were created. There’s no server-side scripting going on, and no database.

Static websites avoid two big problems that we might face using some other approach.

First, static sites are blazing fast. A web server tasked with serving static sites can run circles around a web server bogged down with executing server-side scripts and making twenty-plus database queries per HTTP request. It’s an all-too-common scenario.

Second, static sites typically don’t expose the vulnerabilities that so often come with a site dependent on execution of scripts like PHP and ASP.net and running on the public Internet. Avoiding this complexity, a static website in and of itself offers hackers little in the way of exploitable security vulnerabilities.

The downside of static

Unfortunately, static websites don’t lend themselves to the serious work some might demand of, say, a mission-critical sales and marketing tool.

Let’s sum it up this way: Static sites offer no inherent build and management interface. Without providing a way for non-technical resources to manage content, static websites can hardly be taken seriously in some contexts.

Content management systems

Content management systems have been around and quite functional now for at least a decade. They are, themselves, sophisticated applications that typically run on a site owner’s web server. They were developed as a means to overcome the shortcomings of the static file approach to building and managing sites, and they represent a huge leap forward.

A few benefits that the typical CMS delivers include:

User administration
User authentication and authorization
Flexible permissions schemes
Content modeling
Content entry and updating
Content query and output
URL handling

The list is hardly comprehensive. But even if the CMS did little more than what the list describes, you can imagine the immense value wrapped up in these functions alone.

The downside of the CMS

Despite its value, the CMS comes with its own baggage.

Untuned, a CMS can be disappointingly slow. The traditional solution has been to throw more technology on the stack in the form of high-performance caching mechanisms. In essence, these solutions create, you guessed it, a “static” version of the site, and serve pages from it in response to requests.

This averts having to go through the more resource intensive process of regenerating responses from from the database upon each request. Practically speaking, however, these caching solutions tend to be complex and expensive.

Performance isn’t the only common complaint of CMS users. Popular stacks like Drupal, Wordpress, and Joomla are often attractive targets for hackers.

To avoid nasty outcomes site owners often endeavor to keep their CMS current with security patches. It’s an effective, although expensive, proposition.

Static websites let us avoid deploying big and complicated applications where every hacker can try to work their tomfoolery.

A match made in Internet heaven

So what if we could assemble an approach to building, deploying and managing websites with all the benefits of static files — including speed and security — with the robust build and management capabilities of a tool like Wordpress or Drupal?

To be fair, variations of this approach have been in existence for years. But recently I’ve caught glimpses of what is apparently a resurgence of the idea.

The concept is simple: Build a website using a CMS, but rather than deploy the CMS directly on an organization’s public web server, we extract a static representation of the site’s output in the form of a complete file and folder hierarchy. This static version of the site is what gets pushed to the web server.

To conclude

Call me crazy, but once existing attempts at making this happen mature a little, I believe we will see widespread adoption of the technique. I can’t wait to explore some of the efforts I’ve uncovered thus far.

Is it a panacea? Of course not. Fact is, the most common CMS platforms fall short in other ways that beg a better mousetrap. But this is movement in the right direction, and Rome wasn’t built in a day.

What do you think of the idea of the static website?

Submitted by Digett: Pairin… on Thu, 01/16/2014 - 10:19am

[...] read more [...]

Submitted by Digett: Pairin… on Thu, 01/16/2014 - 10:28am

[...] read more [...]

Submitted by Nir on Thu, 01/16/2014 - 11:33am

We at Gizra are working on doing just that - pairing Drupal with static sites: http://www.gizra.com/content/drupal-x5-faster/

Submitted by Mark Figart on Thu, 01/16/2014 - 11:46am

@Nir Yes, I saw this just within the past couple of weeks, and it was the primary catalyst leading me to write this post! I didn't mention it in this article only because I wanted to first have an opportunity to get my hands on it and understand how far along you guys are. I'm super excited to explore it, and hope you won't mind me reaching out to you for help or some comments before I write about it.

Thanks for reading and commenting!

Submitted by Nir on Thu, 01/16/2014 - 11:58am

Sure thing, we'd be happy to help you get acquainted with Zariz when you get some time.

Meanwhile, a video of Amitai discussing it with jam went up today, if you're interested: http://www.gizra.com/content/zariz-on-tv/

Submitted by mikeytown2 on Thu, 01/16/2014 - 3:38pm

Old school way of doing this is to use the boost module. https://drupal.org/project/boost

Submitted by Mark Figart on Thu, 01/16/2014 - 4:07pm

@Nir, the video is great. I plan on recommending to others in the office. Thanks for sharing.

Submitted by Mark Figart on Thu, 01/16/2014 - 4:21pm

@mikeytown2 Thanks... have heard this now from a couple sources. While it doesn't address *everything* that some other solutions might, I'd still like to try it out for myself.

Submitted by Gijs on Thu, 01/16/2014 - 6:20pm

Funny to read this. Was my idea as well. I had a Drupal website but then realized it was doing lots of db dynamics to serve not-user-specific pages.

I now have a custom backend which produces new json files every 15 minutes (yes, its a very dynamic website !) and then use grunt / handlebars to produce new 'static' html files.

I think most websites not having user-specific content would be much faster (on cheaper hosting) with a solution like this. Instead of doing lots of calculations for every request (and putting a lot of effort in optimizing that), the calculations are done just once in a while. No expensive hardware needed.

Submitted by Mark Figart on Fri, 01/17/2014 - 10:40am

@Gijs Thanks for taking the time to read and respond. Not surprising that great minds think alike. :-)

Submitted by John_B on Fri, 01/17/2014 - 3:12pm

I agree this looks like the trend. However I cannot see how pushing a CMS site into static pages improves on using Boost, or a public-facing Varnish server, with a fresh cache (e.g. refreshed by crawling? An automatically rebuilt static site is in effect pushing static pages; a public-facing 'Boosted' or Varnish server in effect pulls them off the CMS backend. How is pushing static pages better than pulling them with Boost or Varnish?

Submitted by Mark Figart on Fri, 01/17/2014 - 3:36pm

@john_b So "better" is subjective, right? As someone supporting a good number of sites, the advantages from my perspective include (1) getting Drupal and its vulnerabilities off of the public web server and (2) eliminating the use of yet another technology (or module, at the very least). Simpler tools mean lower costs. But I wouldn't say "better", as my evaluation criteria won't necessarily be the same as yours. To make one other point, I LOVE Drupal... and have loved it for years. It's an awesome tool, and stands above many if not most of its peers. But it's power does not come without a few strings attached... as with any other piece of software.

Submitted by Brice on Sun, 01/19/2014 - 10:38pm

Mark,

I think this is a great idea. I have been advocating for the use of semi-static content for a while. The first time I toyed with this idea and even used it to some extent was back in 1999 at an online retailer that we both know well! It is merely a form of long-standing cache.

Synchronization can still cause issues, and the fact that we are introducing another layer of indirection. We also have to realize that 'some' content needs to remain dynamic. For instance, we allow our clients to specify some sidebar ads targeting different pages (ie: the ski pass discount ad goes on the recreation/activity pages, and the bed and breakfast ad goes on the vacation planner page). This can be handled in a couple of different ways... Donut caching/partial page caching using a longer duration cached or static component and server side logic (yuck) or javascript (yes we use it quite a bit with the concept of a 'base page' that is rendered immediately without javascript with all the trimmings filled in later).

We sort of talked about the problems we have building CMS-backed sites that these approaches can solve a while back. Our custom 'mid tier' runs on Lucene and is a very fast cache, but not completely static.

Have you experimented with static content very much?

Submitted by Mark Figart on Mon, 01/20/2014 - 8:41am

Brice, you're right, I remember now talking about the stuff you had been working on, and this necessitates further conversation! No, I really haven't toyed with static approaches much, and erected a new blog recently (http://figart.github.io) to play with one of the more common approaches, Jekyll. Let's talk soon!

Submitted by Mathieu Bolla on Wed, 04/30/2014 - 9:48am

Hi,

I definitely thinks that is the solution.

But here is my story about it:

I've worked for months building a solution that is able to host static websites easily, safely, and that is real fast.

But, when I first tried to sell it to web agencies, the answer was "That sounds good, but how the hell do I explain my clients they have no online admin interface?"

I then added a simple, made-in-one-day feature: The solution may now take files from the storage, or delegate to a URL. You can then benefit from all my pretty speed optimization tools (cache headers, caches, image profile striper, auto gzip...) And you can back your static website with a CMS, just playing some DNS tricks.

And it rocked. Apart one thing: CMS usually tend to use absolute URLs with hostname, and the likes, wherever they want. Time for a search-and-replace tool.

Now, I think I've come to a nice solution. But it has now grown with complexity, from what seemed a super simple fast-cloud-content-hosting-solution.

What do you think about my way to this cruel end? Would you like to try it and give me some feedback? Here it is: http://www.staticms.com (sorry, most of the content is in French, but I'm translating as fast as I can... First error was maybe to target French web agencies...)

Mathieu, founder of StatiCMS.com

PS: Here is a blog post of mine (in French, again...) on how you may use my solution to hide a wordpress install behind my solution to be "20h proof" (able to withstand nation wide TV news coverage... with your URL center, bold)
PPS: Sorry for below average English, I'm no native speaker

Submitted by Mark Figart on Wed, 04/30/2014 - 9:58am

@Mathieu, pas de problème. Je vais jeter un oeil at ta solution. Merci d'avoir visité notre website!

Submitted by Mathieu Bolla on Wed, 04/30/2014 - 10:09am

You've got my email, should you need some demo account for testing purposes...

Submitted by nick on Sun, 08/24/2014 - 8:56am

Would just like to add that many Information Security companies are now doing this (mine included). Some have even completely ditched the hybrid model opting for a full static build. Downside is you need a developer that is familiar with managing various Dev/Stage/Prod environments with CLI experience.

Submitted by Amy Peveto on Mon, 08/25/2014 - 8:52am

There's always a down side, right?

Scripts of a Drupal Newbie – A Love Letter to Views

Oliver Yin — Wed, 25 Sep 2013 13:50:31 +0000

Scripts of a Drupal Newbie – A Love Letter to Views

Oliver Yin Wed, 09/25/2013 - 8:50am

Drupal is definitely not something you can master or even comprehend in a few weeks, or even a few months. All the little details start to take their toll after a while. But my personal savior and motivator as a Drupal newbie came in an immensely useful package that most Drupal developers might recognize.

An eloquent comparison for Views

Most people enjoy using the television, or at least enjoy watching the entertaining shows that pop up every now and again. Yet, turning on the television nowadays requires having to fiddle with unresponsive touch glass that decides to work if your fingers are just dry enough, or pushing a button behind the television in that indentation in the wall…

…or, you could just use the television remote and save yourself all that hassle.

What are Views…

That ineloquent metaphor for my discovery of the Views module describes how I felt when I realized that instead of fighting against Drupal to get custom functionality through a series of SQL queries and a useful interface, I could create structures and formats similar to those that I planned out in HTML/PHP. To say the least, Views rekindled a lot of my lost interest in using Drupal through the sheer possibilities and power that Views provides (to the point where it is included in Drupal 8 core!).

… and why I like Views

The Views module is essentially a customizable data presentation layer on top of Drupal that allows for flexible presentation of content in a lot of ways that would require individual modules, hacks, or additional code to maintain otherwise.

When I first started using Views, I thought it was just an entertaining and useful way to make data appear the way I wanted it to. But I soon found myself examining all the different presentation types that Views can generate, ranging from simple article presenters to interactive slideshows. To say the least, I’m somewhat intimidated by the scope of what Views is capable of. But in all honesty, what in Drupal isn’t very intimidating at first glance?

Oh well. It’s going to be my pleasure learning how this wonderful interface works. Needless to say, I’m more than happy to continue pursuing Drupal. Especially if little joys like this are in store for me.

Drupal

Which Base Theme We Use (and Why)

Why I don't use the other approaches any longer

Why I use Bootstrap

Drupal-specific modules used to help create a Drupal Bootstrap site

What do you think?

LEAVE A COMMENT

4 Challenges With a Webforms Project, Part IV

Challenge #4: Thank you, come again!

Customize that confirmation

Closing things up

LEAVE A COMMENT

Product Review: New Relic APM for Drupal Performance Tuning

How to get it

LEAVE A COMMENT

4 Challenges with a Webform Project, Part I

Challenge #1: Hide the form

LEAVE A COMMENT

A module I've been wanting for a long time — insert a block in WYSIWYG

Suddenly, the obvious choice

How it works

LEAVE A COMMENT

Varnish, Memcache — Cache All the Things BUT Still Run Dynamic Code

What if you want something unique?

Here are two quick options:

Move the dynamic content from PHP to JS

Use the Ajax Blocks Drupal module

LEAVE A COMMENT

Crawling vs. Indexing: Robots.txt and sitemap.xml

For example

Crawling vs. indexing

One step further

Development environments

LEAVE A COMMENT

Why I Love Pantheon for Drupal Hosting

Time-savers

Dev -> Test -> Live

Git version control

Status checks

Backups

Drawbacks

Conclusion

LEAVE A COMMENT

Pairing Static Websites with CMS

Static files

The downside of static

Content management systems

The downside of the CMS

A match made in Internet heaven

To conclude

LEAVE A COMMENT

Scripts of a Drupal Newbie – A Love Letter to Views

An eloquent comparison for Views

What are Views…

… and why I like Views

Related Links

LEAVE A COMMENT