Drupal « OSU Developer

When the Hackathon rolled around our team wanted to bring a project that extended or utilized our current CMS for a new purpose. We wanted something that we could start and finish in a single day and we also wanted a project that would take advantage of a team with diverse skill sets.

Enter bennyslist “a classified advertisements website exclusive to the Oregon State community with sections devoted to buying and selling textbooks, electronics, bikes and just about anything students need. Students can create and respond to listings through the site, making it a safe, secure place to buy and sell.” taken directly from our about page.

Screen Shot 2016-05-18 at 2.15.46 PM

Bennyslist is a group within the main.oregonstate.edu drupal site. We decided to use our CMS because it allows us to tie into existing university themes and branding but it also gives us quick access to some powerful components.

CAS Authentication

Really at the core of the concept is that bennyslist is private to the OSU community. Craigslist fails because of the constant bombardment of spam and phishing attempts. Just try to sell anything and you will see for yourself, it can be an aggravating experience. Because OSU Drupal already has an authentication tool built into it we were easily able to specify which components would be “gated” via ONID login.

If you want to see what is available or want to post something for sale yourself then you will be required to use your OSU issued account. This was also nice because it did not add yet another account credential to store, memorize or update.

Webform

The second component that we used was Drupal Webforms. Our audience can go to the form and fill out what they have for sale and once submitted those entries are dynamically display in our listings. This allows them to come back and edit the posts and also means that it is fully automated. No staff time is required in moving submissions onto the for sale/trade list. However, it also provides a way for administrators to remove postings that are deemed unacceptable.

Screen Shot 2016-05-18 at 2.32.10 PM

Because of these components it was an easy decision to go with a centrally hosted CMS as opposed to trying to create our own home grown application. There are certainly some compromises to make, but in the end we were able to create a fully automated and functional tool.

The rest of the work went into marketing and communications. We had designers create attractive images, a writer help with copywriting and a video producer even had time to create a commercial for the tool. Taking a fully integrated approach to our product allowed us to deliver a completed product in the time allowed.

So go ahead and give it a try, think about how you use Drupal and OSU templates. They do have some limitations but that doesn’t mean you can’t explore different functionality and strategy for your sites.

The Team

Callie Newton – Web Editor and Writer
Oliver Day – Interactive Designer
Santiago Uceda – Assistant Director (Illustrator for this project)
Darryl Lai – Multimedia Producer
Kegan Sims – Drupal Architect

Varnish is a robust caching web service used by many high profile and high traffic websites. Acquia uses Varnish to help end users retrieve web sites faster and to help keep the load down on your servers. Once a page is in the cache performance will be fast, but what if you need to make a quick content adjustment? Now that the cached content is no longer up to date and needs to be cleaned, how can you keep your cache fresh?

What we did for our Drupal site is setup Cache Expiration with Purge modules to connect to our Varnish nodes and keep all our pages up to date. Most module like Varnish and Purge will integrate some page cleaning, but these modules don’t work for cleaning Views or Panels caches. What Cache Expiration offers is a more configurable options to act on and utilize the Workflow module to update our Views. With this extra control we were more comfortable to extend our Caching time beyond what Drupal allows to you select from the pull down to 7 days. With a quick config line change in sites.php we can setup the cache time

$conf['page_cache_maximum_age'] = 84600*7;

Now that we have our pages setting the cache header to 7 days, we need to setup one of the many different Purge options that Cache Expiration offers. After install Cache Expiration go to admin/config/system/expire and select External Expiration as we are wanting to connect to our external cache server. If you are going to use Acquia Purge or Varnish uncheck “Include Base URL in Expires”. The only sections I really needed to worry about were Node Expiration and Menu Links Expiration as we don’t use Comments and our User pages are not their Drupal user account pages. For files we use Apache to send file type headers for how long the cache server can hold onto those and all of the file uploads will append _[0-9] to the file name. For Node Expiration we set all three actions Insert, Update, Delete to trigger a page cache purge. Depending on your setup you might be fine with the basic Front Page and Node Page being purged but I wanted to do something al little different and did Custom with these two URLS

http://[site:url-brief]/node/[node:nid]
http://[node:url:brief]

The next setting that we setup was the Menu Links Expiration section. Again all actions are checked. For menu Depth, it really depends on your menu structure and what menus you have content on that will be updated more frequently, for us Main Menu with depth of 1 was all I needed.

Definition of what Menu Depth is from the maintainer:

The goal is to easily arrange for a high visibility menu to be consistent and current on all the pages the menu links to. So, if you are using a menu block with a depth of 2, you can configure this plugin to clear the URLs linked to by said menu block.

Now that we have all our nodes setup to purge when content is change as well as our menus its time to move on to our Views. The way we setup our rules to purge our Views is One rule per View, so for Feature Story we have one rule that will purge the Home page and our All Stories page.

Create a new Rule and use two events as the trigger, After Saving New content and After Updating Existing Content now with these events we filtered them by a specific content type so that way the rule will only fire for this specific pice of content, for this example I will use Feature Story as the content type. We didn’t need any conditions so that was left as None. Finally down to the part that matters, the Actions. Add a new action Clear URL(s) from the Page Cache. As soon as you select this action the page will update and present you with a text box to enter in your different URL(S) you wish to purge. To continue with the Feature Story example, our site only had one URL that needed to be purge

http://[site:url-brief]/feature-story

Save and that’s it. Any time someone updates a Feature Story on your site, the Node Page and the View’s page will now be wiped from the Cache server and the next request to those pages will now cache the newest content.

For the home page I have a special rule to purge it from the cache anytime anything is updated on the site, you might want to make modifications to this to suite your needs.

Modules:

Cache Expiration: https://www.drupal.org/project/expire

Purge: https://www.drupal.org/project/purge

Workflow: https://www.drupal.org/project/workflow

Varnish: https://www.drupal.org/project/varnish

Acquia Purge: https://www.drupal.org/project/acquia_purge