Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 day 9 hours ago

Web Wash: Control Context Using Context Entity Field in Drupal 7

21 April 2014 - 2:27pm

When you need to dynamically display a block within a region, nothing can really beat the Context module. It allows you to define a set of conditions, that when met, executes a set of reactions. For example, you could create a context rule which adds a block to the sidebar second region (reaction) when a user is viewing an Article content type (condition).

A lot of what Context does can also be achieved using Panels. But if you're new to Drupal, and never used Panels than Context will be easier to use.

If you're new to Context then I would highly recommend you watch the two introductory videos below:

Recently I've discovered a powerful module called Context entity field. It allows you to define a condition that checks the value of a field on an entity.

Categories: Drupal

Drupal core announcements: This week (or two or three) in Drupal Core

21 April 2014 - 1:02pm
What's new with Drupal 8? Configuration system changes

Over the past month, a lot of work has gone into the configuration system. With the addition of a separate module install/uninstall step for the config import process, it's finally possible to properly synchronize configuration changes with module installations or uninstallations. You can now transform a site installed with the Minimum install profile into a site using the Standard install profile by importing configuration (the case we've long said will be our indicator that CMI "works"). (Watch this screencast to see it in action!)

Additionally, after thorough discussion, the active storage for the configuration management system has been moved into the database by default. This means existing Drupal 8 sites will likely need to be reinstalled (or otherwise migrate the active configuration). Read the change record on active configuration in the database for details on why this decision was made.

Now is the time to start really testing CMI deployments. Spin up a dev site, make a copy of it, and test synchronizing complex configuration system changes between the two. See if the system behaves as you expect (and report the problems you find!) For an overview of the outstanding work being done on the configuration system, see #2187339: [meta] CMI path to beta.

NYC Camp at the United Nations


The third annual NYC Camp was held at the United Nations. (Yes, that United Nations, with the flags.) In addition to numerous sessions about Drupal 8 (check out fmitchell's session on 30 Drupal 8 API functions you should already know), we held several days of Drupal 8 core sprints. Media contributors also sprinted on Media for Drupal 8; check out their sprint status report for more information. Finally, Drupal Association executive director Holly Ross worked on a Drupal 8 patch got her first Drupal core commit credit! Are you next? :)

Where's Drupal 8 at in terms of release?

We're in the last stretch of Drupal 8's alpha phase. We've fixed over 130 beta-blocking issues, including 9 in the last week, plus written more than 70 missing change records. The last 28 beta blockers include some difficult issues, but consider some of what we've already accomplished since the beginning of 2014:

  • The removal of the variable subsystem after 18 months.
  • The rearchitecture of configuration synchronization to support the minimum viable usecase after 16 months.
  • The removal of the legacy menu router after nearly a year.
  • The removal of widely used cache-breaking functions including drupal_set_title(), drupal_add_css(), drupal_add_js(), and theme().
  • The removal of all stale hook_update_N() implementations and the modification of update.php to require Migrate for major version upgrades instead.

(And of course so much more.)

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record.

  • #2116363: Unified repository of field definitions (cache + API) converts remaining usages of the deprecated field info API to use methods from the entity manager, and is therefore critical to stabilizing the Entity Field API for the beta release. This significant (~150 KB) patch needs thorough code review from contributors familiar with Drupal 8's entity and field systems.

  • #2183231: Make ContentEntityDatabaseStorage generate static database schemas for content entities is an even larger (~250 KB) beta-blocking patch for the entity system that allows the entity system to automatically create the necessary database tables for entities, resolving numerous different issues. This is another significant change and needs lots of thorough review from as many people as possible.

  • #2198429: Make deleted fields work with config synch needs review of the patch's architecture and functionality. Deleting a field is a significant operation, because the site has to go on to purge all the field instance data for entities that have the field while leaving those entities intact. Drupal 7 includes a lot of code to support this functionality, and in Drupal 8, there's additional complexity since this purge needs to happen when a deleted field is staged and synchronized to another environment.

  • #2124749: [meta] Stop using request attributes as a storage mechanism for other services covers a collection of issues to improve the developer experience around Drupal 8's use of Symfony's request attributes (a public property on the request object that can be used for context-specific information about the request). This context information is not easily discoverable for contributed module developers, and, in some cases, using it adds to the apparent verbosity and complexity (e.g. in the replacements for the common D7 functions menu_get_object() and menu_get_item()). The numerous sub-issues for this meta issue are intended to weed out misuses of the request attributes and provide clear public APIs for others. Help discuss the developer experience and architecture in the numerous child issues for this meta.

More ways to help Notable Commits

The best of git log --after=2014-04-02 --pretty=oneline (207 commits in total):

Configuration management

As we described above, it's been another couple weeks of fantastic progress in getting the configuration management system solid for beta. Notably:

  • Issue #2161591 by pwolanin, beejeebus, sun: Change default active config from file storage to DB storage.
  • Issue #1808248 by alexpott, beejeebus, tayzlor, Nitesh Sethia: Add a separate module install/uninstall step to the config import process.
  • Issue #2124535 by Berdir, alexpott, Désiré, xjm | yched: Prevent secondary configuration creates and deletes from breaking the ConfigImporter.
  • Issue #1740378 by xjm, Désiré, alexpott | heyrocker: Implement renames in the import cycle.

There is still plenty to help out on in the CMI path to beta meta issue if you want to help keep the excellent momentum of the last few weeks going.

Entities and fields

One of the many accomplishments from Drupal DevDays a few weeks ago, was a cute and colorful visualization of the long dependency chain of issues remaining to stabilize the Entity and Field APIs for beta. Two of them were committed in the last two weeks:

  • Issue #2225739 by killua99, Berdir, andypost, pfrenssen: Remove usage of field_info_instances(), use EntityManager::getFieldDefinitions() instead.
  • Issue #2226197 by fago, jessebeach: Introduce FieldStorageDefinitionInterface in the Entity Field API.

That has unblocked Unified repository of field definitions, which is now making good progress, and when committed, will unblock the next level of the dependency chain.

Migration

With a Drupal 8 beta approaching, how exciting will it be to start testing it out with content and configuration from an existing Drupal 6 site?! Several issues were committed that pave the way for that, including:

  • Issue #2211949 by chx, Berdir, fago, benjy: Support keeping new revision id for migrate.
  • Issue #2190561 by chx, pcambra, benjy: Migrate in core: Add a load system for migrate plugins.

And now, there's a 600KB patch containing 82 actual migrations ready for review.

A meta for everyone

No matter what part of Drupal you're interested in, there's probably a meta issue available for you to chip away at. Here's just some of the ones that had a commit in the last two weeks.

Front-end
  • When creating a theme, just when you thought you overrode everything you needed to to get all your markup exactly how you like it, do you hate having to discover yet another obscure theme function that inserts an unwanted <div>? Well, the Twig team is cleaning that up as part of converting theme functions to Twig. Congratulations to them for removing a function entirely in: Issue #2151123 by joelpittet | Cottser: Remove theme_system_modules_incompatible().
  • What's even better than fewer one-off theme functions to override? How about default markup that's perfect to begin with? There's a meta issue and an issue tag for that. Yay for progress on that with: Issue #2226923 by pakmanlh, mandar.harkare, mortendk, galooph: Views: remove wrapper around more link - add class to the link.
  • Great default markup is only half the battle. We need great default CSS to go along with it. Nice to see another issue completed on that: Issue #1662954 by balis_m, mjonesdinero, kalpaitch, IshaDakota, kerasai, ckrina, BarisW | ZenDoodles: Use less-specific tabledrag selectors.
  • And let's not forget about Javascript. In Drupal 8, we've incorporated some fantastic JS libraries. It's important that we keep up with their updates, including: Issue #2192383 by tstoeckler: Update jQuery to 2.1.0.
Back-end

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Blog posts about Drupal 8 and how much it's going to rock your face.

Drupal 8 in "Real Life"
  • First off, there are numerous upcoming sprints in Washington, DC (April 22), Brisbane (April 23), London (April 26-27), and Stockholm (May 4), plus a Drupal 8 Search API sprint in Zurich (April 28-May 2). Try working on a Drupal 8 core or contrib issue at one of these sprints!
  • April 23-25: DrupalCamp Mexico has several Drupal 8-related sessions and a whole "SymfonyDay" track!
  • April 25-27: DrupalCamp Donetsk will include a presentation on Drupal 8 from webchick.
  • April 26: DrupalCamp St. Louis also includes a Drupal 8 introduction.
  • May 2: DrupalJam in the Netherlands has a session on Drupal 8 patterns (plus maybe a streamed Q&A with Dries!)
  • May 2-4: DrupalCamp Toronto doesn't have a set schedule yet, but there are numerous Drupal 8 session proposals.
  • May 31-June 8: DrupalCon Austin and extended sprints. This year's North American DrupalCon will include many Drupal 8 sessions, trainings, and sprints. The conference is June 2-6 with the community sprint on Jun 7, and there are plans extended sprints the weekends before and after the conference. See the signup sheet for Austin's extended sprints. Austin will be critical to make progress toward Drupal 8's release, so please plan to participate in the sprints if you can!
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Drupal

Janez Urevc: DrupalCamp Alpe-Adria - ticket prices go up in only 4 days!

21 April 2014 - 10:22am

DrupalCamp Alpe-Adria will be one of the most scenic Drupal events this spring in Europe. It will take place in a magnificent costal town Portorož, which is conveniently located in the northern part of Adriatic sea.

Camp will happen on 17th and 18th May with extended sprints happening also on 19th and 20th. We already have some great session proposals and new ones are coming in almost every day! Are you new to Drupal? No problems! We're preparing some very interesting beginner-level sessions and on-site trainings. For those who prefer to code we have some very interesting sprints to offer! There will be Drupal 8 core and Drupal 8 media sprints going on. Are you interested in organizing another sprint? Do not hesitate to contact us immediately!

Early bird tickets are available only until 25th April. Don't miss your last chance to get them and start planning your travels well in advance. Portorož is very nice for families and children so you should really consider bringing your significant others with you and maybe extending Drupal camp into a short spring vacation.

Categories: Drupal

Drupal Association News: Continuous Integration Efforts Get Easier with Drupal 8

21 April 2014 - 7:20am

At MidCamp (Midwest Drupal camp), I found out a really fascinating thing about Drupal 8: Support for PHPUnit is going to be part of the base distribution. This means a great deal to Solutions Architects and Developers at Promet because we have been striving to integrate automated tests into our build. Perhaps you remember from my talks or previous posts, number four of my 10 Principles of Continuous Integration is "Self-Testing Build". This makes Drupal a much more sought-after platform for shops looking to fully embrace Continuous Integration.

What do we do now?

Currently, Promet uses PHPUnit for testing purposes. Our team (Michelle Krejci and Will Milton), have instituted the use of Behavioral Driven Development (BDD) using Travis-CI, Behat, Mink, PhantomJS, and PHPUnit. This provides our requirements, use-cases and a way to easily self-code-review. For those not familiar with Gherkin, I urge you review it. It's a simple process to write use-cases in English, such that someone can program tests against it. The confidence this has given our team in our quality of code, and the confidence the client has in the outcome is phenomenal.

Michelle can attest to this being the case. In a project she’s working on now, the tests are actually being used to get sign-off that work is complete. All of the tests were created ahead of time and the scenarios are added as needed; therefore, change orders are obvious because the tests are in version control. There is no question on what scenarios we are supporting, when one was added, or when a piece of work is completed to the specifications.

So how do we improve on BDD?

The problem with this workflow is that we have to jump to the Functional Test level to test anything at all. In terms of testability, it’s a tiny improvement compared to the Simple Test workflow Drupal has now. However, we have seen improvement since we’ve moved from Selenium to PhantomJS. As you probably know, PhantomJS and Selenium both do browser testing.

Selenium is a browser “driver”. Through javascript injection, it hooks into a browser allowing you to emulate a user “doing stuff” on a webpage. However, running those browsers is super slow. The startup time alone for each test is over a second… sometimes up to 5 or 6. Who has that kind of time?

In the case of PhantomJS though, we aren’t testing specific browsers. In fact, PhantomJS is a browser, and a mighty fast one at that. This is fine for Promet where it is less significant whether specific browsers function a certain way. PhantomJS has improved our performance for testing over Selenium by strides.

But there is something even better! Testing at a Unit Level!

 

 

Drupal has been nearly impossible until Drupal 8. We had the Simple Test framework that was baked into Drupal, but it did what I like to call the "Use a Car to Test Another Car" approach. Specifically, you had to have a full instance of Drupal running so that it could make a fake instance of Drupal so that you could test. Additionally, functional code isn't very encapsulated. That is, you can't specifically say, "My inputs are xyz, and my outputs are abc.". The lack of encapsulation is mostly due to frequent use of global variables and not being able to group functionality with data like you can with objects in Object Oriented Programming (OOP).

Fear not. The new object oriented framework gives us easy access to new-fangled Dependency Injection, mocking of objects, and other programming patterns that allow us to consolidate a single unit of code. In our case, a unit is a single function within a class, which is the smallest unit of code that can be tested using PHPUnit.

This inspires developers to not only write better, testable code, but in smaller testable units that are...(insert drumroll, please) Reusable, not to mention, easier to test.

So how does Unit Testing make things easier?

In several situations, we could rid ourselves of functional tests altogether. If every single piece of a component is working as expected, then the sum of those parts would equal a feature that works as expected. Lastly, those tests run a couple of orders of magnitude faster than the PhantomJS tests. This means that the tests can easily be part of the build script and not just something that runs on Travis-CI.

Speaking of Travis-CI, now we can integrate Travis-CI directly with Drupal. No more hacking the pieces together to get a testable environment outside the box.

Final Thoughts

Overall, BDD is still flippin’ awesome and has its place in projects; we will still continue to use it. BDD is great for communicating directly with the client with something testable. However, Unit tests will allow us to build a set of reusable code at a lower cost to maintain. These unit tests allow us to better gauge our quality of code. I think these facts, speaking strictly as a Developer, will improve upon the testing process that we already have in place, particularly for our migrations and more technical projects with APIs and integrations. Looking into the future and our use of Drupal 8, I am excited for the availability of new unit test results to be used as insurance to our clients to backup our claims of quality. Developers happy and clients happy? Yes please! Thank you, Drupal 8.

Categories: Drupal

Phase2: DevNation’s Hack Night Champs: Building A Drupal Hosting Dashboard On OpenShift

21 April 2014 - 6:18am

This past Wednesday night, I participated in the DevNation Hack Night in conjunction with Red Hat Summit. I was joined by Phase2’s CTO Frank Febbraro and Joe Caccavano, our CMO. Here at Phase2 we are big fans of OpenShift, RedHat’s open source Platform-as-a-Service (PaaS) offering, and we see a huge opportunity for Drupal in this space. In order to make Drupal a first class citizen on OpenShift, we helped develop Drupal 7 and 8 quickstart packages for Openshift in addition to building the official OpenShift Origin community site using Open Atrium, our Drupal social collaboration distribution.

Some of the benefits of using a PaaS like OpenShift is the ability to have a uniform environment, security, and automatic deployments with the Git distributed version control system. PaaS also gives you an API to spin up applications the same way Infrastructure as a Service (cloud computing) providers give you an API to spin up compute resources.

With our enthusiasm for OpenShift and Drupal, we decided to develop our own Drupal-based PaaS on top of OpenShift as a proof of concept at DevNation’s Hack Night. In just under two and half hours, we were able to create an application to host an OpenShift Origin set up on Google compute engine, and build a Drupal based PaaS on top of this.

In order to create a Drupal-based PaaS that can be used like other cloud hosting providers, we developed an application that runs on OpenShift that communicates with the OpenShift API to quickly spin up new applications. Our application was built with node.js and Angular and works alongside another application we built with PHP to help set up Drush-based automation for Drupal sites. With these applications running on OpenShift, you can have your dev, stage and live site all together with the ability to pull a database from stage to dev or promote a database from stage to live.

Here is a demo I have recorded to show the MVP we put together in 2.5 hours during the hack night.  We had a blast building this Drupal hosting dashboard with OpenShift and I’m happy to say that our team won first prize. Earlier during the conference, we also contributed a number of improvements to a Node.js OpenShift Client.

DevNation Screencast from Phase2 on Vimeo.

This project really shows the power of OpenShift Rest API’s: if you have access to any language that can consume REST web services, you can fully automate your application lifecycle. I’m looking forward to continuing to build, develop, and hack with open source partners like OpenShift.

Categories: Drupal

Frederick Giasson: Managing Resource Type Entities (Screencast)

21 April 2014 - 5:53am

In this screencast, you will discover how you can use the OSF for Drupal user interface to browse, filter and search for Resource entities that have been indexed in Open Semantic Framework (OSF) datasets. You will see how you can use it to manage what you want to expose on your Drupal portal.

Then you will see how you can create, update, delete and export Resource entities using Drupal.

Finally you will discover the revisioning system, and the revisioning user interface that is available to the Drupal administrators.



Categories: Drupal

ThinkShout: Desire Paths, Part 1: Retracing Your Audience's Steps

21 April 2014 - 12:00am

Why do people visit your organization’s website?

It’s such a basic question, I’d hesitate to posit it – if it weren’t so fundamental to the work of making the world, and the Web, a better place.

If your first thought was something along the lines of “To support our work, of course”, note that the question is not “Why should people visit” but “Why do they”.

Nonprofit organizations often approach communications and outreach assuming that everyone should just get it. Because you spend so much time organizing around complex issues, you may assume a shared vocabulary with the broader world when that vocabulary really only resonates within your organization.

This is further complicated because nonprofit departments often have competing priorities: Development wants donors, Program wants event participants, Communications wants names for the email marketing list.

I can pretty much guarantee that very few people arrive at your website thinking, “You know what would be great? Giving you my email address.”

The truth is, the motivations of your visitors are often very different from your organizational goals. This is further complicated because, to paraphrase Jeanne Bliss from Chief Customer Officer, “The nonprofit often does not live in rapport with its constituents because they don’t experience the nonprofit through its departments. The constituent experiences a nonprofit horizontally, across its departmental silos.”

To improve the efficacy of your website by making your users happy, you must resolve the dichotomy between “Desire Paths” and “the desired path.”

“Desire path” is a term of art in the urban planning world describing the shortest path between an origin and a destination, particularly those that weren’t planned. You’ve seen them: a dirt trail between two sidewalks, a cut corner, a hole in the fence. Desire paths exist in defiance of all the thought that goes into a made environment, the creation of what planners consider the right way to move through a space. An architect might think, “The staircase will give this hill some gravitas.” The college students may think, “Ehn, I’d rather just walk up the hill,” the resulting path eroding that gravitas.

You can see the parallels to your website, I’m sure. We spend hours thinking about the information architecture most likely to move visitors into a funnel that will lead them to donate or volunteer – only for them to pop up on that blog post mentioning Channing Tatum, liking it, and closing the tab.

If Channing Tatum resonates with a core audience segment, you need to find a way to tap into that. The magic of the Internet, the work of the user experience engineer, is to find the intersection of the desire path – the motivation driving someone to visit your site – with the desired path, or any of the potential actions you hope a visitor will take to support your organizational goals.

To begin, understanding how they arrive at your website will give you clues about what motivated them to check you out.

Search

There’s no greater shortcut to your content than the Google. In the 7 years since analytics guru Avinash Kaushik pronounced “Home pages are dead,” we’ve seen search become ever more important.

As much as we may complain about web search being the ultimate conversation killer, these people are coming to your site driven by the desire to know something. Is your website prepared not only to answer the question, but to redirect that motivation into greater engagement?

In a recent audit of some of ThinkShout’s great clients – with monthly traffic ranging from a couple of thousand visits on up to hundreds of thousands – we found:

  • Homepage traffic accounted for less than 20% of the total for 7 of 9 organizations; for 2 of the 9, it’s less than 10%.

  • The percentage of traffic driven by search was more than 40% for 7 of 9; for 5 of them, it’s significantly more than half.

  • The bounce rate for search traffic for 6 of the 9 was significantly worse than for the site as a whole.

I do need to toot a little horn for the team here at ThinkShout, because for the 4 sites we can compare year over year, we’ve seen improvements of between 6% and 20% in the bounce rate for search traffic post-redesign. That’s because, as part of our discovery process, we put user motivations first – and you can, too.

Tip: Know Your “Search Terms”

Search traffic is probably the easiest to get real, actionable data for, even if all you have is Google Analytics.

This is advice that has been repeated almost endlessly, but Google made it more complicated a few years ago by filtering out search results for anybody logged in to one of their products. (You know, almost everybody.) Fortunately, there’s an easy way to approximate that data.

  1. Go to the organic search terms report at “Acquisition” -> “Keywords” -> “Organic.” You’ll see most of the terms are “not provided."

  2. Set the “Secondary Dimension” to “Behavior” -> “Landing Page.” This will show you where that “not provided” traffic is going, which can give you a clue as to the search terms.

  3. Click the “advanced” link next to the search box and change it to “Include” “Landing Page” “Containing” and the URL of one of your landing pages, then click “Apply.” This will align the “not provided” landing page with all of the returned search terms for that page. Extrapolate from there for each of your highest traffic landing pages to build your list of important search terms.

Social Media

Social media traffic is generally some of the worst quality, in terms of meeting your organizational goals.

The metrics for bounce rate, visit duration, and pages per session were significantly worse for social referrals compared to the site as a whole for 6 of the 9 organizations we reviewed. (Interestingly, the redesigned ThinkShout.com showed significant improvement across the board.) For the most part, they come, they spend a moment, they go back to Facebook.

Social traffic can be driven by all sorts of user motivations, from links posted in your own social channels – “I want to keep up with the latest news from one of my favorite organizations” – to something posted on your Wall by your mom – “I’d better know what that is so I can talk about it at our next dinner.” You’re not likely to meet all of them, so your analysis should focus on the highest value interactions. What are the outliers? If you have a few pages that outperform the majority, try to figure out what’s unique about them.

Again, pay special attention to landing pages. High bounce rates from a news article about your latest initiative probably won’t be of much concern. Bounces from your donation page should be: what drove traffic there in the first place, if it wasn’t you? Find those influencers!

Tip: Set up a special Analytics dashboard for social media.

Even if you can’t afford something like Radian6, you can use Google Analytics to do some pretty good analysis of traffic being driven to you by social channels. I find that the default reports provided are actually harder to use than they used to be, but you can aggregate the information most important to your team on a custom dashboard.

  1. Start with a premade dashboard. Go to “Dashboards” -> “New Dashboard” and click “Import from Gallery.”

  2. Justin Cutroni’s “Social Media Dashboard” is a great starting point. Click “Import”.

  3. “Social Media Dashboard” will now be listed as an option under your Dashboards. Modify it to meet your needs!

Other Referrals

If somebody likes your content enough to post it on their own website, you need to be aware of that, not just because you may have found a new partner, but because analyzing the pages sending traffic to you can tell you more about your own (potential) audience.

One of ThinkShout’s clients got significant traffic – roughly 3% of the site total in the first quarter of this year – from a regional magazine, mostly from a single article in which they were mentioned only tangentially; 90% of the visits are new to them. Knowing this opens the opportunity to think about user motivations from several angles:

  • What is it about our services that prompted the magazine to mention us? What do they know about their own audience that caused them to try to match them to our own? Are there other opportunities to engage that audience? Could what became a major landing page have been structured better?

  • What is it about the service described that prompted all the clickthroughs? These folks had a particular motivation for engaging with the content on the magazine’s site in the first place, which triggered the motivation to look at our offerings. How can we tap into that?

  • Was there any difference in behavior between the new visitors and repeat visitors?

Tip: Look at the actual sites and pages that are referring traffic your way.

  • Go to the basic Referrals report in Google Analytics: “Acquisition” -> “All Referrals.”

  • Click the domain name of the “Source” that interests you. This will bring up a list of the pages on that site that have referred visitors to you.

  • Combine one of the referral pages with the domain of the source. (Side note: I’m sure Google used to provide a direct link to this, but doesn’t seem to anymore. Boo.)

  • Spend some time poking around the site. Think about their audiences and what may have sparked the interest in your own content.

Campaigns

You’re probably running campaigns to drive your current supporters to your website through email, social channels, and web advertising – maybe even billboard, radio, and TV, if you’re blessed with a large advertising budget.

If you’re not already using tracking codes to better quantify the success of your campaigns, you should be. The desire paths here will be much more evident – and likely in line with your organizational goals: you send out a Call to Action (CTA), they respond. The key thing to watch for here is when the CTA doesn’t lead them to take desired action.

Tip: Track your non-digital campaigns.

Just because you’re not sending a URL to your supporters directly doesn’t mean you can’t put some basic campaign tracking in place.

  1. First, set up the campaign URL, complete with codes.

  2. Then, redirect to that URL, which Google will pick up.

    • For print, you can embed the long campaign URL in a QR code.
    • If you don’t expect your users to have a QR reader, create a simple landing page with a redirect to the tracked URL: your.org/campaignname is reasonable for somebody to type into a browser, so hit it with a 301.
    • Or, use an URL shortener like bit.ly to create the redirect to the campaign URL for you.
Direct Traffic

Uh-oh, I was afraid you were going to stick around this long. There’s not much to say about “Direct” traffic, in terms of quantifiable user motivations. Maybe they typed your URL directly into their browser. Maybe somebody chatted the URL to them (the so-called “dark social” network). Maybe your mom’s proud of your work and mentioned it to a friend. Maybe they’ve bookmarked your site. Maybe you sent out an email campaign without a tracking code. Maybe… well, you get the picture.

Direct traffic does not have a lot of data attached to it that will enable you to figure out why a user arrived at your site beyond examining their landing pages.

This is, however, very important traffic: for some reason, almost unbidden, they showed up at your site. We can still apply the concept of desire paths to this segment, we just need to do it a bit differently: by taking a look at how they move through your site itself.

Determining “how” users arrive at your site is just the beginning of understanding the “why.” The next question to answer is “what”, as in “What are they doing on our site now?” By combining “how” with “what”, we can build models of behavior that will help us understand what motivates our audiences to seek us out online.

And once we get to the “why”, we be able to create structures that tap into the identified desire paths and subtly redirect them in ways that will help you meet your organizational goals.

So, if you’re so motivated, add to ThinkShout’s “direct traffic” report by bookmarking this page and we’ll point you to the next part when it’s available.

Categories: Drupal

Drupal core announcements: Approachable tasks for Drupal 8 Beta 1

20 April 2014 - 6:28pm

If you couldn't make the (nearly) back-to-back sprints on beta-blocking issues at Drupal DevDays Szeged and NYC Camp, don't worry! We still have some leftover sprint tasks that will help with the first Drupal 8 beta release. Many of the 27 remaining beta blockers require deep knowledge of the problem space; however, the tasks listed here (while not necessarily quick or easy) are more approachable and self-contained. Some of these issues are beta-blocking in their own right; others are "beta target" issues that would ideally be done for a beta release even if they aren't critical enough to block it.

If you're new to core contribution or Drupal 8, check out the Core Contribution Mentoring program instead.

Documenting Critical Drupal 8 APIs #1988612: Change record: Apply formatters and widgets to rendered entity base fields

Entities in Drupal 7 and 8 have two kinds of field data: base fields (or properties in Drupal 7), like the node author field or the taxonomy term description, and configurable field instances, which can be attached to a given fieldable entity type's bundles through the user interface. Previously, it was not possible to use widgets or formatters for base fields, so they typically use custom form elements and rendering code that are not compatible with Drupal 8's in-place editing functionality. Since December, however, it is possible to use widgets and formatters on base fields -- but there is no change record yet for this improvement.

#2244777: Document in WSCCI change notice or handbook all the menu changes (tasks, actions, contextual links, menu links) from 7 to 8

In order for contrib developers to make good use of our first beta release, we need good documentation of the new Drupal 8 routing and menu systems. The first step is to thoroughly document exactly how a Drupal 7 module's hook_menu() is upgraded to Drupal 8, and the exisitng change record is only partially complete. Join the discussion on this issue and help us complete this critical documentation.

#2046367: Document the internals of the router

While not explicitly beta-blocking at this point, more complete API documentation for the routing system overall will be very valuable to contributed module developers using the first beta release. Help improve the routing documentation both in the Drupal.org handbook and in the Druapl 8 codebase.

#2235363: Document how plugin definitions should declare config dependencies

This is a documentation followup for one small API change that supports the new configuration dependency system. It sits at the intersection of two new (and complicated) Drupal 8 APIs: plugin derivatives and the configuration entity system. Most of the confusing work for this issue is done, and it has resulted in a new handbook page on configuration entity dependencies. The remaining task is to add documentation of the config_dependencies key in plugin derivative definitions to the API documentation in the codebase. (See under "Calculating dependencies in plugins and their derivatives" on the handbook page.) The handbook page, which is about configuration dependencies generally, also needs further work, but that is not blocking for this issue.

Configuration system #2224761: Translation sync should be stored in own storage instead of injected in field instance settings

This issue for the content translation module changes the way some of the module's configuration is stored. It's an easier change to implement compared to other deep architectural beta blockers for the Configuration system and the Entity Field API, but it still needs some work to resolve. The next step is to incorporate the latest feedback in comments #24 through #27 on the issue. This is also a great spot for multilingual initiative contributors to help with the beta.

#2140511: Configuration file name collisions silently ignored for default configuration

This critical configuration system bug isn't a hard blocker for the beta release, but it can cause significant problems. An in-progress patch on the issue needs test failures resolved, updates for the latest changes in the configuration system, and other improvements.

Entity Field API #2016679: [Meta] Expand Entity Type interfaces to provide methods

Drupal 8 core provides numerous entity types, but the full API for each type is not easily documented or discoverable, since the entity's properties are accessed through magic getters. To improve the developer experience, each entity type interface is being expanded with relevant methods for the specific entity. (For example, NodeInterface now has methods like isPromoted(), isPublished(), getTitle(), and setTitle().) All the methods for content entity types have been added, but only 1/4 of the configuration entity type interfaces are complete. Most issues have a submitted patch, and what is most needed is architectural review of the proposed interface methods. (For example, see comment #19 on the FieldConfig issue.) If you have experience with one of the subsystems that still has an open child issue, or if you have a sound grasp on OO design generally, we could use your help to thoroughly review these patches so that the completed APIs are available for contributed module developers in a beta release.

#2190313: Add $EntityType::load() and loadMultiple() to simplify loading entities

In a similar vein of improving the entity system's developer experience by making the API more discoverable and removing exposure to internal concepts, this issue adds static methods for loading the entities of each type. The patch needs to be rerolled to apply to HEAD, and then needs architectural review.

#2010930: [META] Apply formatters and widgets to rendered entity base fields

Remember that issue above about widgets and formatters for base fields? We also need to convert base fields other than the node title to also use widgets and formatters rather than custom code. This isn't considered beta-blocking, but it will change how contributed module developers interact with these entity types (plus make it so that in-place editing behaves in a more expected fashion). The several child issues of this meta (one per entity type) need either further work on the patch or code review. If you're somewhat familiar with entities and fields in Drupal 8, this is a good place to help.

Views conversions #1823450: [Meta] Convert core listings to Views

One of the major benefits of having Views in core is that legacy one-off listings in core can be replaced with user-configurable views. Views is used in numerous places in core already, for example, the user and content administration screens, the promoted node frontpage and RSS feed, and numerous blocks like the "Recent content" and "Who's online" blocks. A handful of more complicated legacy core listings still need to be converted to views. These conversions don't block a beta release, but are targeted for the beta since adding them involves removing legacy API functions. In particular, it would be valuable to complete the conversions of the comment admin page and the taxonomy term pages to views for a beta release. Additionally, replacing the content revision table with a view is blocked on a major views bug related to content revisions.

Categories: Drupal

Hook 42: Hook 42 Presentations at Stanford Drupal Camp

20 April 2014 - 2:53pm
Friday, April 18, 2014 to Saturday, April 19, 2014

The Hook 42 team had a great time at Stanford Drupal Camp this weekend.  Kristen and Aimee presented two sessions each and four other members of our team attended, Lindsay, K2 (Kristin), Marc, and Marc's 15 year old son Dean.  It was the first Drupal camp experience for the extended team and they enjoyed the great topics, beautiful facilities, and the welcoming community.  Many thanks to the Stanford Drupal community for hosting such a great event!

Kristen and Aimee presented four sessions.  We normally cover a bunch of detail so we've attached our slides for your reference:

  • Site Tune-up, Vroom Vroom! by Kristen Pol (DrupalCon session!) - Session Overview
  • Migrating from Drupal to Drupal: Using migrate and migrate_d2d by Kristen Pol - Session Overview
  • Zicasso Case Study: The Million Node Migration (Business Emphasis) by Aimee Degnan - Session Overview
  • (Don't Fear) The Features, Now With More Cowbell by Aimee Degnan - Session Overview

If you have any questions, contact us!

Other interesting links:

Attachments  zicasso-case-study-business-pm-hook42-stanford.pdf features-more-cowbell-hook42-stanford.pdf hook42-drupal-migration-v1.pdf hook42-drupal-site-tuneup-v1.pdf Aimee Degnan Kristen Pol Topics: Services:
Categories: Drupal

Friendly Machine: The Case Against Drupal Base Themes

20 April 2014 - 11:34am

When it comes to Drupal base themes, it seems the conversation is often limited to which one you should choose, rather than discussing whether you should be using one at all. As someone who has spent a lot of time extolling the virtues of base themes, I thought I'd share the other side of the argument and ask if we should we use contributed base themes in our projects.

This discussion is really part of a larger debate that front-end developers are having about CSS and grid frameworks in general (see here and here), but it seems particularly relevant when discussing Drupal base themes because all of the issues are magnified due to added complexity.

Why We Use Base Themes

Why do so many of us use base themes? The easy answer is that they can save us time and potentially make us more efficient. Sometimes they can also act as common ground for development teams. But I think a more complete answer is that they act as a useful crutch, particularly when first learning Drupal theming or responsive design.

At some point we all had to build our first Drupal site or our first responsive site - probably under deadline - and we looked to a base theme or framework for help. It allowed us to get the job done on time and within budget, but perhaps without fully understanding everything that was going on under the hood.

Over time we probably learned most of the base theme and developed a deeper understanding of responsive design, but the framework eventually became a comfortable place. We stuck with it, happily soldiering on until one day...

When the Shortcut Becomes the Long Way

If you've been working with base themes for a while, the moment has certainly come when you have found yourself fighting with it. By design, base themes and other frameworks are opinionated - they make decisions about how to solve certain problems. Most of the time this is a good thing. It can help you accomplish things more quickly. Until it doesn't, and then your base theme is actually slowing you down and causing problems.

Part of the reason why this happens is that the developer doesn't have full mastery of the base theme -  or underlying concepts  - and therefore doesn't know why something is happening. This is bound to happen with base themes like Omega and Zen that are complex and have a very granular file structure, lots of hooks, etc. It can take some effort to track issues down.

Other times it's not mastery as much as the choices being made by the base theme don't match up with the project at hand. You find yourself at cross purposes with the base theme, possibly even trying to sort out incompatibilities between the base theme and a module you want to use.

And all the hacks you add to sort things out? More kilobytes that have to be downloaded by a user on a mobile device.

Fast Sites Win the Day

This leads us to another reason you might not want to use a base theme - it will probably slow down your site vs a theme that is tailored for a specific project. The case has been definitively made that faster sites are more successful sites (see here and here). In most cases, base themes are going to include a lot of stuff that you are not going to need on a given project. The 'extra' stuff is bloat that will end up slowing your site down.

This isn't a slam on base themes. Most of them are akin to a Swiss army knife. They have things in them that help accomodate a lot of different scenarios - they're flexible. This can be a big help if you're a beginner, but what if you're a seasoned front-end developer tasked with building a high performance site?

In that case, maybe a base theme isn't the way to go.

The Role for Base Themes

Some will sing the praises of Mothership or Tao or their favorite lean base theme of choice, insisting it solves all of the issues I've mentioned. I certainly have no quarrel with using those base themes on projects if you've mastered them and find them useful. It can also be helpful to employ Zen or Omega. It really depends on the specific project. This isn't a post bashing base themes.

My own thinking on the topic, however, has shifted. I've decided to move away from base themes whenever possible. My decision stems from wanting lean code that helps me build fast, mobile-first sites. It also allows me to understand exactly what is happening with the code because I'm the one who wrote it. Ultimately, I think this practice makes me better at my job as a front-end developer, and importantly, I'm also delivering a better product to my clients. I came to this place after spending so much time hacking apart base themes that they were no longer recognizable. It made more sense to just chuck them entirely and start fresh.

Of course, I haven't thrown efficiency considerations aside. I have my own starter theme to make my work easier, and this is what I would advise others who are considering a base theme to do as well. Create your own bag of tricks. If there ends up being things in it that don't fit a particular project, you'll know exactly where they are so that you can easily discard them.

One last tangential thought on this topic - a fantastic development for Drupal 8 would be for core to add no CSS whatsoever, minimal markup and then let themes in contrib add commonly requested bells and whistles. This is a philosophical approach that would be hugely positive for Drupal as a mobile-first approach takes hold as the standard for front-end development.

If you have any comments on this post, you may politely leave them below.

Categories: Drupal

bojanz's blog: How Devel causes heisenbugs

19 April 2014 - 4:52am
Here’s what killed my Friday. The story has been edited to remove pain, suffering, prolonged coffee intake. Read more...
Categories: Drupal

Frederick Giasson: Configuring and Using OSF FieldStorage (Screencast)

18 April 2014 - 6:07am

This screencast introduces you to another one of the most important OSF for Drupal connector: the OSF FieldStorage module. What this module does is to create a new FieldStorage type for Drupal7. It enables Drupal7 to save the values of its Content Types fields into another storage system than the default one (i.e MySQL in most of the cases).

Because of the way that the Field system has been designed in Drupal7, it is possible to save the values of different fields that compose the same Content Type bundle into different field storage system. For example, if your Content Type bundle is composed of 10 fields, then 4 of them could be saved into MySQL and 6 of them into OSF.

The main purpose of the OSF FieldStorage module is to be able to save Drupal local Content Type information into OSF. What that means is that all your Drupal7 local content then become accessible, manageable and manipulatable using the 27 Open Semantic Framework (OSF) web services endpoints. Your local Drupal content can then be shared with other Drupal instances that could use OSF for Drupal to connect to that same OSF instance and seamlessly republish/re-purpose that local content from the other Drupal portal.

Here is the documentation of the architecture of this connector module.

This is the power of the OSF FieldStorage connector module. It supports the following Drupal features:

  1. Full FieldStorage API
  2. Entities caching
  3. Revisioning
  4. SearchAPI
  5. 29 field widgets
  6. Export feature in 6 formats

In this screencast, you will be introduced to Drupal7′s Field system. Then you will see how the OSF FieldStorage module creates a new FieldStorage type for Drupal7 and how it can be used. Then you will see how to configure the OSF FieldStorage module: to creating new Content Type fields that uses this osf_fieldstorage type, how to map these fields to RDF, how to use one of the 29 supported field widgets, etc.

Finally, you will see how you can synchronize existing Content Type pages (that was created before OSF for Drupal was installed on your Drupal instance) into a OSF instance.

 



Categories: Drupal

Drupalize.Me: Hiding form fields in Drupal 8

18 April 2014 - 6:00am

If you have worked with the Field UI in Drupal 7 you will know that you are able to prevent fields from being displayed when viewing entities (e.g. content, users etc). It was fairly simple, you would go to the Manage Display tab of an entity and move the field to the ‘Hidden’ region as shown in the screenshot below.

So you could hide a fields output from being displayed when viewing that entity. But what about when editing that entity? There was no way in the Drupal 7 Field UI to hide a field on a form. You would have to write some form of hook_form_alter() in a custom module and manually force the field to be hidden, like shown in this example.

Categories: Drupal

InternetDevels: Drupal and high-load projects. Myth or reality?

18 April 2014 - 5:03am

One of spring days 2012 brought us a new project. One of our regular customers recommended our company to a very ambitious and engaged Moscow businessman. After reading the specifications we were at a loss… after 5 years of active web-development! HiConversion project demanded the following:

Read more
Categories: Drupal

.VDMi/Blog: Paragraphs: content editing reinvented

18 April 2014 - 12:50am
The biggest problem of the modern web is that non-tech-savvy users have to manage the content. Those people can quite mess up your responsive layout with their way too big tables, inline images and text marked up with Word. That's why we invented Paragraphs, less to mess up, but still the flexibility of WYSIWYG.

Let's face it, the web has evolved. But what about content editors? Dit they evolve with the web?

Most of them still like to paste everything they can find into a big WYSIWYG texarea. That's not a viable option when you want to build responsive website. It gets even hard when you want to use cool technologies like responsive images. Wouldn't it be awesome if you had all those pictures in image fields, or maybe even better, in Scald? Behold: Paragraphs!

We developed Paragraphs to be a full blown replacement of the default body field. It's comparable with Inline Entity Form, except that you can use different types of bundles in the same field. It also comes with content editing features like having your paragraphs collapsed by default. More features are on the way!

Some examples of Paragraph Bundles that we have created in the past:

  • Slideshow - A simple slideshow in your content:
    - Create a slideshow Paragraph bundle.
    - Add a multi-value image field.
    - Use a slideshow formatter.
  • Youtube embed - A Youtube embed between your text blocks:
    - Create a Youtube Paragraph bundle.
    - Add a simple embed field. 
    - Tweak the formatter settings to fit your needs.
  • Customer Quote - Add a personal quote/review from your customer in your content:
    - Add a author, text and optional email field.
    - Theme it to your style, with bundles-specific templates.

The bundles above are use-case-specific, we often start with the following bundles:

  • Text: a simple WYSIWYG textfield with the basis buttons enabled, like bold and italic.
  • Text Left, Image Right: same as above, but with an image on the right of the text.
  • Text Right, Image Left: same as above, but with the image on the left.
  • Fullwidth image: an image that takes the full width of the content.

All paragraph bundles have their own display settings and view modes, just like nodes! Because of that, every paragraph item also has it's own theme suggestion.

Because of the seperation of content, it's great for a responsive site. For example: Just add a wrapper around your slider paragraphs that hides the slider on mobile, or makes it smaller on tablets.

Excited already? Try it out!
Want to know more? Check the project page.

Note: Paragraphs is also useful if you want to build a Drupal site with Parallax scrolling. More on that later!

Categories: Drupal

NYC Camp News & Announcements: NYC Camp Keynote by Atefeh Riazi (UN CITO, ASG)

17 April 2014 - 3:37pm

Last Saturday afternoon, we were very fortunate to have Atefeh Riazi, UN CITO and Assistant Secretary General (ASG), deliver a keynote presentation to the 500+ Drupalists in attendance.

Salem Avan delivered the introduction to the keynote, and spoke about "we the people" and our inherited collective responsibility to help advance the UN's goals of furthering peace and security, international development, and human rights.

Ms. Riazi then delivered a riveting keynote that was a call to action for the Drupal community to help use technology to better the world. She emphasized the importance of leveraging innovation, collaboration and partnerships in order to solve the global challenges we face, and to respond to this call to action in a coordinated manner through partnerships that bring all of our best resources to bear.

Her exciting keynote address was followed-up with a stirring panel on  Women & Technology Leadership, that featured Mr. Riazi, Holly Ross (Executive Director or the Drupal Association), and Angie Byron (webchick). The panelist explored the pivotal importance of furthering female leadership is technology circles, and particularly the Drupal community. 

You can watch the full keynote here on UN WebTV.

You can also view the Flickr photo album from the Keynote here and the Panel Discussion here

Thanks again to the UN Office of Information Communications Technology (OICT) for their generous support of NYC Camp and the Drupal NYC Community. You can find our more about the UN OICT at their websiteFacebook page and by following them on Twitter.

Categories: Drupal

Drupal.org Featured Case Studies: The Woodhouse Day Spa

17 April 2014 - 3:28pm
Completed Drupal site or project URL: http://www.woodhousespas.com

Unleashed Technologies developed an enterprise platform that easily scales to accommodate The Woodhouse Day Spa’s explosive growth, as they take the company from 30 to more than 200 franchises. The Woodhouse Day Spa can now instantly create franchise sites that are consistent in branding and content, yet managed and updated by the franchisee. All sites for The Woodhouse Day Spa are fully integrated into spa management systems to provide a seamless experience to visitors. The Drupal platform developed for The Woodhouse Day Spa brings usability and control to its franchisees in order to increase engagement and improve ROI.

The Woodhouse Day Spa website won the 2013 Blue Drop Award for Drupal Site of the Year.

Key modules/theme/distribution used: Drupal services JSField PermissionsTaxonomy Access ControlUbercartFeaturesUltimate CronViews Bulk Operations (D8)Nodequeue
Categories: Drupal

Drupal Association News: Drupal Association Board Meeting Summary: 16 April, 2014

17 April 2014 - 1:31pm

Preparing the materials for the monthly board meeting is a lot of work, but it's a great chance to reflect each month on the momentum of the Association and the community. Looking back, March 2014 was particularly exciting as the community and staff are pushing forward in several directions at once with considerable momentum. So let's get down to it and share some of the highlights:

Program Updates

Each month we review the metrics outlined in our 2014 Leadership Plan and share updates from the teams. We're pleased to say that most of our metrics are in the green (within 95% of goal). Particularly exciting is the news about DrupalCon Austin. Numbers looked very solid at the end of March (the end of our reporting period for this meeting), but we are also able to share that early-bird pricing ended just a few days after this dashboard closed and we beat our estimates, meaning that we are more than on-track to have a 4,000 person event this June - another biggest DrupalCon ever!

We are also really pleased with the momentum around the Drupal.org metrics. This is still our area of greatest concern - we have more red metrics here than anywhere else. However, March brought some tremendous gains that, if sustained, will move our metrics quickly towards green. In particular, we focused discussion on:

  • Page Response Time: Our goal is 3.07 seconds. Our current average for the year is 3.93 seconds. Part of the reason that we're so far from goal is that we had some serious issues in January that pushed the numbers way up. Our hardware improvments (thanks to the DIWG and Rudy) have helped speed this up, and the upcoming CDN deployment will bring this number down even further, especially for individuals accessing the site outside of the US. 
  • Testbot performance: Goal is 70 minutes, but actual average for the year is about 138 minutes. This actual is also very inflated by lots of issues we had in January that pushed the total testbot time much higher. Thanks to work done at Drupal Dev Days in Szeged by Jeremy Thorson and Ricardo Amaro, along with some changes to D8 core, the actual tesbot run time average in March was just 47 minutes!
  • Home Page Bounce Rate: This metric is one of the central motivations for the User Research that the DCWG has begun as part of a larger Drupal.org reinvention. We have also begun to put tools like Optimizely in place that will allow us to run tests and experiments based on our research, which should help us address bounce rate, time on site, and other engagement metrics for our various audiences. We likely won's see shifts here for some months, but we are definitely thinking about these metrics and working to put the foundation for a solution in place. 
Procurement Policy

At the Association, we work hard to ensure that our actions are in line with the Drupal community values. This is, of course, particularly important when money is part of the equation. To that end, the Association has a Financial Policies document that is reviewed annually by the board Finance Committee and sets rules for transparently and openly making decisions for how Association money gets spent. Until now, one element that was lacking was a Procurement Policy to govern when we pay for a service (vs. work with a volunteer) and how and when we can take in-kind donations. Back in February, we looked for feedback from the community, and incorporated a lot of the suggestions into a final policy, which was approved by the board in the meeting. 

I would like to add that this policy, though approved by the board, is just a starting place. There is so much nuance that we will encounter as we put the policy into practice. During our annual review of policies, we will have the opportunity to revisit and refine this language. In particular, we want to ensure that we are supporting and growing the volunteers who contribute to the project and not hiring contractors at the expense of the health of our community.

At-Large Elections/Terms

In the March Board meeting, we updated At-Large term length and shifted the election cycle. The goal is to give our At-Large Directors a better board experience by giving them time to integrate into the board and really work on their agendas. With this change, the community will elect one At-Large Director each year to a two-year term. For this to work, we need to stagger the terms of our existing At-Large Directors, Morten DK and Matthew Saunders. Since Morten is serving his second one-year term currently, the board voted in this meeting to extend the terms of Matthew Saunders 1 year. So, in our next election (in February 2015), we will elect a new At-Large Director to fill Morten's seat for two years and Matthew will have one year left in his term.

First Quarter Financials and Annual Audit

In Executive Session, the board reivewed the financials for the first quarter of 2014 and received a presentation of the 2013 Audit report from the Association's auditor. All materials were previously reviewed by the Finance Committee (which meets monthly to review the most recent financial reports), and the Finance Committee recommended approving both the fiancials and the audit. The audit documents are now being produced as final versions (we presented draft documents to the board) and will be shared with the community at the June public board meeting at DrupalCon Austin. If you're ready to dive into some numbers before then, you can review the first quarter financials now:

Lots more happened at this board meeting, and if you're interested, don't forget that you can read the minutes, or watch the recording. And as always, let me know if you have questions.

Flickr photo: xjm

Categories: Drupal


about seo