Jan 19 2016
Jan 19

DPSX-jan-2016DPSX-jan-2016 Our January meet up was in the making since the #DPSX BoF at DrupalCon Barcelona in September 2015, the sign up for the 13th Jan event was great but logistical challenges mid December left quite a few folks confused. In retrospect the meet up needs a permanent abode, if you’d like to host the next meet up please get in touch.

Despite that the turn out was good, we had 11 from a possible 29 and one late arrival found the venue doors locked! apologies Chris, have expressed much annoyance with the venue management.

We had Greater London Authority, Crawley borough council and Lambeth Council representing the public sector along with folks from the Drupal community.

The theme for the evening was ‘A Drupal Distribution for Local Councils’ though discussions as always went beyond the theme, other subjects that made for a lively discussion included Agile colocation, G-cloud for local government procurement, user lead design and next steps to making a local gov distribution happen!

Obvious place to start the conversation was GovCMS, as it turned out Andy from Lambeth had a look but did not go with it, likewise the general consensus was there is too much there for a local council and by the time you’re done stripping stuff out and adding to it you’d have forked it significantly! and of course there is the ’not invented here’ factor too. GLA tried Panopoly with one supplier only to have the next one rip it out, which turned out to be the right decision for GLA.
General reluctance towards distributions; few found them to be cumbersome and perhaps best suited for proof of concepts and demos but not the real thing. Consensus was getting to a distribution for local councils in the UK ought to start by utilising a local council’s existing platform as the base, the requirements are likely to follow the 80/20 rule – 80% common across and 20% custom, with the custom requirements most likely to be integrations with back end systems. Questions raised included which council’s platform would be the base? this would require a discovery, setting out a minimum viable product (MVP) criteria, an evaluation criteria, getting buy-in to the concept, evaluating contenders etc.. the other key aspect to consider for a local council distribution is keeping it minimal! if overloaded with features it will fall by the wayside as cumbersome.

The discussion went on to how could we make it happen? Chandeep is certain there is an initiative in the making (shall reach out to the local community to explore further) and if you happen to be involved in it please reach out to the #DPSX community here. A to do for me is to reach out to Ben Goward from Westminster, Kensington & Chelsea and Hammersmith & Fulham councils and explore their initiatives on shared digital platform and services. For the next meet up it would be invaluable to get a few more councils represented, explore if there is an initiative on a local gov/council specific distribution and to put in a process to capture the minimum viable product (MVP) criteria. Shall update everyone with a followup post as and when I have news either way.

For this post I will pick one more topic from our meet up to keep it brief, that being User lead design at local councils and making the most of the Government Digital Services’s (GDS) user testing lab and services. Agile co-location and G-cloud shall share in separate posts. 

Graham informed the group that GLA placed a great deal of emphasis on ensuring the solution followed user lead design principles and practises, and for that the GLA called on the Government Digital Services’s (GDS) user testing lab and services, GLA accessed the GDS testing lab and had the benefit of working with the GDS’s design team. This is a huge takeaway for all local Gov representatives reading this post, for local council product owners it would be hugely beneficial to enquire that sort of access and service costs, or reach out to the GLA to share the learnings. I’d like to point out to an earlier post on better understanding your jury (your users), and if you’d like to learn more about persona driven user journeys then you’d benefit from the following resources:

This is relevant to our conversation on distributions too, for most if not all distributions appear to me as engineering lead, whereas they ought to be user-need / problem-solution driven. If approached from the problem-solution view I have no doubt we would have leaner, more focused distributions that address vertically focused user needs which in turn would mean increased uptake, lower cost of ownership and quicker release cycles. A valuable exercise to under take would be to develop a empathy map for local councils to identify their digital behaviour as an organisation, I sense a #DPSX workshop evening in the making!

The resolution for 2016 is to hold more frequent DPSX meet ups and with that in mind I’ve set up a meetup.com group which ought to make it easier to coordinate and grow the community, you can sign up and keep track of our meet ups here. The next meet up is planned to coincide with Drupal Camp London, we’ll be holding a BoF at Drupal Camp London (4-6th March 2016) (details to be confirmed).

Lastly I’d like to thank our sponsors Acquia and FFW for their support with the venue and refreshments for the evening.

Nov 01 2012
Nov 01

Posted Nov 1, 2012 // 21 comments

A Renewed Focus

Open Atrium has long been the go-to "Intranet in a box" distribution for Drupal 6.  Obviously, Drupal 6 is nearing it's official "end of life" and something needed to be done with Open Atrium.  The question for the past year has been: "What exactly should be done?"  Should we just port the existing modules to D7?  Should we just leap-frog to Drupal 8?  What about new functionality?  What about improving existing functionality?  How do we make Open Atrium more accessible to more types of users?  How do we take advantage of new Drupal 7 components?

We have spent the past year collecting feedback and suggestions from existing and potential Open Atrium clients regarding these questions.  Since DrupalCon Munich we have developed a detailed plan for moving forward with Open Atrium in Drupal 7, have put together a new internal project team, and have finally started development!

I'll be posting more technical details about the new Drupal 7 architecture for Open Atrium 2.0 to the community.openatrium.com site soon and will also be presenting a BoF session at BADcamp 2012 this weekend.  But here are some teasers on what we've been doing and what is coming.

A New Project Team

Like most firms, Phase2 Technology makes its business doing paid client projects.  Performing Drupal module maintenance and building Drupal distributions is something we try to make as much time for as possible to help support the Drupal community.  Fitting this in-between projects works most of the time, but large projects, such as a full Drupal 7 rewrite of Open Atrium, are more difficult and require a greater commitment.  To better achieve this goal, we have put together a full internal project team for Open Atrium 2.0 (OA2) and are treating it the same as a regular client project.  We are actively seeking sponsorship for this work, but also putting a large amount of Phase2 resources into this project.   In fact, Phase2 will be matching dollar-per-dollar any external sponsorship, so please email us if you are interested in funding some of this work.  With this new project team in place, and myself as the new technical lead for the project, you will now see increased momentum behind Open Atrium 2.0.

Open Atrium 2.0 Architecture

When facing a large site migration from Drupal 6 to Drupal 7, it's usually best to use this as an opportunity for improvements to the architecture of a site.  Drupal 7 brings many new core concepts to a project, including Entities, improved node access control, etc.  For Open Atrium, a new architecture was required to take full advantage of these new concepts.

The core concepts of the Open Atrium 2 architecture are:

  • Flexible and modular feature components (Apps)
  • Flexible layout customization (Panels and Panopoly)
  • Mobile-friendly, responsive base theme (Zen or AdaptiveTheme)
  • Improved user, group, section, team permission system
  • Customizable notification and subscription system
  • Plugin API based upon Entities
  • Available as a distribution, or just a set of Modules

More than just an "Intranet in a box", Open Atrium 2 will be a Framework for integrating your existing systems into an intranet.  OA2 will come with very simple and basic "features" for collaborative discussion, file organization, events, tasks, etc.  However, in each case the "simple and basic" App can be removed and replaced by an App with a high-level of integration with existing best-in-class business systems.OA2 Architecture

New Features

Open Atrium 2 adds several new core concepts that make it even more flexible for your organization.  First, rather than seeing a set of "tabs" for each App (Discussion, Files, Calendar, etc.) a Group Owner can create custom "Section" pages and place any combination of available "widgets" on each page.  You can use the default section page layouts to recreate the OA 1.x tab pages, or you can creatively combine various elements into your own section page layouts.  For example, you can create multiple different Discussion areas within your group, or combine a view of Tasks with your Event Calendar on the same section page.

OA2 TeamsYou can also assign "Teams" to a "Section".  A "Team" is a collection of Users, similar to Members of a Group.  A Team might indicate a user's Organization, or Department, or any other collection.  Each User can be a member of multiple Teams.  When Teams are assigned to a Section, only users who are both a Member of the Group and a Member of an assigned Team can access the Section.  This allows a Group Owner to create sections within their group with different Team access, such as Private section pages.  For example, Mary might be a member of the NewWebSite Group and might be assigned to the ProjectManagers Team.  The Group Owner  could create a new section within the NewWebSite group and assign the ProjectManagers team to it.  Mary would be able to read and post content to this new section, but Bob, who is a member of the NewWebSite Group but not in ProjectManagers would not be able to view the section.

Beyond some of these new concepts within the core of OA2, the real power of OA2 comes from its modular App design.  In Open Atrium 1.x it was possible to create a new plugin Feature.  But the plugin architecture was poorly documented and difficult.  In addition, the theme used for Open Atrium made it difficult to customize for many customers.  In January, we will release the new Community Plugin Toolkit which will contain documentation and examples for creating Open Atrium 2 plugin Apps. This Toolkit should make it much easier for the community to contribute new Apps for OA2.

Moving Forward

In addition to releasing the Community Plugin Toolkit in January, the first Alpha version of Open Atrium 2 is planned for Spring 2013, with the initial Beta version to be released in time for DrupalCon Portland in May 2013.  If you are interested in helping sponsor work on Open Atrium 2, or wish to be involved early in building OA2 Plugin Apps, please contact us directly via email .  I am very excited about the future of Open Atrium 2 and look forward to delivering the Intranet product and framework that you have been dreaming about and waiting for.

Mike Potter is a Team Architect at Phase2 who loves to pair a solid technical solution with an intuitive client-focused design. Mike started his career as an experimental neutrino particle physicist before creating the first WWW home page for ...

Oct 25 2012
Oct 25

Posted Oct 25, 2012 // 2 comments

 Earlier this year at NYC Camp and DrupalDay ATX, I got to talk about my favorite subject: products and distributions in Drupal. And at the upcoming BADCamp Product Summit on November 2, I'm going to get to share ideas and learn from the top firms building products and distributions in Drupal. 

Products and distributions occupy a really interesting space in the Drupalsphere. After seeing Drupal's growth into a mature framework and platform, the natural next question is: "Where can we take this now?" Can Drupal be used to power stand-alone products? Can it be the basis of SaaS-hosted site building platforms? Are distributions best suited as tool kits for developers? Or should they be used to build "site in a box" solutions that reach a larger market of site builders? These are the questions our own product teams grapple with regularly, and that drive our work on our own distributions. 

But Drupal (and open source, generally) presents a second, perhaps even more important question. Beyond "what CAN we build?" lies the question "How do we take Drupal products to market, the Drupal way?" How do we make sure we aren't sacrificing community goodwill, collaboration and contribution, and general open sourceyness, while still deploying the business models that will sustain these "Drupal products" and their further development? 

To address the multiple decision points and questions of when, how, and sometimes, what to build when considering a distribution, OpenPublic technical lead (and dear friend) Erik Summerfield and I built a decision tree, tracking the many motivations, aspirations, and assumptions that we have seen in building distributions in Drupal. Our disclaimer to this decision model, which we gave in New York and Austin: none of this is meant to say that at Phase2, we've avoided every pitfall and done it perfectly. Quite the contrary. This is the result of early missteps, some challenging internal conversations, some hard decisions, a little well-earned community criticism, and ultimately, a lot of lessons learned. We share it not to say "we know how to do this" but to say "we're all navigating this together -- let's do it smarter."

Without further ado, here's our decision tree. (oh, and if you'd like to "zoom" through it, feel free to click through the prezi version online. 

We started with the question "why" because so often, when we talk to people about using or contributing to distributions, the first thing we hear is "oh, we're thinking about building a Drupal distribution." And our natural next question is "Why?" Distributions are expensive to build, more expensive to maintain, and can be community suicide if handled poorly or neglected in the long run. Knowing up front whether you have a good reason to build a distro -- be it to build your brand and reputation, to create new offerings or business models, or to have a "base" for future builds, is vital to what you build and how you build it.

Once you know why you're building a distribution, there are a few decisions that might help to ensure that you're preparing for your distro to be a useful, sustainable, and well-supported product in our community. Checking to be sure that your team has built sites that solve the problem you're trying to solve and that you have people on your team who know Drupal, understand what it's like to contribute to Drupal, and know how to navigate the community can save a lot of time and energy down the road. 

Finally, thinking ahead of time about your distribution's total cost of ownership can mean the difference between a successful experience and a distro disaster. Thinking about what it will cost to build, maintain, document, support, train, and market your distribution, and where you'll find the revenue models to support that cost, is absolutely key. 

It's not an easy set of questions -- but when we're trying to find out "where can we take Drupal now?", it's vital to ask ourselves the hard questions (and a lot of them) in order to hold our work to the highest standard. If you want to jump into these questions (and more) I hope you'll join us at the product summit next week. We're excited to join the discussion among awesome, product-minded companies like Commerce Guys, Pantheon, Acquia, ThinkShout, Volacci, Gorton Studios, and Aten Design Group

As a product director with us, Karen Borchert keeps Phase2 growing each day; she focuses on the business strategy for our products, including OpenPublish and OpenPublic.

Thanks to her deep background in product strategy, Karen can ...

Sep 25 2012
Sep 25

I've known that TomRandall and the rest of the crew at Level 10 have been working on Open Enterprise for a while, and I'm excited to have a reason to give it a go. I'm in the process of numerous upgrades to BuildAModule, one of which is making the current bare-bones blog more integrated with the technical advances of the last decade.

Since it's been a while since I've spun up a Drupal-based blog, and since I know there's numerous aspects of blogging and content creation I'd like to finally wrap my mind around and implement (like RDF, HTML5, pingbacksSEO Tools), I'm thinking that the right distribution could save me time. I'm not entirely sure Open Enterprise has everything I'd like to integrate, but I know it has some good minds behind it. Or, it could turn out that I'm not the target use case for Open Enterprise and I could spin my wheels a bit, but I'm going to take the gamble so I can get familiar with a product that I know is on the edge of some awesomeness. 

So, here's an 'unboxing' of Open Enterprise. In particular, I'm using the Enterprise Blog version, which I'm thinking might be the same as Open Enterprise at it's core?

As per a typical Drupal installation, I downloaded the source, set up an empty database, added a virtual host via my MAMP Pro, and went to the new site.

The installation process gave me an Open Enterprise installation profile, and prompted me to install a set of 'apps'. I was tempted to check everything:

After all that installed, it had me fill in the default admin user and site information screen. After I submitted that, I hit a screen asking me for my FTP information. That threw me off a bit:

I tried to submit the form with nothing in it, then filled it with bogus information, thinking that maybe I could deal with it later. But neither of them let me pass. I did a quick search in the issue queue, and pulled this up which said that I could just make the sites directory writable, which I did by cd-ing into the Drupal directory via Terminal and doing a

chmod -R 777 sites

I remember running into something similar on Pantheon, I imagine for similar security reasons. But I'd sure like to have had a few more details on the screen about why this was needed.

After I did the chmod, I went ahead and refreshed the page, which seemed to push the installation process to the next step. However, not without a few errors (a lot of which just have to do with my level of reporting):

Some of these errors had to do with images, and as I started clicking on bits to look at content, I saw that there were no images and I was getting errors like:

Messing about with SEO tools

So, the first thing that I want to play with is the SEO tools to see if there was anything in there that would clearly be a benefit to my current workflow, so I go to create a piece of content and just copy over a blog entry from my personal blog.

Next, I scrolled through the vertical tabs at the bottom of the content and clicked on the Content analysis one. Everything was enabled except for the Alchemy item, which got me curious, so I followed the steps to set it up, which required the following:

  1. Downloading the PHP SDK files from here.
  2. Putting the files in the AlchemyAPI folder in the alchemy module folder (but you have to take the files out of the expanded folder)
  3. Going back to the content and trying again. This time I need an API key, so I follow the instructions
  4. I sign up for an Alchemy account, verify my email, request the API key, copy it and paste it in

Another disabled tool was the Readability section, and I didn't want to dig into that after going through the 10-minute Alchemy setup. But I did watch some of Tom's video on it  which was good (Tom has a nice screencasting voice).

Once Alchemy was set up, the check seemed to go through and I got some additional info:

After checking out the 3 tabs there, nothing appeared to be particularly useful for this article at least.

The Quick SEO tab had some good tips, mostly I think for folks just getting a feel for the amount of content to plug into a typical article:

At this point I think that maybe I should save the article, since it's showing as just having 12 words when there's definitely more, and realize that I pasted the content into a WYSIWYG. My content contains html tags, so I want to paste source in, and I don't see any source code icon (that would have been nice to have).

So I went ahead and copied my content straight from the public facing page into the WYSIWYG, which got everything including some object tags I had in there, and after that there were some better results from Alchemy:

I played around with the SEO tools for a bit, and couldn't get the keyword search to work. I noticed that you could hover over keywords like you see above to show menus for adding keywords to some kind of list, but after adding a few items I wasn't able to find where the list was. I imagine there's a bit of a learning curve here, but it seems like there's got to be some potentially good stuff in these tools.

Next, I wanted to see what the output of a typical blog post looked like, so I checked out the source code. Woah! I haven't seen that many CSS and JS files on a page before. But, I know you can turn on aggregation, so I ceased the freak out and scrolled down to where the body started:

I've been diving deeper into HTML5 over the last several weeks, and I was hoping to see some <article> and <footer> stuff with oddly named attributes, and I wasn't disappointed (though I'm curious why the footer was at the head of the article). I'm still wrapping my mind around best practices around HTML5, and I imagine that looking at this might contain some good lessons. 

In the Open Enterprise description it mentioned that it's using a flavor of Omega for a responsive theme, so I played with the browser window size a bit to see what changed, and got a re-sized logo and stacking in the navigation on the smaller window size. At an even smaller window, the sidebar drops down below the content. Cool.

When I go to check out the blog page as an anonymous user (after publishing the page), I get Access Denied. Bummer! ;)

Okay, so permissions are set up to keep anonymous users at bay. NO BLOG FOR YOU! Well, I kind of want people to read this stuff, so I went to the permissions page and made a couple minor adjustments:

And

Hey, that blog page looks pretty good! Except for a little floating issue with the comment buttons:

So at this point, I want to see how hard it would be to integrate Disqus with this blog. I first go to the modules listing page on the off-chance that it's already included. It's not, and I noticed while I was there that Drupal core and the theme is already a bit outdated:

It's tough to keep up with Drupal, man. 

I knew from talking with the Level 10 folks that they were really getting into integrating Apps, so I wanted to check out the App listing to see if I might have missed anything. In the admin bar I clicked Apps and then took a look. I didn't see anything there, so now it's time to download a module and see how well it integrates with the distro.

Okay, that took a few minutes but everything went smoothly. I now have Disqus enabled on blog posts, and normal commenting disabled.

Now I want to click around a bit. I click on the Images tab, and WHAT'S THIS? Whirlyball? And who's the psycho int he middle who clearly runs the operation?

This default placeholder content is way better than what my real content is going to be. ;)

When I click on HOME, I get a Page not found:



Bummer again! The Add URL redirect link is enticing, but when I click that it looks like it would set the redirection for any 404s, rather than just the home page:

Okay, so I'll leave that as is for now.

As my next task, I want to set up those social links at the bottom of the page to point to something functional. Icons would be nice, too, but I'm suspecting this is a standard Drupal menu and getting those icons might take a little pulling of teeth:

Indeed, there's a little cog wheel that's a bit hard to see against the blue, that points me to edit the Social menu, where I update my links.

Getting my share on

Now, I want people to be able to share posts, ala ShareThis. So, I take a gander through The Configuration menu and see a Social media item, which I click on. As I scroll down, it looks promising:

Okay, but how do I get these to show on my blog posts? As I'm looking around, I run into this, which looks a little off:

I'm also getting some overlay screens where there's no way exit because (I'm guessing) the close button is under the admin toolbar:

Then I browse to the modules page and see that maybe the social module I'm seeing isn't fully functional yet:

I check out the Help page and it mentions something about one's profile, so I think that maybe I have to associate the social media accounts with my user, rather than the site, but when I go to my user account page, I just get a submit button:

So I scroll down the modules listings page, just to see what's in there. And what's this?

This looks promising. So here's what I do:

  1. Enable the Widgets module
  2. Check my blog post to see if social icons magically appeared. They didn't.
  3. Went to the Widgets module page to see if there was any insight there. Indeed there was!
  4. Based on what I read, I went to the blocks configuration page and enabled the Widgets: socialmedia_share-default block in the Content region, above the Main page content block.
  5. I went back to the blog past, and whammo!

Okay, so I kind of like the ShareThis versions that include details about the different networks' activity (though I just found out you can up the count just by clicking on the icons), and based on the info on the Widgets module page, I probably just need to include the Service Links module for that.

Things to investigate and update

So I'm liking this so far. I have a responsive theme that doesn't look like crap, I have a lot of my needs anticipated in terms of blogging setup. I'm on Drupal 7, which feels like the future after working on Drupal 6 so much these last 6 months, and it seems like the feature modules / apps are thoughtful and goal-oriented, meaning I can probably get some nice functionality pretty cheap if I have the need for additional features later on.

At this point, there's a few things I want to check out / fix / accomplish / learn:

  1. Get the site branded.
  2. Figure out how to interlink pages with automatic Related to this article functionality for better SEO.
  3. Set up archives and a tag listing blocks or pages for better SEO (correct me if that's old school thinking).
  4. Check out how forms do on the responsive front.
  5. See if enabling the view source on the Wysiwyg is going to break a feature module
  6. Research current best practices on working with Features in a distro (I'm curious if anything has changed since I put together a video series on the subject)
  7. See if I can use Alchemy to automatically tag and enrich posts for search engines, ala the AlchemySEO service / product. And also, is that kosher?
  8. See why I can't get keyword searches to work. Is there some API key I need?
  9. Check out RSS feeds. And is there any integration with PubSubHubUb, and do I really need to care about that?
  10. What about trackbacks and pingbacks? Do people use those? Any reason they weren't included in the distro?
  11. Play with OpenGraph MetaTags to see how it impacts mentions in Facebook
  12. I'm curious what the UUID module means for nodes. Can I use them in feature modules now (the last time I tested that it was buggy)? Is that what it's intended use is in Open Enterprise?
  13. Integrate a menu-search tool like Coffee, or maybe finally check out the Drupal 7 port that Amit Goyal made of Navigate.
  14. Do some Adobe Shadow (or Edge Inspect as it was newly released today) to check out how this Omega theme looks on a few different devices. And make sure images are 100% max-width (they get cut off as the screen gets smaller).

Thanks!

Thanks to the Level 10 folks for putting this distribution together. I know it's super hard to build features that work for lots of use cases, but it seems like they're doing a really good job so far. I'm looking forward to seeing how fast I can get this to production. :)

Apps Images enterprise I ma e 5. Is ani app for m ? h'1 Images content and displaying image ApPS are the next generation In usability for Drupal They contain bund les of galleries tuncncnatnv for your bS'lte. Select any apps you want to install Fig hr new You a add rmln? jailer rim line I'll pm page i Link Mil.11.l1gr!'; rmf ns- &quot;,uluru' link. It can be used to keep short I ? gf valuable resources In odder lay Inman apps. you Muni be able Il I FTP er SSH in! C tour server This uses v. r, nr the basis for fiJi blqw;!1 link directory like dmo.T.org. same [process as the update module. locations rr-r APPS TO ? ALL Enables r&quot;r'hl:rl.l4.e me n L od locations as content address are automatically go eneere map displays you Cari 'i?iY groups or locations on Of as listing april rotating balder j blog rotating banner of sudes with links Vern ()ll·illmC'1 on the homE page multiuser full featured avg app. Has many at the features .M' SEa essentials Development essential &quot;1';trrh engine cptlmI7.,tifl a features for your sea is il, more this app ands the most commonly used devel omern medulas to your site if yogi are limited set of than thaw In CFO ToXIcs. If you have Into ? SRN doing development In D r pal I this app its essential Ned robed CIO events a seo Tools provides t(lil1? for managing time bated events includes r h ? Liam Suite of advanced Seo tools including keyword reseercn and content analysis Seo Tools of includes all of the features of co essentials plus many ether tools for going Seo In fan drupal lode to bug In apps you must install 90olille_anaMlcs I'll a n a to. fore this enables creation of answers oLD frequently asked questions using a standard Iraq form, app will install o Forum DNAa! May, community discussion boards with topics and threeued comments help GNU socialize tour Swe. images I'd videos enterprise images is il 11 App for noIr aging images cnntr-n and displaying image provides video content management [naMes playing 0.11 uploaded Dr timbered videos galleries l' them Y,iliU T,u Un ? di WebfOrm Manages online resource links it ean be used tO keep short list or Ell valuable resource eneerea you to add web terms to your Site that can be lemalled and/or saved to a uenaase includes contact us example form but allows you to build any number of cUStom forms DiE:FAULT content ? In Stal default content B, ?r?jr.tli ng this box default confirm will me ,imt;tilDll;ld fgr each app without default content the site may look empty before yOU start addl fl to It. YOU can remove the .iI'efw! l content later by going to line apps caring page install apps SkIp this step Home Update downloaded successfully. WARNING You are not uSing an encrypted connection wyour password Will rnccse profile be sent in plain text, team mere cnccse language TO continue provide your server connection details Verify requirements Connection method se up database 'FTP install profile FTP connection settings Configure site username install apps Finished Password your password not sated In the database and only used to establish cc-reecucn ADVANCED SETTINGS Continue Alchemy has been installed Content Analysis has been installed Content Optimizer has been installed Keyword research has been installed Kilvword research google has been installed wcrestream has been Installed AppS enabled successfully Imponed node 43. Contact uS of i nodes oJt imported Some values may have been reset depending on Node experts configuration Choose profile Choose language Verify requirements Set up database rnstan profile Notes. Undefined vanabte replacements in quid token (line ? 9Sof of jChrlsjWebsilesjloc.b1og bullddmodule.comfslteS/dlljmodules/uuld/uulo taken NotiCe Undefined variable replacements in uuid_tokensO (line 9501 of jChf;sjWebsit?sjlo' blog. bui!d.Jmodul?.com/ sites J/f/rmxlule l/uuid lIuid.1 ket Notice Undefined variable replacements in lJuid_tok.?n'JO (line ? 95 of of IChf;'JIWf'bJit?J/loc blog. build.modulO com/silf'S .t!f/modulu/ uuid/uuld take i NotIce. undefined variable replacements in uujd_tok?nfO (line 95 of /ChrISjWt'!bsilesjloc.b1og bul/d.dmodule.comfsltesfd//fmodult'!sfuu/d, Eula takei Notice Undefined vartabte replacements in uuid rokens(J {line 95 of /Chr;s/Wt'bsites/lrx.bJog,bui/ddmtJdu?.comlsitt'sldll/mtJdu!t's/uu;d/UUid,lClk Notice undefined variable replacements in uujd token (line 95 of IChf;sIWcobsit?'J/loc blog hutld..Jnmdulr com/silf's I .tll/modulu/ uuid/uuld take i notice undefined vanable o. replacements In quid token [line as of ()f /Oms/Web5ltt's/foc.blog,bu,!ddmcdu!e.com/Srles/.l/1lmcdlr!es/uwd/uwd,t(lAw Notice Undefined variable replacements in uuid_tokens(Hline 9501 of IrIdic Ill tgif hills Jri&quot;, in, ,J[ configure sue rnstan Apps Finished Notice: getimagesizeO [function.getimagesize): Read error! in image_gd_get_infoO (line 349 of IChrisIWebsitesl/oc.blog.buildttmodule.comlmoduleslsystemlimage.gd.inc). least 2 to times is recommended Consider mcreasm Content Analysis Results Analyzers Alchemy Alchemy Keywords Concepts Entities Quick SED Term Relevance Keyword research voice testimonial service 95.7% Analyzer checklist Content Analysis Results Close Window Quick SEa Analyzers ep ick Quick SEe rd: testimonial long analysis Analyzer checklist yzer page tnte Char count 95, Word count ? 14, Keyword count ? I. Keyword density 7.1, Keyword prominence ? 28.6 Your page title contains 95 characters No more than so characters to 75 characters is recommended Consider reducing the length of your page title sou Char (ounl.76, Word count. 12. Keyword ccunt-, I. Keyword density_S.l, Keyword prominence. 16.7 You body contains 12 words At least zoo to 800 words is recommended Consider Increasing the number of words. The targed keyword 'tes1imoniar occurs in the body I time At least lto times is recommended Consider Increasing the number of keyword ccecrenees in your body copy Meta keywords Char count o. Word count o. Keyword count o. Keyword density.O.O, Keyv,.(Hd promlnence-O.O You meta keywords contains o words. At least to SOwards IS recommended Consider Increasing the number of words. Content Analysis Results Analyzers Alchemy Alchemy Keywords ? Con Entities Concepts Quick SEO Term aerevaeee Keyword research can widget 99.3% Analyzer checklist Google Voice 98.90 wtb page 83.00 voice testimonial service 63.4% Google Voice page 57.1% Click Call Widgets 55.5% new call wjdge? 53. lg new greeting 44. embed code 35.1&quot; OPEN ENTERPRISE OPEN ENTERPRISE HOME Notice: Undefined variable replacements In BWIA rokensQ fine 95 of /C'm.sIWebsltesJ? tllOg.ooA'damodlJ.le.comlsimslsNimodul'esluuidIUUJd. rokens. Nance: Undefined variable: replacements in ulna tokens (line 95 of of Johns ? ? byog OlJi'd.lrn odlJ ? comlsitrJsfaY/ft'KXk.sPos/uuidfuukJ. tokens l. ACCESS DENIED You are not aumcruee to access this pa ge USER LOGIN E-mail p as s word Create now account Request now password LOGIN CA ? main content ? ay &lt;hI ClASS M title idea pa9c-title&quot; show to quickly set up an Qwcso:r &lt;dlv class: class-&quot;tabS elearfix-&gt;&lt;h2 ? class ? element-invisible&quot; Primary classeN active?&gt;&lt;a ? href ? M /blog/chris-shattuck/how-quickly-set-awesome-customized-f class-&quot; element-invisible-&gt;{active tll:b hrefa·/node/6S/edit? ? href·-/node/6S/kwresearch&quot; ? iliaci idea hret-&quot;/n In class-&quot; action-links&quot; ? hret-M/node/add/enterprise-b1og&quot;&gt;Add blog post! all &lt;11&gt;&lt;a href-&quot; /admin/contont/node/enterprise blog Administer blog ? blog &lt;luI&gt; &lt;div id-&quot;b1ock-system-main&quot; c j as a=vb block block-system&quot; c Laa s=vb block bloc title. id-&quot;block-system-main&quot;&gt; &lt;div class=&quot;content&quot; class: content clear fix &lt;article about=&quot;/blog/chris-shattuck/how-quickly-set-awesome-customized-free­ class=&quot;node node-enterprise-blog node-promoted node-published node-not-sticky sel enterprise-blo9-65 -s- &lt;footer class submitted &gt;&lt;span property: dc: date dc:cre4ted&quot; content ? 2012-0 21:36&lt;/span&gt; &lt;span ? rel=&quot;sioc:has creator pga href=&quot;/users/chris-shattuck&quot; tit! In ? t r. h r; a a hnt&quot;. eueje&quot; T. vn&quot;,n ? RI II a p. r ? n t. nrnnArt-.v= fnltf!nllmlR&quot;&gt;r..hri tsi MW modulI! module D Modules There are updates available for your version of DrupaL To ensure the proper functioning of. updates page for more information and to install your missing updates, There are security updates available for one or more of your modules or themes. To ensure the available updates page for. more Information and to install yOur missing updates. Download additional contributed mOdU'o extend Orupal's functionality. mod Regularly review and install available updates to maintain secure and current site. Always REGISTER for to post comments LOG IN Access the content overview page VIew published content View own 0i;own unpublished content ?content revisions View content IJ.'JCD Administer comments and comment settings View comments Post comments by i oj NRA PAGE NOT FOUND Add URL redirect from this page to another location URL redirects FROM http:!{loc.blog.bulldamodule.com/ navigatlon4Q4 TO. TO Advanced options Add URL redirect fro The requested page could not be Ic Unk8dln Twitter YouTube Submission form settings Title Publishing options Published Promoted to front page Display settings display author and date information Comment settings closed Threading SO comments per page Content Analysis Settings Menu settings Ml sneman Indusio excluded Scheduler settings PubU,hlng enabled Iran DEFAULT ICON style i 32)(32 ill rcee set Styles teverren 16x16 Glossy 32x32 by teverren 48x48 ? in t ? L, J S I'd a media Social media Enabled ? Name Social media Version Description I ? J Example module to demonstrate module media. beta 11 Operations Help Permissions Configure Widgets Enabled Name Widgets Version Description Operations xl. a. Enables easy management of code snipes like Twitter, Facebook and Google buttons. betaS Required by: Widgets Service links (disabled) Widgets 7. x-I. 0- Enables links from Service links module to be used as widget elements Service links betaS Requires: Widgets (disabled), Service) inks (miSSing) hello on, matter ode export Key ords kill ? ion o. CHRIS SHATTUCK View Ed. 1- Shortcuts Social profiles SUBMIT File browser Devel HOW TO QUICKLY SET UP AN AWESOME, CUSTOMIZED FREE VOICE TESTIMONIAL SERVICE a ? f, '&lt;1 Mon. 2012-09-2421 :36 Chris Shattuck Ever since heard about the VoiP Drupal I've been itching to set up some kind of service that allows people to call in and leave testimonials for BuildAMocMe. But. haven't had chance and decided today that it was time to do something about it. ran into this awesome article outlining the process of using Google Voice to set up the service, and 1; I. it I. pH

Jun 28 2012
Jun 28

Posted Jun 28, 2012 // 5 comments

Overview

In Drupal you can have base themes and sub-themes where sub-themes inherit the functionality of their base theme. Wouldn't it be cool if you could do the same thing with Drupal install profiles and make files? Imagine creating your own profile that inherited all the functionality of OpenPublic. Now you can, and this article will show you how easy it is.

Inheriting a profile

The first question you should probably ask is: "Why would I want to inherit from an existing profile?" After all, you can always just copy the profile.make, profile.profile, and profile.info files, rename them to be your own and then have your own profile. Having your own profile gives you complete control over it's contents. Inheriting from an existing profile requires some level of trust that the creators of the base distribution are including the correct versions of the modules that you need. Why give up that control?

On the flip-side, do you really want to be in charge of figuring out which patches to apply to which module versions needed with the latest Drupal update? If a distribution is using 40 modules, the effort involved in keeping everything in the distribution working well across upgrades is non-trivial. Do you really want to spend your time dealing with module upgrades all the time?

Everybody will probably have different answers to these questions. But what if you could leverage the work from existing distributions *without* giving up control over specific module versions and patches? Turns out you can.

Installation profiles

A basic Drupal installation profile looks similar to a Drupal module. You create a myprofile.info file that names the profile and lists which modules to enable: (for more detail, see "How to Write a Drupal 7 Installation Profile")

1
2
3
4
5
6
7
8
name = Profile Name
description = Description of what the profile does.
core = 7.x
dependencies[] = views
dependencies[] = views_ui
dependencies[] = node_reference
dependencies[] = features
...

Then you create a myprofile.profile file which contains anything else you need to do (similar to a *.module file for modules). When inheriting from other profiles you might need to add functions to call the parent routines. For example, if I inherited from OpenPublic, I probably want to inherit it's app server config:

1
2
3
4
5
6
7
/**
 * Implements hook_apps_servers_info.
 */
require_once ("profiles/openpublic/openpublic.profile");
function myprofile_apps_servers_info() {
  return openpublic_apps_servers_info();
}

Drush Make files

Profiles are great for just enabling modules within Drupal. But what about downloading the other modules to your site in the first place? That is where "make" files come into play. A "make" file is a list of resources (modules, themes, etc) to be downloaded to create the actual Drupal file structure. Instead of just manually downloading Drupal and the modules you need, you "run" your make file using a tool called Drush (If you haven't used Drush, go download it and learn about it as it's the most important tool you can have to manage a Drupal site). A simple myprofile.make file might look like this:

1
2
3
4
5
6
7
8
9
10
11
12
api = 2
core = 7.x
; specify which version of Drupal to download
projects[drupal][type] = core
projects[drupal][version] = 7.14
 
; now specify which modules and themes we want
projects[views][version] = 3.3
projects[references][version] = 2.0
projects[features][version] = 1.0-rc3
projects[omega][version] = 3.1  ; themes are just like modules
...

To build your initial Drupal directory structure using this make file, you simply do:

drush make myprofile.make /path/to/drupal

and drush will download the specified Drupal core files along with all specified module files. Once you have built your Drupal site, add a symbolic link to your profile:

ln -s /path/to/profile /path/to/drupal/profiles/profilename

Then when you go to your new site page in your web browser, it should run install.php and show your profile as one of the install options. Drupal will then configure the site and enable the modules specified in the profile.info file.

You can also add libraries to your make file, like this:

libraries[ckeditor][download][type] = get
libraries[ckeditor][download][url] = http://download.cksource.com/CKEditor/CKEditor/CKEditor%203.6.1/ckeditor...
libraries[ckeditor][directory_name] = ckeditor

using http GET or via git (change type to "git"). The archive will be expanded and placed in the specified sub-directory of the sites/all/libraries folder.

Specifying Versions and Patches

One of the really cool features of drush make files is the ability to specify the exact revision of a module and also apply patches to it. In the above example, we downloaded the "7.x-1.0-rc3" release of the Features module. But what if a module doesn't have an official release and we need a specific "dev" version or branch? Just add lines to your make file with the revision or branch name:

projects[features][type] = module
projects[features][download][type] = git
projects[features][download][url] = http://git.drupal.org/project/features.git
projects[features][download][revision] = a4d3fc9593a65aba335de617feccc86a2bc9947e

where the "revision" can be the name of a branch or the uuid of a specific revision (as shown above). You should never just refer to a "dev" version of a module since it might change at any time; always point your profiles to a specific version of a module.

To apply a patch to a module, add patch lines to the make file telling Drush where to find them:

projects[views][patch][] = http://drupal.org/files/Overide-Title-displays-Key-1477814-3.patch

Here we give it the exact http download path for the patch file. You should generally test to ensure your patch files will apply properly to the version of the module you are downloading before putting them into your make file.

One beauty of this method is that your profile.make file completely documents exactly which modules and versions are being used on your site, along with which patches. No longer do you need to worry that some module on your site has been modified without anybody knowing about it. Never modify the module files directly; create a patch for the issue you are having and place that patch somewhere accessible by your make file (preferably the module issue queue on drupal.org). You don't need to wait for the module maintainer to apply your patch, you can still download it and apply it yourself in your make file.

As you build your web site, it's good practice to export your various content types, views, and other configuration into Features (using the Features module) and then add those exported modules to your profile.make file. With this strategy you can rebuild all of the code for your site at any time by re-executing the drush make command. Paired with a sql dump of your database, this makes it easy to deploy your site.

Inherited Profiles

To actually inherit from an existing profile we need to change two things: 1) Tell Drupal the "base" profile name, 2) Tell Drush to execute the "base" make file. To tell Drupal the name of the base profile, add this line to your profilename.info file:

base = base-profile-name

where "base-profile-name" is the name of the profile you wish to inherit from, such as "openpublic". This should be the filename of the base profile without any extension or path.

To execute the make file of your base profile, simply add it to your profile.make file similar to referencing another module:

projects[openpublic][type] = profile
projects[openpublic][download][type] = git
projects[openpublic][download][url] = http://git.drupal.org/project/openpublic.git
projects[openpublic][download][branch] = 7.x-1.0.4

Simple, right! Just specify the "type" of "profile" instead of "module" and drush will download it and then recursively run the make file of the base profile. In fact, you can nest this as far as you want, creating sub-sub-profiles that inherited from sub-profiles that inherit from profiles.

Drupal Patch Needed

But wait, there is one final detail. While drush has recursive nesting of profiles built-in, Drupal itself still needs a small tweak. When you reference a module in Drupal, you need to tell it what order to look into the other profile directories. You want any module within your main profile directory to take precedence over any module with the same name in the base profile. This allows your profile to use a newer version of a module or apply different patches than the same module in the base distribution.

The patch needed for Drupal is here: Make install profiles inheritable. A patch for both Drupal 7 and Drupal 8 is provided and the issue is marked for back-porting to Drupal 7. The patch itself is very simple and has no effect on any site unless the "base = base-profile-name" line is found in the profile.info file. You can easily include this patch in your make file near the top where you specify the version of Drupal you are using:

projects[drupal][type] = core
projects[drupal][version] = 7.14
projects[drupal][patch][] = http://drupal.org/files/1356276-make-D7-21.patch

Any other needed core patches can be added in the same way.

Versions of Drush

If your profile installs a different version of a module that was already included in the base profile, the result will vary depending upon what version of Drush you are using. With Drush 4.5, drush will actually *remove* the old module from the base profile directory. For example, if you override the Features module in your profile, the /profiles/base-profile/modules/features directory will be deleted and only the new version of the Features module will be added to your /sites/all/modules/features directory. While this helped the old version of drush find the correct version of a module (by deleting the old version), it wasn't really the expected functionality.

This issue was "fixed" in Drush 5. In Drush 5.4, both versions of the module will be retained and drush will properly use the modules in /sites/all/modules over the version in the /profiles/modules directory. Drush will also modify the module.info file to indicate that it has been overridden, so if you look at the module info using "drush pmi modulename" you might see a version like "7.x-1.0-rc2+0-dev" where the "+0-dev" was added by drush to indicate the module is overridden. You can surpress this behavior using the --no-gitinfofile option for "drush make".

When patching modules from the base profile and using Drush 5, you will end up with two copies of the module: 1) the original module from the base make file (in profiles/base-profile-name), and 2) the newly patched module in sites/all/modules. At some later time, the base distribution might be updated to include your patch. When you remove your patch from your own make file and just use the updated distribution you'll go back to only having a single copy of the module in the profiles/base-profile-name directory. But your Drupal database will still be looking for the module in sites/modules/all. If this happens and Drupal does not automatically locate the new module, simply rebuild the Drush registry using the "drush rr" command. If your version of Drush does not have the registry-rebuild command, simply download it via "drush dl registry-rebuild".

Future Plans

Currently the patch to Drupal core only involves changing the search path for modules. In the future we could also include the base *.profile file automatically so you don't need to call it from your own profile. We could also run the install hooks for the base profile that your profile does not override. Most of this work involves deciding how we want profiles to work in Drupal 8 so that inherited profiles are part of the supported functionality.

Conclusion

As shown above, you can create your own profile that inherits from any existing Drupal profile. In your own profile you can override any module version and even add different patches to modules. You might end up with multiple copies of modules on your site, but the patch to Drupal core will ensure that the correct module version is used. In your profile.install file you can disable any modules in the base distribution that you don't want. In your profile.profile file you can call any functions in the base distribution to configure features such as app servers. You'll end up with the best of both worlds: a completely customizable profile that defers the configuration of base modules to the community. Let the community do the work of determining which modules are compatible and just focus on your project-specific profile work.

Mike Potter is a Team Architect at Phase2 who loves to pair a solid technical solution with an intuitive client-focused design. Mike started his career as an experimental neutrino particle physicist before creating the first WWW home page for ...

Mar 15 2012
Mar 15

Posted Mar 15, 2012 // 5 comments

You may not have noticed, but Drupal.org has rolled out full distribution packaging support on Install profile project pages. What this means is that now we can host complete distro downloads (including 3rd party libraries) directly on Drupal.org. No longer do we have to download Drupal core, download a Profile, download all required contrib modules and libraries (or use Drush Make like a sane individual to manage all of that). At this point you might be saying, "Big deal, so now there is an archive on Drupal.org." At first glance it might seem that way, but what we have effectively done is bring it all back to Drupal.org.

Before the upgrade, each distribution had its own product sites and workflows for building the final downloadable. There was no consistency. If you found a profile you wanted to use, you would have to go to another website to find the download and it made for a very disjointed experience. Distributions very often target folks that are NOT Drupal folks. Industry specific solutions provided by distributions draw from a bigger pool than within the Drupal community, and the experience was very confusing. Now, when you go to an Profile project page, if the owners have configured fit correctly, the link/download on the main page will contain a complete package that someone can download and install. One step. Easy peasy.

The OpenPublic and OpenPublish downloads are already being hosted directly on Drupal.org. It was super easy to make happen, check out the documentation on how to host your distribution on Drupal.org.

This came together by funding through the maintainers of some the more popular distributions, including Phase2 Technology, Acquia, NodeOne, Pantheon and Lullabot and was implemented in transparent community fashion by Derek Wright (dww), Chad Philips (hunmonk) and Michael Prashun (mikey_p) of 3281d Consulting.

In addition to providing the downloadable distribution on Drupal.org, this now sets up distro maintainers to provide a more unified support experience. Since we can now fully use Profile project pages, it also makes sense to utilize issue queues and Drupal.org git structures at all points in the process allowing distro maintainers to be better equipped to incorporate community feedback and contributions.

This first step to get distributions hosted directly on Drupal.org puts many of the pieces together to effectively manage the release and builds of these distributions, but our work is not yet done. We hope to soon support -dev releases of profiles and we also hope that the work being done here will drive a more consistent use of Drush Make in the build process allowing for a simplified build process and consistency across distributions. Currently each owner has their own magic potion for how they manage development of the distro and we hope that in ironing out the kinks of packaging and deployment we can come to some consensus on how to build for development as well. This consistency will be another benefit for those that wish to provide community contributions to the distros.

Read more about this in the community announcement on Drupal.org

Frank Febbraro is the CTO at Phase2. He is obsessed with software and integrating new techniques and practices with proven methods of execution. A combination of comprehension and real world experience enables Frank to attack challenges with a ...

Mar 05 2012
Mar 05

Looking for a website for your school or department? Meet Julio.

Features include:

  • Blogs/Announcements;
  • Slideshows;
  • Calendars;
  • Configurable home page layouts;
  • Simple install process;
  • Fully configured text editor;
  • Simple media handling;
  • Flexible menus, customizable within sections;
  • Easy modifications to selected theme options;
  • The ability to delegate editorial control over sections, and pages within those sections;
  • And more!

Credits: Music in the video from Ludvig Franzén: http://soundcloud.com/ludvigfranzen/live Used with permission from the author.

Jan 19 2012
Jan 19

Posted Jan 19, 2012 // 0 comments

Just a small but important release, security release for Date (SA-CONTRIB-2012-004), and multiple community patches!

Changes

  • Date 2.8: Security release.
  • Organic Groups 2.2: Maintenance release.
  • Data 1.0: Maintenance release.
  • Atrium Features: All atrium features have been updated to current feature code format.
  • Atrium Activity: Corrected layout for projects with long titile
  • Atrium Groups: Allow default dashboard name to be translated
  • Atrium Members: Make view members access default value consistent.

We'd like to thank members of the community who were able to identify issues and provided patches to make Open Atrium better. So thanks to AquaticDisorder, wannianchuan, tlattimore and so many others!

If you're a Open Atrium developer and would like to get more involved in the project, be sure to stop by http://community.openatrium.com

Drupal Developer Patrick Settle digs into his bag of tricks whenever he runs across a “new” challenge facing Open Atrium, which he’s been developing since its beginnings.

Thanks to 12 years in system administration ...

Jan 19 2012
Jan 19

Posted Jan 19, 2012 // 0 comments

Cliché alert: I love it when a plan comes together. 

But seriously, I do. At a couple of recent Drupal camps in Austin and New Orleans, we heard from multiple organizations using the Apps and Appserver modules for their Drupal distributions. With similar questions and needs around these new modules, we had a couple of lively "birds of a feather" sessions at the camps.

Very often, "lively" BOFs end then and there at the camps, but this one continued into the issue queues and ongoing conversations. Ultimately, it resulted in organizing a multi-organization sprint on the Apps and Appserver modules this Friday, January 20th in Austin, TX. Phase2 and our fellow Austinites at 4Kitchens will be co-hosting the sprint space, and the day's looking at a pretty full agenda.

Developers from Level Ten, Four Kitchens, Pantheon, Media Current, Volacci, and Phase2, as well as some individuals from the community, will be working to address issues marked for the sprint in the Apps and Appserver modules on drupal.org. It's not an app-production sprint -- you won't see a whole bunch of new "apps" coming out of it. Rather, you'll see the underlying structure and module of the Apps and Appserver modules improve, making it easier to build apps and use them in your distributions.

If you're interested in joining us remotely (or you're in Austin and want to bring your Apps knowledge to the table!), drop us a line and we'll add you in. And if you can't make it but want to see what we worked on, check back here next week and we'll give you the low-down. 

As a product director with us, Karen Borchert keeps Phase2 growing each day; she focuses on the business strategy for our products, including OpenPublish and OpenPublic.

Thanks to her deep background in product strategy, Karen can ...

Jan 13 2012
Jan 13

Links Corralled by Lullabots

CMI TMI? FYI.

Don't Be Evil

Kenyan Startup Mocality had a rude awakening this December, when the businesses they worked with reported confusion about the company's new joint venture with Google. The problem? There was no joint venture: a Google team was spidering Mocality's site, cold-calling businesses in its directory, and offering them a "special discount" on hosting services while pretending to be partners. Crafty analytics helped Mocality prove what was going on, and Google has apologized.

More Drupal Faster

The Canucks at Fuse Interactive have posted a great checklist of Drupal performance tuning tips. Interested in digging deeper? Video of Nate Haug's performance tuning deep-dive from the 2011 Do It With Drupal conference is available for free on Drupalize.me. Related: A fantastic 2011 article that introduces software-focused devs to the exciting world of server management and "DevOps."

Small Teams Do It Efficiently

Distro vs. Cobra Commander

Bill Fitzgerald of FunnyMonkey writes about the next generation of Drupal complexity: administering sites built on top of distributions. The short version? features, install profiles, and similar tools have given developers more deployment options but the full life cycle of those sites brings new challenges. Drupal devs and product owners will be talking about these issues and more at the DrupalCamp San Diego Distributions Summit. Looking for a Drupal outsider's perspective on configuration-based system design? This post on "Duck Programming" covers some of the dangers and possible solutions.

I've Got A Backup Strategy In My Pocket

In 1956, IBM introduced the ground-breaking IBM 350 hard drive. Capable of storing an astonishing 3.75 Megabytes of data, it was the size of a large washing machine and could be leased for a mere $3,200 per month. At this year's CES convention, Victorinox introduced a Swiss Army Knife with a built-in 1TB solid-state hard drive. Don't let that go through the wash...

Jan 09 2012
Jan 09

Within the Drupal community, we continue to wrestle with what, exactly, these things called distributions should be, and could become. Going into D7, the benefits of distributions (and specifically, the tools that support building distributions) are clear to developers. For most shops, the notion of building a site without using (at the very least) features hasn't really been an option for the last few years. Within FunnyMonkey - like at many other shops - we treat custom builds as product development, creating an install profile to contain config that can't be pushed to features, and making use of drush make during the build. Again, this is nothing horribly unique; this workflow simplifies testing, and technical decisions can be directly traced to code or a feature. Over the course of even a mildly complex project, having a clean, replicable build for all team members to work against saves countless hours of time.

Mind the Gap

But this is really only of interest to developers, or to people who directly benefit from a clear development process. These benefits filter down (theoretically) to the end user and content administrator in the form of a site that is easier to manage and use. But, the power of distributions has yet to become obvious to less technical users because, up to this point, the focus of distributions has been on automating a site install that delivers complex functionality out of the box. Distributions have done a great job solving this issue. Between installation profiles, drush make, and features, many of the pain points of replicating site builds have been eliminated or minimized.

So, using distributions, Drupal can be used to create products, and everyone can build an app store, and developers can sit back and make it rain.

Except: while distributions have taken the pain out of replicating complex site builds, they still require ongoing maintenance. Like every other software system, technology requires periodic updates; Drupal is no exception. Any Drupal site, whether built from scratch or deployed from a distribution, requires maintenance over time.

Most distributions are based on a collection of features. As a result, maintaining a distribution raises an additional question: should a distribution attempt to stay synchronized with the features that power the distribution, or with the underlying modules that are used within these features?

Tracking Overridden Features

The reflexive answer - the satisfying answer, the one that we want to be right - is that any site built on a distribution should stay synchronized with the features that drive the distribution. Over time, these features will evolve, and will have new, better, shinier functionality. However, the strength of features makes managing the config covered by that feature potentially more complex over time (there are many strengths and advantages to features, but one of the most obvious is the ability to push complex config to code where it can be managed and tracked via version control). Even a simple change (adding a field to a view, adding a field to a content type, changing a variable that has been strongarmed, etc) results in the feature being overridden. Over time, these overrides will need to be tracked against the features in the base distribution, and reverting these overrides could potentially break customizations in the production site. So, on a production site with overridden features, the overrides need to be tracked and either merged or ignored on each feature update. This is very possible to do, but it requires a level of technical expertise that is generally beyond the immediate reach of the people that distributions are supposed to empower: less technical users who just want to launch and use a web site.

Distribution-based Sites as Standalone Web Apps

And this brings us to the other alternative: once a site has been deployed from a distribution, that site is essentially detached from the distribution, and the site should be viewed as a standalone web app. With this approach, the features used on the production site should be checked into version control, and all site-specific overrides should be committed. This approach cuts the site off from potentially all future improvements in the base distribution, but it ensures that all modifications remain untouched. And, of course, this method requires a level of technical expertise that undercuts one of the main selling points of distributions. Managing overridden features in a sane way requires technical expertise, and distributions are supposed to make it easier for non-technical people to run Drupal sites.

Middle Grounds

There are additional possibilities here for working with and adapting the features within a distribution, but all of these methods require a level of technical expertise that undercuts the "distributions will simplify Drupal for non-technical users" argument. Probably the best option involves having features that are well architected, and make logical separations with documented dependencies within features. Then, end users can turn on the features that they want, and then they can clone and modify or ignore the features that they don't want to use. This leaves the core features untouched and in synch with the base distribution, but it also creates an additional set of features that should be managed via version control.

In any case, no matter the approach, maintaining a complex web site requires technical expertise. Distributions take the pain out of deployment, but they haven't done the same for maintenance.

Where To Go From Here

At the risk of stating the obvious, keeping all features untouched is really only possible in a SaaS environment, or an environment where the site admin has the discipline to resist unnecessary changes to the config. Aside from these two scenarios, most sites will require some modifications to meet the specific needs of the people running the site. And it's worth noting that in a SaaS environment, people are used to not having full admin rights, so there are use cases where only providing limited admin access could work. But, for most people/organizations, one of the key appeals of Drupal is the ability to tinker, modify, and expand the base build. This is good, and normal, and natural; if an organization doesn't think about how to use their web site in different ways after the initial launch, they are essentially stuck in time, and that's not good, and distributions need to be flexible enough to support that reality. However, within the community, until we clarify what we mean when we talk about admininistering a site deployed from a distribution, people using distributions will remain uncertain about the best approach to keep their site working well over time.

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).

Aug 29 2010
Aug 29

DrupalCon Copenhagen comes to an end, as does my blogging hiatus.

Two of my primary learning objectives here in Copenhagen were configuration management and deployment process. Historically, working with Drupal in these areas has been unpleasant, and I think that's why there is tons of innovation going on in that space right now. It needs to be fixed, and new companies are springing up to say "hey, we fixed it." Often, the people running the companies are the same people running the project that encapsulates the underlying technologies. I'm referring to:

  • The hyper-performant core distro, Pressflow
  • Distros with sophisticated install profiles, like OpenAtrium, ManagingNews and OpenPublish
  • Configuration externalization with Features
  • Development Seed's "for every site, a makefile" workflow using drush make
  • The different-yet-overlapping hosting platforms Pantheon and Aegir

Dries commented in his keynote that as Drupal continues to grow, it also needs to grow up. I think advances like these are part of the community's answer to that. I want to wrap my head around some of these tools, while continuing to watch how they progress. Others, I want to implement right now. What's perfectly clear though is that I have a lot of work to do to keep up with the innovation going on in this hugely powerful community. Which is actually nothing new, but reading a blog post about these technologies doesn't make my jaw drop the way that it does when I'm in the room watching Drupal advance.

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