Jun 28 2012
Jun 28

It’s official. After months of development, ELMS has been labeled Beta. The major blockers to beta included user management, information architecture stabilization, a solid foundation of features out of the box, a bullet proof installation, and (most importantly) full distribution packaging on drupal.org. All of these are now included in addition to a lot of bug testing and questions from the community that have been rolled in. Videos have been reshot for the entire project's tutorial site on youtube too! Watch the ELMS tutorial channel now!

Why is this important? Because for the first time, ELMS will be packaged nightly by drupal.org. As patches and issues are addressed in the queue you’ll be able to download and see the changes the next day! This will add a new level of transparency to a project already being developed out in the open.

With the ushering in of ELMS Beta I can also announce a few other things that have been going on the last few months:

  • All ELMS related modules available in contrib. on drupal.org are almost all beta or full stable releases.
  • Most ELMS related modules available in contrib. have a drupal 7 branch if not published version
  • ELMS has a Drupal 7 branch for the community to help push the upgrade forward, now made more possible because of the standardization in information architecture
  • ELMS Collaborative learning environment is now a functional alternate install routine for the ELMS distribution
  • ELMS Media is now available for download on drupal.org. It’s still early in open development but is worth checking out how we handle asset management in our courses
Jan 03 2012
Jan 03

Tips for Acquia Hosting Development

Posted on: Tuesday, January 3rd 2012 by Brandon Tate

Here at Appnovation, we frequently use the Acquia hosting platform for our clients. The Dev Cloud and Managed Cloud are impressive platforms that fit well for many Drupal sites being built today. I’ve listed some items below that have helped with the overall build quality and ease of use for these platforms.

Utilities - Drush aliases

Anyone who develops with Drupal should know about Drush by now. Acquia has gone ahead and installed Drush and the Drush aliases on your Acquia Hosting account automatically. For example, you can run the command “drush @sitename.stg cc all” from your local computer to clear all the caches within the Drupal site without having to log into the server for it to work! You can find the aliases under Sites > Managed (or Dev) Cloud > Utilities. After downloading the file to your $HOME/.drush/ directory and setting up an SSH key, you're good to go.

Enabling Git

Acquia uses SVN as its primary repository system. However, some of us like to use Git for its enhanced speed over SVN. Not a problem since Acquia supports both. Switching to Git is easy and can be found under Sites > Dev Cloud > Workflow. At the top of the page you’ll find an SVN URL by default with a gear icon located next to it. If you click that icon a drop down will appear and the option to switch to Git will be displayed. Simply click this link and your repository will switch from SVN to Git. For Managed Cloud platforms, you just have to request Git by filing a support ticket through Acquia and they will switch it for you.

Pressflow

Acquia Dev Cloud and Managed Cloud implement Varnish to speed things up. To take advantage of this I recommend you use Pressflow. The installation and setup is the exact same as Drupal and Pressflow is 100% compatible with Drupal core modules. There are some issues with contrib modules, so make sure you check the functionality of these modules before assuming they work. Once Pressflow is installed and setup on the Acquia server, you’ll notice you have a new option under Performance called “external”. This allows Varnish to handle caching instead of Drupal’s stock functionality.

Mobile sites and Varnish

I recently worked on a site that was using Varnish to speed up the performance. The site was also configured to use a different theme when a mobile device was detected. I was using the global variable $custom_theme to switch the theme when a mobile device was found. However, when this solution was implemented with Varnish we noticed that sometimes the mobile site would get served to a desktop browser and vice versa. The problem was that Varnish was caching the page and not hitting the code to determine if the device was mobile or not. To correct this, we needed to switch from using the global $custom_theme variable to using Drupal’s multi-site folder architecture. To do this, you need to add a mobile site folder (m.domainname.com) to the sites directory within Drupal. Then within the settings.php file add the following line.

$conf = array('theme_default' => 'mobile_theme');

This will force the site to use the mobile theme. Next, you’ll have to add the domain to the Acquia Hosting platform which is located under Sites > Managed (or Dev Cloud) > Domains. After that, you’ll have to get in contact with Acquia support so that they can configure Varnish to detect mobile devices and redirect to the correct sites folder.

Memcache setup

Memcache is another technology that speeds up the performance of Drupal. To enable this, you must download the Memcache module from Drupal.org. After this, you can add the following lines into your settings.php file.

if (!empty($conf['acquia_hosting_site_info']) && !empty($conf['memcache_servers'])) {
  $conf['cache_inc'] = './sites/all/modules/contrib/memcache/memcache.inc';
  $conf['memcache_key_prefix'] = 'domainname';
  $conf['memcache_bins'] = array(
    'cache' => 'default',
  );
}

First, I’d like to point out the memcache_key_prefix which must be unique across the different environments such as development to production. This prevents the cache tables from overwriting each other. Next, the memcache_bins key allows you to cache specific cache tables from Drupal. In the example above, I’ve left it to "default" but you could cache specific tables such as views, blocks etc.

Workflow - Lock out the files folder

Acquia has a drag and drop interface that allows the developer to drag the codebase, files and database between development, staging and production environments. This allows you to easily migrate your site between any of the servers. One thing I want to point out is, once your site is on the production server, its a good idea to lock the environment by setting it to Production Mode. This prevents the files directory and database from being overwritten and also allows you to pre-release the site to the client, allowing them to add content while you update the code base. To do this, go to Sites > Managed (or Dev) Cloud > Workflow. There will be a “Prod” section with a gear beside it, clicking that gear will provide a link to switch the site to Production Mode. This can be easily reverted as well by clicking the gear and reverting the site to Pre-Launch mode.

Those are some tips that I’ve discovered over my use of Acquia that have eased the development and deployment of a Drupal site on their hosting platforms. If you have any questions or tips of your own, feel free to comment.

Nov 01 2011
Nov 01

It's a silly title but the ELMS Distribution Alpha 5 has been released! I'm very happy with where things are heading with ELMS now that I've transitioned the platform completely to a Spaces / OG / Features / Context / Views / CCK based platform. There have been 11 features created as part of ELMS Alpha 5 and I've posted 24 module releases to drupal.psu.edu or drupal.org in the last 24 hours. It's been a wild ride but the reason that I say this is atrium's little brother is that it's essentially the same backbone as Atrium (Spaces, OG, PURL, Features) but flavored for education.

Much of the code that has been written for ELMS will work in Open Atrium or any other Spaces based platform. For example: projects like Workflow PURL integration, Feeds RID Map, Feeds Node Helper, Spaces OG Clone, Spaces Theme, and the Regions API should all work outside of ELMS. Most of the projects released as part of this build are applicable to any Drupal site! Regions and the 3 implemented regions in ELMS should deploy against any Drupal site.

It has been my philosophy to make ELMS a user of Drupal modules, not a builder of custom code. This has lead to a very small amount of code and features being written specific for the ELMS platform itself. I hope more people can benefit from the development of ELMS as a result of this development philosophy. This also can provide greater code security as more pieces will be audited outside of the EDU context. This was an absolute must in my mind because a large reason I didn't develop for Moodle was the quality of the Drupal core product and community around it.

With all that said, I hope you enjoy the modules that have been released and any feedback on the distribution is most welcome. Make sure you read the README.txt file before reporting issues as you need to make sure error reporting is not printed to the screen on install (again, this is still alpha). This should be the last release marked alpha as we'll be running something similar to this for the Spring semester (after User experience testing). Here's the tutorial series recorded for the elms.psu.edu website about ELMS


Aug 29 2011
Aug 29

Background

I have been reading through the various blog posts and issues discussing the need for a community consensus around a plan for Drupal as both a platform/kernel/framework and product(s), and how we get from here to there. Despite indication from some that this is may be an edgy or controversial topic, it feels to me like there is already pretty good consensus around big parts of the discussion. To (hopefully) demonstrate this, I thought I would try and sum up the discussion thus far in terms of “Vision, Strategy, Implementation”, also known as a “VSI”. This is a very straightforward but effective strategy framework we use at CivicActions, both internally and with clients. 

Rather than describe the history and purpose of this discussion, I am just going to point at Jeff Eaton’s excellent Drupalcon London presentation, and  the video if you haven’t already.

Note that I am skipping lightly over the semantics around platform/kernel/framework/etc here. Also that this is just my personal impression of the conversations (with input from a couple of other folk), and there have been lots of "offline" conversations at Drupalcon and IRC - if you have interesting details or ideas I have missed please add them in the comments or the appropriate drupal.org thread!

Vision

We have done it! What does it look like?

At the highest level, the vision is that people just starting out with Drupal are able to effectively kick start their site with products that really support their use cases, that experienced site and distribution builders have solid and sophisticated functionality available, and that Drupal core development is more effective by focusing effort on the platform system/API and a small set of truly core features driven by the needs of contrib, site and distribution builders.

New users and evaluators are driven towards a wide selection of complete distributions, install profiles or feature “bundles”, that solve common use cases out-of-the-box, and would come complete with sample content, tutorials etc. One of these is a Standard/Starter distribution very similar to the current Drupal core (including generic and basic community features), and/or some common use case that showcases Drupal.

There is a clearly defined Drupal platform/kernel/framework with the core systems and APIs, as well as a set of basic but high-quality features that are essential for the vast majority of sites, that support product development and strategic areas such as user/content management and usability. All modules are relevant, optional and have minimal interdependencies.

Strategy

What things could we do to get there?

  1. Do nothing - core stays as it is. This option doesn’t serve the needs of new users (not a friendly, use-case demonstrating entry point), it doesn’t serve the needs of site builders (core comes with cruft they don’t need, and misses things they do need), it doesn’t serve the needs of core developers (the raft of overly dependent product features increases the workload of people who are better focused on the platform, and doesn’t encourage others to contribute to the product features).
  2. Encourage creation of more and higher quality distributions and products that are focused on specific use-cases. Part of this is improving core to make it as easy as possible to build and maintain this type of project (for example  supports this). More generally we need to discover, demonstrate and promote best practices, ensuring the resulting products have excellent user experience and learnability. The  is a key part of this - in addition to helping define best practice, it can provide concrete feedback to the platform to better enable other distributions to reach the same goal. There seems to be a high level of consensus around this, and it is an area that can be worked on whilst other discussions proceed.
  3. Start defining and uncoupling the platform/kernel/framework (to be), making core modules optional, removing interdependencies, cleaning up APIs. I think there is good consensus around this, and it is clearly something that can be worked on right away. See  for details and the  tag for issue links.
  4. Move modules/themes that don’t qualify to stay in the platform to contrib (or possibly “golden contrib”). Note that even if they are moved to contrib, they could still potentially be used in “official” distributions/install profiles - referenced and pulled in by the packaging scripts - such that users could transparently download the exact same set of modules they did with D7 (if that is what they wanted).
    A key here is defining what the heuristic is for determining this - for example Jeff Eaton
    :
    “1) Does the module provide 'Product features' for people who want to blog/discuss/etc (as opposed to 'platform features' for people who want to construct a custom CMS?)
    2) Do the most active core developers feel that it is essentially a "waste of energy" to maintain in core?
    3) Can equivalent functionality be implemented using other tools available in Drupal core?
    4) Can equivalent functionality be implemented using popular and well-established contrib modules?
    5) Is the module's functionality 'uncoupled' from the essential parts of the Drupal platform? (aka, 'We can't dump System module')
    6) Has the module's feature set stayed relatively static over its time in core?”
    Several people (including ) have pitched in with specific lists - there is general consensus about a few modules but less about others. Either way, it seems like when consensus has been reached on a module it can simply be moved to contrib without too much delay, especially if they are to be pulled right back into an install profile - the meta discussion and links to issues for specific modules is at 1255674 as well as the .
  5. Decide what should be in the platform. This is a more subtle and complex question than the previous, because discussion here should really be in terms of features (and if/how they support the majority of contrib, site and distribution builders) rather than in terms of just this or that module. The work will likely take time to complete because it may involve splitting modules (some in contrib, some in core), improving them or even moving new functionality or contrib into this distribution (and making sure it is up to scratch). Several people have attempted to define what the standard should be for this (including myself above), or for example Larry Garfield (Crell) :
    "Drupal core contains functionality that meets one or more of the following criteria:
    1) platform functionality that is used to build application-level functionality that cannot be easily replicated in contrib.
    2) Application-level functionality that is difficult or impossible to implement in contrib.
    3) Application-level functionality that supports a pleasant initial experience with Drupal for new users, and encourages them to further explore Drupal's offerings including contributed extensions."
    or catch :
    “1. Essential for anything else to work (database layer, cache system, sessions, locking, queue, string sanitization, logging, other things that mainly live in /includes). These generally have some kind of corollary in PHP platforms although they are not organized as such in core.
    2. Essential to call Drupal something beyond a strict platform - the entity API and field system are good examples, also token, contextual links. These are the APIs that site building tools are built from, and can also be used directly by developers. Do not provide either user or admin-facing features by themselves, may provide scaffolding like UI elements (vertical tabs or similar, or the token browser).
    3. Essential to allow site builders to do stuff: Default themes, default /admin provided by system module, Field UI.
    4. Essential for having 'a website' - specific entity types like nodes, users or taxonomy, certain field types like text, image, organisation tools like blocks and menu modules. At this point it includes things that site visitors can see (like node/comment forms and listings).
    5. Essential to serve particular kinds of site or use cases (poll, tracker, forum, profile).”
    This seems likely to be an ongoing discussion - some things are quite clear, others are less so, and others will likely only be discovered as we get a wider depth of distribution products (such as Snowman/onramp).
  6. Determine where “official” products/distributions (including Starter/Standard, and possibly Snowman/onramp) should live - as install profiles “inside” the core platform, or as separate projects/downloads (leaving the platform as a “minimal-only” install), or one of various other options. This seems like potentially the most controversial question and hasn’t been discussed much in depth, but it clearly doesn’t need to block any of the other work and it’s easy enough to move things around with git retroactively if we change our mind after trying one approach. A thread figuring out discussion items/process for this and other more complex questions is at 1262752.
  7. Determine the user presentation - what do we show users in order to ensure that new users and evaluators end up with the most appropriate user experience for their needs. Discussion and some nice mockups are at  - there seems to be some agreement around this, however it is further down the road and doesn’t block any of the other work.

Implementation

How will we do it?

I have posted links to issues for most of the strategies listed above, where I would encourage folks to participate there. There are lots and lots of details to figure out here (and no consensus yet on plenty of them!), pros and cons to balance, and plenty of patches to fix up too (of course!). With VSI, a great approach (for major projects) is to break down each implementation step into it’s own mini-VSI. It is also worth considering though what can be done now (no point in-depth planning stuff you can’t even start yet).

Jul 26 2011
Jul 26

This tutorial walks through how I was able to make the top branding bar in ELMS "follow you" as you go through the site.  The modules used in this video primarily are Appbar, Context, Menu Block, Menu Icons, and Menu Token.  There is also some custom code in the elms_spaces module which extends Menu Token's default functionality but this should help you build out your own consistent region in your projects.  As always, feedback is much appreciated!

Editorial note: I call a project "Menu Translate" in the first part, what I mean to say is Menu Token.

Jul 19 2011
Jul 19

For a presentation our graphic designer recently created some Druplicons for different colleges at the university. I'm posting these here so others can download and use them if they like.  They are very simple but could provide a nice way of showcasing the fact that your college or university is participating in Drupal.

Images created by Michael Palmer based on the original Druplicon. As these were created for the ELMS initiative these are all GPL.

Nov 04 2010
Nov 04

Killer platforms need killer apps. A great platform by itself isn't that interesting or useful. It takes killer apps to attract customers and define the platform.

Since the computer industry hit its stride we've seen a number of examples of killer platforms and killer app duos. 1000s of financial workers bought the Apple II platform on the the strength of VisiCalc and Lotus 1-2-3. Once Facebook opened up their platform, 1000s of applications and services were written, most worthless, but social gaming company Zyanga has made 100s of millions of dollars from games like Farmville and Mafia Wars. Apple's App Store has introduced millions to the "app lifestyle" through its various iOS devices.

In the world of the Drupal platform, many people think Drupal distros are becoming the "killer apps" of Drupal. They (and I) believe that these distros / applications will help Drupal attract new customers in new markets. Popular distros, such as Open Atrium and OpenPublish, are starting to show that this model can work as they and other distros are receiving attention far outside the normal channels and communities which discuss Drupal.

For the past year or so, I've been working on building a Drupal distro called Eduglu, which is a social learning product designed to support groups of learners. Similar to Drupal, my company's product Eduglu is a platform. As part of developing the platform I've built a number of apps for it such as a forum/mailinglist, polls, etc.

But while these are nice apps and I'm really pleased about how the platform is coming together, I feel that Eduglu is still missing its set of killer apps.

Many people look at Eduglu now and think "meh", "what does it do", they ask, "that existing education / community platforms don't already do?"

And... I can't really answer that question. Not yet anyways. Eduglu is still missing its killer app that for 1000s of organizations will become the reason that they must adapt Eduglu as their learning platform. Something like email that for millions of companies and households was the "reason" they signed up for Internet.

So recently, I've made a prediction to myself, that Eduglu will become a success only if a large number of apps are built on top of the platform.

But luckily, I don't have to rely entirely on people building apps specifically for Eduglu. In Dries Buytaert's (founder of Drupal) first post on Drupal distributions four years ago, he said that for Drupal distributions to succeed, they must collaborate not compete. That Drupal distros can't fork Drupal core or otherwise introduce incompatibilities between themselves.

And happily, that is what has happened. Through the efforts of many in the Drupal community, particularly Development Seed, it is possible to take an application written for one Drupal distro and reuse it across multiple other distros. And one very interesting effort, Debut, is working to build a common set of applications specifically designed to serve as base applications for a variety of Drupal distrubutions.

So this has left me, Eduglu, and other Drupal distros in a nice spot. Many people are working together to build reusable apps and Drupal, particularly with the upcoming Drupal 7 release, has developed into a very nice framework for building web applications.

So I have two items now on my roadmap for Eduglu.

  1. Refine and evangelize the platform and
  2. Develop killer apps.

And while predicting in advance what is or isn't a "killer app" is difficult, I have a few ideas up my sleeve. First on the list is a realtime notetaking app built with Drupal and Etherpad. Students will be able to take notes together, attach audio recordings of the lecture and other media files, and save all of this to the class website where it'll it can be referred to in the future.

And if you already know what you're killer app for learning is and just need someone to build it then by all means, please contact us! We'd be happy to help :)

Nov 03 2010
Nov 03

This is a series of screencasts about how to use the ELIMedia system.  While it is currently a closed system for internal use by the e-Learning Institute, I figured I'd post the tutorials here so you could see some possibilities of Drupal.  This is a Drupal 6.x site with a Flash Media Interactive Server on the back-end, heavy use of Views and JWPlayer Module, and a snazzy theme.  There are two helper modules to connect systems together as well as stream-line different asset types.

Currently, there are tutorials for navigating the site and how to embed flash in a course.  The trackback system is also discussed.  Many, MANY more of these videos will be posted tomorrow and over the next few days.  The Flash tutorial also showcases smart-builder (I accidently call it smart-sheet which is a different product) integration.  After that is a lesson on the importance of using image treatments.  It's a 3 part tutorial on how to use image treatments to replace the need for redundant HTML creation and making images more reusable in courses.  There are also tutorials on uploading video, audio, images and adding youtube videos to the system.

If you have any questions about how different things are done please ask!  I hope this gives you some ideas for asset management in Drupal.

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