Feeds from Drupal.org

Subscribe to Feeds from Drupal.org feed
Drupal.org - aggregated feeds
Updated: 57 min ago

Appnovation Technologies: Simple Website Approach Using a Headless CMS: Part 1

Wed, 2019-02-06 08:00
Simple Website Approach Using a Headless CMS: Part 1 I strongly believe that the path for innovation requires a mix of experimentation, sweat, and failure. Without experimenting with new solutions, new technologies, new tools, we are limiting our ability to improve, arresting our potential to be better, to be faster, and sadly ensuring that we stay rooted in systems, processes and...
Categories: Straight From Drupal

erdfisch: Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Sat, 2018-05-12 09:00
Drupalcon mentored core sprint - part 2 - your experience as a sprinter 12.05.2018 Michael Lenahan Body:  Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Hello! You've arrived at part 2 of a series of 3 blog posts about the Mentored Core Sprint, which traditionally takes place every Friday at Drupalcon.

If you haven't already, please go back and read part 1.

Drupalcon Mentored Core Sprint Room

You may think sprinting is not for you ...

So, you may be the kind of person who usually stays away from the Sprint Room at Drupal events. We understand. You would like to find something to work on, but when you step in the room, you get the feeling you're interrupting something really important that you don't understand.

It's okay. We've all been there.

That's why the Drupal Community invented the Mentored Core Sprint. If you stay for this sprint day, you will be among friends. You can ask any question you like. The venue is packed with people who want to make it a useful experience for you.

Come as you are

All you need in order to take part in the first-time mentored sprint are two things:

  • Your self, a human who is interested in Drupal
  • Your laptop

To get productive, your laptop needs a local installation of Drupal. Don't have one yet? Well, it's your lucky day because you can your Windows or Mac laptop set up at the first-time setup workshop!

Need a local Drupal installation? Come to the first-time setup workshop

Fatima's tweet - first time setup room

After about half an hour, your laptop is now ready, and you can go to the sprint room to work on Drupal Core issues ...

You do not need to be a coder ...

You do not need to be a coder to work on Drupal Core. Let's say, you're a project manager. You have skills in clarifying issues, deciding what needs to be done next, managing developers, and herding cats. You're great at taking large problems and breaking them down into smaller problems that designers or developers can solve. This is what you do all day when you're at work.

Well, that's also what happens here at the Major Issue Triage table!

Major Issue Triage

But - you could just as easily join any other table, because your skills will be needed there, as well!

Never Drupal alone

At this sprint, no-one works on their own. You work collaboratively in a small group (maybe 3-4 people). So, if you don't have coding or design skills, you will have someone alongside you who does, just like at work.

Collaborating together, you will learn how the Drupal issue queue works. You will, most likely, not fix any large issues during the sprint.

Learn the process of contributing

Instead, you will learn the process of contributing to Drupal. You will learn how to use the issue queue so you can stay in touch with the friends you made today, so that you fix the issue over the coming weeks after Drupalcon.

It's never too late

Even if you've been in the Drupal community for over a decade, just come along. Jump in. You'll enjoy it.

Mark Hope's tweet - never too late

A very welcoming place to start contributing is to work on Drupal documentation. This is how I made my first contribution, at Drupalcon London in 2011. In Vienna, this table was mentored by Amber Matz from Drupalize.Me.

Documentation table

This is one of the most experienced mentors, Valery Lourie (valthebald). We'll meet him again in part 3, when we come to the Drupalcon Vienna live commit.


Here's Dries. He comes along and walks around, no one takes any notice because they are too engaged and too busy. And so he gets to talk to people without being interrupted.

Dries Buytaert

This is what Drupal is about. It's not about the code. It's about the people.

Cathy and Tim

Next time. Just come. As a sprinter or a mentor. EVERYONE is welcome, we mean that.

This is a three-part blog post series:
Part one is here
You've just finished reading part two
Part three is coming soon

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categories: Straight From Drupal

KnackForge: How to update Drupal 8 core?

Sat, 2018-03-24 05:01
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categories: Straight From Drupal

James Oakley: Drupal Security: Forewarned is Forearmed

3 hours 48 min ago

Yesterday, at 7.13pm, the Drupal Security Team issued a public service announcement: Drupal 7 and 8 core highly critical release on March 28th, 2018 PSA-2018-001.

This needs a bit of background to understand.

How Drupal Core Updates Normally Work

Updates to Drupal Core fall into one of new kinds.

Blog Category: Drupal Planet
Categories: Straight From Drupal

Deeson: How to create a custom field to use on an entity in Drupal 8

4 hours 16 min ago
Drupal 8 logo close up

On a recent project I wanted to be able to create a custom field which would automatically be added to certain types of entities. I thought that this would be a straightforward thing to do.

When I searched the internet for how to create custom fields I found plenty of documentation on Drupal.org and other blog posts about creating custom fields that you can add to any type of entity, but I couldn’t find out how to actually add the field directly to an entity (like the URL alias field).

Creating a custom field.

So first off, how do you create a custom field? Drupal.org documentation is a great place to start.

You need to create a FieldType plugin, a FieldFormatter plugin and a FieldWidget plugin in a custom module. Combined, these define your field, how it will be rendered when displayed, and what settings a user can set on it when adding it to an entity.

The directory structure of a module that implements all three looks like this:


  • my_custom_fields.info.yml
  • src/
    • Plugin/
      • Field/
        • FieldType/
          • MyCustomFieldItem.php
        • FieldFormatter/
          • MyCustomFieldFormatter.php
        • FieldWidget/
          • MyCustomFieldWidget.php

I would recommend reading the documentation about these as there are some great examples as to how they can be defined.

Adding your field to an entity.

So having now defined your own field, you should be able to see if in the list of fields that you can add to an entity.

Great, you think, I've done it! Well, if all you wanted to do was to create a field that you could add to any type of entity if you choose to … then yes, that's all you need.

However, I wanted to automatically add my custom field to an entity when my module was enabled. This was because I wanted there to only be one instance of my field on an entity, so there was no need to be able to add it manually (a bit like the URL alias field).

Automatically adding your field to an entity. If you want to be able to add a field directly to an entity, you need to use hook_entity_base_field_info for this. For example: use Drupal\Core\Field\BaseFieldDefinition; /** * Implements hook_entity_base_field_info(). */ function my_module_entity_base_field_info(EntityTypeInterface $entity_type) { if ($entity_type->id() === 'taxonomy_term' || $entity_type->id() === 'node') { $fields['my_custom_field'] = BaseFieldDefinition::create('my_custom_field') ->setLabel(t('The custom field)) ->setDisplayConfigurable('form', TRUE) ->setDisplayConfigurable('view', TRUE); return $fields; } }

You'll notice in the above example that this uses the BaseFieldDefinition class to create a new base field only on taxonomy or node entities. More information on this hook and the BaseFieldDefinition class can be found in the Drupal.org documentation.

So now we can add our custom field to specific entity types - amazing! At this point I thought I'd cracked it. Having cleared my cache I checked my entity and there was my custom field with the widget showing as I'd expected. But when I came to save my entity, the save failed with this big exception:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The “my_custom_field” plugin does not exist. In Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php)

Having had a play about to see what was causing this, it seemed that because I had specified to create a base field of ‘my_custom_field’, Drupal didn’t understand what this field was.

There are lots of defined field types already with Drupal but, as I'd created my own, Drupal didn’t know about it.

So I set about trying to understand how to define my own field type.

I got nowhere at first so I turned back to Drupal core and started delving into the base field definitions to try and understand how these have been defined.

What I found was that I need to create a DataType class which defines my custom field. This class needs to be located within the Plugin directory of your module, for example:


  • my_custom_fields.info.yml
  • src/
    • Plugin/
      • DataType/
        • MyCustomField.php
The content of MyCustomField.php will then look something like this: namespace Drupal\my_custom_fields\Plugin\DataType; use Drupal\Core\TypedData\Plugin\DataType\StringData; use Drupal\Core\TypedData\Type\StringInterface; /** * The MyCustomField data type. * * The plain value of a MyCustomField for an entity. * * @DataType( * id = "my_custom_field", * label = @Translation("My Custom Field") * ) */ class MyCustomField extends StringData implements StringInterface { }

This new DataType class extends the StringData class as I am just storing a string. If you wanted to store a boolean or integer then you would need to extend the relevant DataType base class to make use of all the goodness that they set. If you want to override any of the methods on these classes then you can as normal.

So now Drupal understands what my base field of ‘my_custom_field’ is.

But wait - we're not quite finished yet… Although the entity will “save”, you will notice that no data is actually saved for my new field yet. This is because we haven’t defined the storage for it.

There are several ways in which you could handle this. You could define your own database table and then write to this as part of the preSave method on the FieldBase item.

The easier way is to define your own config entity which will add additional columns to your entity table to store your custom data against. To do this, you just need to create a schema.yml file in your module, for example:

  • my_custom_fields
    • config/
      • schema/
        • mycustomfields.schema.yml

The contents of this file just define your field:

# Schema for the configuration files of the MyCustomFields module. field.value.my_custom_field: type: mapping label: 'Default value' mapping: value: type: string label: 'MyCustomFields'

You'll need to disable your module and enable it again for the new config entity to used, but there you have it: a step by step guide to creating a custom field to use on an entity in Drupal 8.

Categories: Straight From Drupal

Eelke Blok: DrupalCamp Ruhr Talk: Drupal 8 Configuration Management

5 hours 16 min ago

Last weekend, the DrupalCamp Ruhr was held in Essen, Germany. I was fortunate enough to have been selected as a speaker. I've now made the slides available online.

Categories: Straight From Drupal

MidCamp - Midwest Drupal Camp: MidCamp Reaction Roundup

11 hours 24 min ago
MidCamp Reaction Roundup

Folks have made it home and collected their thoughts on this year's MidCamp. Here's a list of some of them. If you've made words and you're not on the list, please tweet or slack them to us!

Categories: Straight From Drupal

Lullabot: Not Everything is a User Story

Wed, 2018-03-21 18:32

At Lullabot, we’ve been using Agile techniques for years to help run our software projects. We’ve learned what pieces of Scrum and Kanban seem to fit our teams and what parts are safe to ignore. We’ve learned not just how different Agile methodologies prescribe we should work, but we’ve uncovered what’s actually helpful to us. In other words, we have opinions.

One of those opinions really crystallized among our project managers over the last 12 months, and we want to share it with you. It has to do with the way we think and communicate about the work that our teams do.

User stories

Most of us in the software industry have encountered the idea of user stories. These minimalist requirement statements have been around for two decades, and are one of the fundamental ideas in Agile software development. As such, there’s been a lot of thinking and discussion around them.

Rather than being some definitive statement on user stories, this article is a reflection of the experience of working with this kind of artifact within the specific context of our clients, developers, and project managers here at Lullabot.

A user story is supposed to be a short statement about a task a user wants to do with a particular software. It briefly describes the user, the task, and what benefit the user gets from it.

On typical format of a user story looks like this:

As a <type of user> I want to <do something> so that I can <benefit>.

A more concrete example would be:

As a Night Owl, I want to drink multiple cups of coffee in the morning so that I can be even slightly functional before noon.


As a visitor to this website, I want to easily search for content so that I can find what I’m looking for quickly.

The brevity of this format is helpful to force people to have actual conversations about the feature they’re building. Once upon a time, development teams and business stakeholders needed to be encouraged to collaborate more, so this was a revolutionary tool.

So, obviously, this is a good idea. But In the course of the last year, we talked about user stories a lot and how they can help or hurt a development project.

Is everything really a story?

Stories are such an operating assumption that many of the software packages that help organize development projects start with ‘Story’ as a default issue type. They’re so normalized in modern software that we’ve even had clients direct us that “everything needs to be a story” in their projects.

Explicitly or implicitly, there’s an idea out there that since we’re Agile (whatever that really means), we have to do user stories for everything. I’ve found myself writing 'As a user' stories uncritically, out of habit, or because I was instructed to do so.

However, there’s often business-driven or system-level requirements, which are not user-focused at all, that have to be crammed into the user story format. It’s easy to apply the user story format to everything, for the sake of consistency, but it’s a bad fit in several common cases. Here’s an example of a technical requirement stuffed into a user story:

As the system, I want to verify a user's OAuth credentials before granting access so that I can ensure secure connections.

I’ve seen and written lots of stories like that. The problem is that this story personifies the system with wants and desires which it does not have. If it were truly a user story, the user would be the focus like in this example:

As an amateur chef, I want to log into the system because I want to access recipes behind the paywall.

You’ll note that the whole character of the story has changed. Security and technology standards are not the primary concern of the user, so they aren't reflected. It doesn't reflect the business requirement of HOW the authentication should happen, but then again the user doesn't care about that. It’s honest but less than effective as a requirement.

As a user, I want you to take my money

This is also a problem for business requirements that are not actually user-focused. They are similarly ill-suited to the user-story format:

As a site visitor, I want to see advertisements so I can know about products and services that might interest me.

We know that no user ever wanted that. They came to the website for the content, and the advertising was a distraction. So that user story is fundamentally NOT about the site visitor—it’s about the revenue model of the site.

User stories function as conversation starters about the value of a piece of work and the ways in which that value might be realized. Our examples above don’t need conversation or discussion. The imperative and authority to do the work come from the organization’s need to provide security or earn revenue.

So how do you express non-user requirements?

In general, it’s better to surrender to common sense and not put these kinds of technical requirements into the user’s voice. Instead, write simple, imperative statements that declare what must be done.

Integrate Google AdSense into article pages.
Require a valid OAuth token for access to the system.

We like to surrender to the forces of common sense and call a user story that no longer involves a user what it actually is: a task for a developer to perform.

This might seem like a meaningless distinction—who cares if it’s a story or a task or whatever? But if your mental model of the user is demonstrably false, what else are you getting wrong?

It’s easy to write your biases into the user’s voice and finding yourself keeping the status quo instead of doing something new. If you insist on shaping the conversation around your product from a false premise, how can you spot your real business problems and innovate to solve them?  

To take our example from above, maybe traditional web advertising is a sub-standard way of generating revenue for your business, but you’ll never have that conversation if you paint it over with false user requirements and benefit statements.

What are user stories actually good at?

The beginning of our process is a well-written, truthful story about a feature with benefits for specific kinds of users, accompanied by clear acceptance criteria.

Ideally, we’re starting from a position where there’s been actual user research and one-on-one interviews during the discovery process. That ensures we’re building features that users are actually interested in.

As a content administrator, I want to be notified of new user account requests because I need to review and approve them quickly.
As an authenticated user, I want to drill into search results using facets because I’m looking for something very specific.
As a vacation planner, I want to visit a page that aggregates content about my country of interest, to help me decide what I might like to do while in that country.

The conversation around actual user-based stories builds understanding between the business and our development team, and it sets us on the right path. It just needs to be recognized that the user story format itself isn't magic.

The life-cycle of a story

It’s natural that stories would be initiated by the business stakeholders based on their knowledge of their users. In the same way, when the developers are done with their work, those same stakeholders will want to verify that the story is properly complete.

That makes stories an ideal artifact to drive QA and acceptance testing. Developers and QA team members both benefit from business-level acceptance criteria elaborating the story to help guide their work.

We like to use Gherkin as a way to write acceptance criteria using a particular format consisting of ‘Given, When, Then’ statements.

  • Given expresses the preconditions of the acceptance criteria. This might be authentication, the existence of some data, or the completion of a business step that must precede the feature under discussion.
  • When expresses the action a user takes.
  • Then expresses the result of the action.

All three of these keywords can be combined with conjunctions like ‘and’ or ‘but’ to layer conditions onto the acceptance criteria. Here’s a simple example:

Given a user has requested an account in the system,
and the account request has been reviewed by an admin,
and the admin wishes to approve the request.
When the admin approves the request,
then the account changes state from ‘pending’ to ‘active,’
and the user is notified by email that their account request has been approved. 

This kind of acceptance criteria is great to work up as the story is being discussed, where developers can ask questions of business stakeholders. Gherkin is actually used in software like Cucumber and Behat to drive automation of these test criteria.

Not every client is interested in this kind of test automation, but even if those tests will never end up in code, working with Gherkin to write acceptance criteria has a way of clarifying everyone’s thinking.

When the conversation is done

The story and the acceptance criteria are really valuable for everyone involved. But, when you’ve reached a stopping point and the story is ‘ready for development,’ there’s still more that has to happen. Even with great acceptance criteria, the story still might not express the level of detail that a developer needs.

Beyond the story and acceptance criteria, developers may rely on technical documentation, design artifacts, or architectural planning to fill in the gaps. This is especially true when a story is a single unit of value to the business, but the implementation crosses disciplines and teams.

Stories for everyone, subtasks for developers

It’s helpful at that point to break the story into subtasks which can be assigned and sized for an optimal developer workflow — bite-sized chunks that take no more than 1-2 days to accomplish, and which are often unit testable but aren't always good candidates for QA.

Our account approval example from above can be broken into several tasks. Most of these features are off-the-shelf with Drupal, but we’d probably want to make some adjustments and customize the language in the notification emails.

Again, our task format is short imperative statements, possibly with additional notes as needed in the body of a ticket.

Grant permission to site admins to allow account approvals.
Build a list of open account requests.
Customize account approval emails.

You may or may not need distinct acceptance criteria here. Some tasks are self-explanatory, while others have the need for more guidance as we describe above.

In any case, QAing these shorter tasks can be cumbersome and confusing for the QA team because the total work for that story is not sufficiently complete. Any single task is only part of the full acceptance criteria, and they’re often interdependent.

However, we’re not without validation for those subtasks. Unit testing and peer review between developers work very well for checking them along the way, especially when we write custom code where errors might be introduced. When all the tasks are done, the complete story can move forward to QA and acceptance testing for the complete feature.

All of this is to say that user stories are an important part of Lullabot’s software development process—but they’re not the only thing we need to get the job done.  

Get more background

I like to know the background and history of these techniques we use to manage our projects. The user stories and Agile development practices have been around for about 25 years, but it sits in the context of the whole history of software. Knowing the history and the thinkers behind it all set you up to use the practices selectively and use them well.

In that light, and to give credit where credit is due, these are some of the folks that did the big thinking around user stories and other Agile practices. If you’re a practitioner of Agile in some way, check out their history and opinions:

And, here a couple of books that have been helpful:

Categories: Straight From Drupal

Nextide Blog: Intelligent Work Automation

Wed, 2018-03-21 18:04

In my last post “Untapped Areas for Business Improvements” I attempted to point out the various areas where the potential exists for significant returns for your business through intelligent work automation. As well, time was given to examine some of the more obvious impediments as to why so little is done in this area.

I would like to take the discussion to the next level in reviewing the potential for rewards. No one is going to make intelligent work automation a priority unless there is some ‘gold’ to be discovered. The key to this is centered on employee productivity. And while I will dedicate most of this article to the rewards, we also need to look at what is at stake by ignoring these suggestions and doing nothing.

Categories: Straight From Drupal

CTI Digital: Drupal Europe 2018 - show your support and buy tickets now!

Wed, 2018-03-21 16:41
drupalcamp europe

Drupal Europe promises to be the most significant community lead conference in the history of Drupal on the continent. Redefining and reinvigorating what a major Drupal conference means to the community, business users and agency leaders Drupal Europe promises to be an exciting and rewarding experience.

Categories: Straight From Drupal

Matt Grasmick: A New Documentation Initiative

Wed, 2018-03-21 16:14

I recently performed an experiment in which I attempted to emulate the experience of a Drupal evaluator. I highlighted a few glaring pain points and shared my experience and conclusions in a blog post: Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks.

That post sparked a tremendous degree of engagement. Many people commented, wrote responses on their own blogs, and voiced support on twitter. I was pleasantly surprised by the Drupal community's response, which was (nearly) uniform and highly corroborative. The jury is in. Drupal's evaluator experience is fraught.

A few notable long-form responses include:

Categories: Straight From Drupal

InternetDevels: A collection of free Bootstrap-based themes for Drupal 8

Wed, 2018-03-21 15:25
A collection of free Bootstrap-based themes for Drupal 8

What should a dream theme for a Drupal 8 website be like? Responsive, modern-looking, highly customizable, rich in powerful features, and intuitively understandable, perhaps? Many developers would say a dream theme is based on the Bootstrap framework.

Read more
Categories: Straight From Drupal

Chromatic: Using `composer outdated` to Manage Drupal Dependencies

Wed, 2018-03-21 13:00

Managing Drupal sites with composer brings a number of benefits. However, when installing Drupal dependencies from source (an option offered by composer), you also lose the functionality provided by Drupal core’s “Available Updates” page. Thankfully Composer will allow you to keep tabs on the available updates for all of your project’s dependencies, including Drupal core/contrib.

Categories: Straight From Drupal

Manifesto: Write once, chat anywhere: the easy way to create chatbots with Drupal

Tue, 2018-03-20 17:08
Historically, we have many ways of serving content digitally: through a website, through mobile apps, via social media, RSS feeds, RESTful APIs (allowing content to be consumed by other apps, websites etc), and email. Now we have a new player in the game: chatbots and personal assistants. Conversational interfaces promise a more natural way for. Continue reading...
Categories: Straight From Drupal

Dries Buytaert: Responsive accessible HTML tables

Tue, 2018-03-20 16:56

A very thorough explanation of how to build responsive accessible HTML tables. I'd love to compare this with Drupal's out-of-the-box approach to evaluate how we are doing.

Categories: Straight From Drupal

Drop Guard: How updating a Critical Drupal update costed a Drupal agency 1,750.00€ minimum

Tue, 2018-03-20 16:30
How updating a Critical Drupal update costed a Drupal agency 1,750.00€ minimum This article is meant to be a further step to raise agencies’ and also customers’ awareness of the huge expenses when it comes to update management in Drupal.

It’s not about promoting a single solution or product. It’s about getting more sensitive for processes which could or should be way smarter and efficient than they are in most companies right now. It’s about creating processes which are ressource friendly, customer focused and support automation.


Drupal Business Automation Drupal Planet
Categories: Straight From Drupal

Aten Design Group: A Tool for Estimating College Tuition

Tue, 2018-03-20 15:50

Every generation is a little different. They bring different beliefs and perspectives tied to their upbringing. Generation Z, those born in 1995 or later, have been brought up in a world where information is at their fingertips. They are digitally connected through laptops, tablets and smartphones. If they have a question, all they have to do is pull out a device and ask Siri, Google or Alexa. They have a drive for getting information, learning new things and making an impact.

Gen Z students interested in Stanford are no different. We've often heard Stanford describe their students as adventurous, highly motivated, and passionate in their desire to come together and deepen their learning. During their time at Stanford, they will discover what motivates them and how they can impact the world after graduation. This is true of full-time Stanford students, as well as visiting students participating in the Summer Session. Stanford’s Summer Session provides current Stanford students, high schoolers and students at other universities with the unique opportunity to complete a summer at Stanford – getting a full experience of the coursework and college life Stanford offers.

The program isn’t cheap, and not every student can afford it.

We recently worked with the Stanford Summer Session communications team to combine the high school and college level websites into one site with a fresh design and structure. We kicked off the project with a discovery phase that included user surveys and stakeholder interviews.

The Problem Image 1 Stanford Summer Session tuition table before the redesign The old tuition tables from Stanford Summer Session. Students had to navigate the fees and add all the relevant fees up on their own.

As we learned from the user surveys, students are cost-aware individuals, just like Gen Zers all over the nation. Corey Seemiller and Meghan Grace in Generation Z Goes to College couldn’t have put it any better: “Anxiety over being able to afford a college education is forefront on the minds of these students.” Prospective Summer Session students were specifically looking for ways to make the program fit within their budget. This message was amplified by the interviews we conducted with the Summer Session staff, who noted that tuition information was buried, and in some cases, scattered throughout the site.

Through more discussion with stakeholders and students, we learned that students struggled with deciphering the available tuition and fee tables, inhibiting them from learning how much the program would cost (see Image 1). Additionally, as fees and tuition changed every year, staff found it painful and time-consuming to update information in the old system.

The Solution

So what did we do to help these students out? We created a one-stop-shop to get an estimate of the cost – welcome the tuition and fees calculator. By answering a few simple questions, students can get a true estimate of the total cost for their summer at Stanford. If they’re not happy with the results, they can tweak their answers to help make the program fit their budget.

As an added bonus, the system makes it really easy for staff to update the costs each year! On the admin side, each question and list of answers are fully editable. The dollar amounts can be changed for each student type to ensure the estimate will stay accurate for each coming school year. On the front end, the questions are organized, options are shown or hidden depending on previous answers, and the total amount is tallied on the final screen. Vue.js allowed us to build a complex interface simply, while making the static data more engaging.

How We Got There

Hopefully you’re in love with the solution we came up with, and maybe you’re wondering how we got here. Well, you already know we did some research – surveyed current students and interviewed staff – to learn about the problems they were facing. We then brought our two teams together to brainstorm ideas using the Core Model exercise.

Core Model worksheet for the tuition calculator

We took a few minutes to sketch out the proposed solution.

Sketches of the tuition calculator

These ideas were then further refined in wireframes and design:

Wireframes for the Stanford Summer Session Tuition and Fees Calculator Design Comps for the Stanford Summer Session Tuition and Fees Calculator

And finally developed in Drupal 8.

The tuition and fees calculator was designed to provide Gen Zs with the information they need to financially plan their summer at Stanford, but all generations can benefit from it. Since launch in November 2017, the calculator has appeared in the top 10 visited pages of the redesigned site, with an average of 3000 pageviews per month.

Categories: Straight From Drupal

Drupal Association blog: 2017 Q3 & Q4 Financials

Tue, 2018-03-20 15:48

The Drupal Association Board is responsible for the Drupal Association’s financial health and as part of their duty, they vote to approve monthly financial statements. The board met virtually on February 27th, 2018 and voted to approve the Q3 & Q4 2017 financial statements.

Each month we compare our results against the two financial KPIs that we measure against:

  • Cash Reserve: have a cash balance of 15-30% of Total Revenue
  • Net Income Profit Margin: end 2017 with a net income profit of 10%

These two goals focus on increasing Net Income in order to build a stronger cash reserve.

Below is a summary of how we performed in the third and fourth quarters of 2017 against our KPIs. As you look at this chart, you can see that we improved on our KPI month over-month.

Prior to the start of the year, we stated that if we could achieve a 10% Net Income this would move us to the minimum percentage (10%-30%) of the cash reserve. As we move month-over-month, you can see the cash reserve build as our net income percentage increases. December has us land at a Net Income percentage of 16%, and our “money in the bank” was 11%, or $570K (not including restricted cash).



Cash Balance (including Restricted Cash)


Net Income


Cash Reserve %


Net Income Percent


Cash Balance (excluding Restricted Cash)


Cash Reserve %


Monthly Highlights

The month of July saw us move closer to our cash reserve KPI. We ended the month within 80% of that goal. As we moved closer to DrupalCon Vienna, we saw cash reserves drop because we paid expenses towards the conference. The net income goal outperformed the cash forecast due to fundraising revenue being $31k higher and membership sales coming in $11k more than forecasted. The costs for July tracked to forecast, with a small amount of trailing costs (about 4k) from DrupalCon Baltimore, and bank fees being $5k lower than forecasted.

August had supporter sales and digital sponsorships down $30k from the forecast, however this was offset by an unforecasted time and materials project for $25k. Operating expenses for DrupalCon, along with overall administration costs, stayed in line with the forecast.

September’s focus was DrupalCon Vienna. Overall, net income significantly exceeded expectations for September because of much lower than expected costs for Vienna, and a boost of an additional $46k in revenue. This increase in revenue was mostly due to fundraising ($20k over forecast) and other programs ($26k over forecast). We do expect a significant amount of trailing costs in October for Vienna that will impact the net income in the upcoming months.

Activity for October saw some trailing costs for DrupalCon Vienna, and a clear picture on how DrupalCon Vienna closed out. We were below the forecasted loss of $267k, however the trend towards a loss. Some revenue help was in trailing ticket sales and sponsorship sales, which did beat the forecast. The events team did a great job containing costs, and maximizing savings in catering, supplies and our print signage for approximately $71k of savings in those budgets. Additionally, we were able to reclaim $32k of VAT through deductions on tax returns. This moved the anticipated net margin loss from -31% to -22% on this event.

November saw trailing costs from DrupalCon Vienna, which increased the forecasted loss of $68k to $114k. (October’s predicted loss was much less than forecasted) This was due to timing issues, as these invoices were expected to come in October.

December had some variances between actual and forecasted, ending up with a $59k loss instead of the forecasted $66k. Some of the more material events were:

  • Revenue was up $50k over forecast due to VAT deductions from Vienna booked to uncategorized income at month’s end that totaled $57k.
  • Board expense came in at $4k but we had none forecast. We have updated the forecast for the recurring $4k item to be included each month.
  • IT expense in the admin section was $7k for December, but we forecasted $16K.
  • Cash ended the month (and year) at $770k, which was $119k higher than our forecasted $651k. This ends our year with our minimum cash reserve goal sitting at 10%.

With reforcasting in process, and not quite finalized, we expect cash to grow over the next four months, leading into DrupalCon Nashville in April 2018.

We will be blogging soon about our 2017 close, which includes our CPA driven financial review (a lighter “audit”), production of our 2017 990 tax return and a 2017 weather report review from our virtual CFO group Summit.

We would not be able to do our mission-driven work without the support and contributions of our community. Contributions come in many forms, through the purchase of DrupalCon tickets and event sponsorships, through our Supporters and Members, Drupal.org sponsors, recruiters who post jobs on Drupal Jobs and many other fantastic ways our community supports the Drupal eco-system. We are deeply grateful for everyone who has contributed their time, talent, and treasure to move Drupal forward.

Thank you!

File attachments:  Drupal Association - Q3 2017 Financial Statements.pdf Drupal Association - Q4 2017 Financial Statements.pdf
Categories: Straight From Drupal

Dries Buytaert: Every day I'm Drupalin'

Tue, 2018-03-20 15:35

It's a few years old, but I don't think I've seen this Drupal rap video yet:

Categories: Straight From Drupal

Acro Media: Introducing the Drupal Commerce Kickstart 2.x Installer

Tue, 2018-03-20 14:51

There is now an easier way to install Drupal Commerce! And the best part is that you don't have to do any type of crazy spinup. It does involve a little bit of pseudo-programming, but if you know your way around a command line, you should be OK.

A Bit of Background

Commerce Kickstart logoThere's a Commerce Kickstart that exists for Drupal 7. It's Drupal Commerce and all the standard add-ons put together into a mock store. It shows you the power of Commerce and provides a bunch of examples. That can be helpful because Drupal is so modular and can be a bit daunting at first. You install just Commerce, but then if you want, say, gift cards, that's a separate module you need to add. There are all these little bits and pieces you have to get, and not all of them have intuitive names, and it can be very confusing. Commerce Kickstart was meant to solve that problem. Which it did, to some extent.

But the Drupal 7 Commerce Kickstart tried to be both a demo and a base for you to build from. It was primarily a demo, but lots of people used it as a base. The problem was that the demo was already so customized that many people ran into issues because they needed to delete or remove different things instead of starting from a clean setup.

A Better Way for Drupal 8

For Drupal 8, we decided to build two separate things: a demo, and a kickstart that would truly assist developers in getting started. It covers Drupal Commerce and all the normal add-ons you would typically add. With the original Commerce Kickstart, you got all the add-ons as a complete package, and you would have to remove whatever you didn't want. For Drupal 8, Commerce Kickstart is an actual builder.

And it's easy to use. You select a region, for instance. If you say that you're based in North America and only ship there, you're not going to see the options for integrating with the Royal Mail, because that's irrelevant to you. Then you go through the different sections. What do you need for payments? For shipping? You select all the options you want, and Commerce Kickstart uses Composer to build an install file for you.

Screenshot of the Commerce Kickstart Installer

Why Is This Cool?

For one thing, it saves you time. For another, it's a great introduction for people who aren't familiar with the Commerce ecosystem. That latter point is key, as that was the biggest hurdle Commerce Kickstart was trying to overcome. If you're new to Commerce and you don't know about all the add-on options, you might install Drupal Commerce and just get stuck. This gets you much farther in the process.

Check Out Our High Five Drupal Web Series Demo Content On the Way

You will eventually be able to choose whether you want a clean install, or whether you want to use demo content. With example content, you could see what a nicely configured product looked like, for instance. Or see a sample tax item, or a sample shipping method. This could be great for people who aren't super technical or who just aren't familiar with Drupal Commerce conventions.

This functionality isn't out there yet, but it is coming down the pipe soon. You can see the status of the Demo Content module here.

We also have pre-set-up migrations. So it's becoming easy to migrate from an Ubercart site or a Commerce site on Drupal 7. Options for Magento and Shopify are also coming.

The Bottom Line

If you're building a Drupal Commerce website, use Commerce Kickstart 2.x Installer. It's the best ad easiest way to get Drupal Commerce installed with everything you need.

Try the Commerce Kickstart 2.x Installer

More from Acro Media


Chat with us

If you'd like a personalized tour to discuss how Drupal Commerce fits into your ecommerce solution, give us a shout. We're happy to show and tell.

Contact Us

Categories: Straight From Drupal