clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#3

On github - ma, 2014/04/21 - 4:40pm
April 21, 2014 clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#3 Support --format to output new formats.

clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#2

On github - ma, 2014/04/21 - 4:23pm
April 21, 2014 clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#2 Selector has no validation

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

Planet Drupal - ma, 2014/04/21 - 4:20pm

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.


Mark Koester: Building Mobile Apps for Drupal Conference Sites

Planet Drupal - ma, 2014/04/21 - 4:15pm

I'm excited to announce that we've built our first Drupal-powered apps for iOS and Android. The apps are in the Android and Apple marketplace and are helped to improve one association's yearly technical conference.

There are times when apps are overkill and unneeded. Frankly there are already too many apps out there. But as we as a company continue to focus on conference sites, this was an obvious use case where taking the plunge into mobile app development made sense. It’s nearly become standard to have an event app at major conferences around the world.

At events, internet connectivity isn't that reliable and attendees, speakers and organizers are able to navigate the event much easier with the right mobile tool. Conference sites provide more media attention for sponsors and also provide various ways for networking.

In this post, I'd like to discuss our recent work building two mobile apps---one for Apple iOS and another for Google Android. Specifically in this post we’ll look at what we built, and in a future post, we’ll look at how we built these apps using different technologies (Drupal, iOS and Android) as well as some technical and business takeways we gained from this process of integrating a CMS like Drupal with a mobile device.

Let's take a look at what we've built.

Drupal-Powered Conference Sites

One of our main focuses over the last several years has been event and conference sites.

Drupal handles content, users and commerce with increasing sophistication and flexiblity. In Drupal 6, we used COD to build club and simple event management systems. In Drupal 7, we decided to shift away from COD and Ubercart and have been building our own events registration system using Panopoly, Drupal Commerce and Registration.

The first fruit of this work was a romance writers conference that last year took some 150+ orders in the first 10 minutes for signup. This year the same event was even more rapid fire and took 200+ orders in the first 3 minutes after registration opened!

We love building Drupal sites for events so much that we are, in fact, also working on our first alpha release for this platform called "Events for Drupal".

Along with that site, this past year we've gotten the chance to test and refine the system on other projects.

Several months ago, SPE Environomental Division came to us to overhaul their site to better deal with their yearly event, GPEC (Global Plastics Environmental Conference). Specifically, we cleaned up their legacy content and sessions and built a clean flexible design and layout. We organized their content and products around their yearly event and we empowered them to handle their own ecommmerce needs and registrations.

Along with a full upgrade to handle registration and paid sponsorship, we overhauled their session and awards submissions processes. Potential speakers could submit their abstracts months before the event and admin could manage it from approval to scheduling and room assignment. This allowed them to create a dynamic schedule and, most importantly for their app, to make their content available for mobile distribution.

So, with the content exposed via an API, what did we build?

What We Built: A Conference App with a Drupal Backend

To be honest, it's not that uncommon to see conference apps these days. It's one of the easier mobile use cases to build for. (There are even several companies that provide a platform for generating your own apps for events, like Guidebook.)

Most conference or event apps provide the following features: event schedule, session and speaker info, venue maps and various "about" pages as well as perhaps a facebook or twitter feed.

We wanted to have all of this along with one key additional change: it needed to be dynamic. In particularly, we wanted a dynamic "my schedule" functionality; a way that the user could mark sessions they wanted to go to and a dynamic my schedule display. This "marking attendance" needed to be available and synced on either the site or app. This would then allow the "my schedule" page to be seen on the app, in the site or even in an exportable and printable format.

In the Drupal world, there are also several conference apps. There is nearly a new app for each DrupalCon. These apps provide attendees with the schedule and other event info. While these "Drupal" apps are quite helpful, they are in most cases static. The event content (sessions, rooms, speakers, etc) was exported and simply built into a page-by-page functionality. Some do provide data pulls but I didn't see any that went far into the functionality we wanted, like login and “flagging” sessions to attend.

In many cases this static format is enough, but we felt that these apps missed out on providing a more dynamic and interactive experience. In big events with dozens or hundreds of sessions, a conference without a personalized user schedule is not that helpful. Many attendees end up using a paper version for the simple ability to circle and markup the sessions they want to go to.

As such, we took the more dramatic choice to build a dynamic app integrated into the website's backend.

This approach allowed us to provide a way for attendees to download the most up to date session info (meaning you didn't have to wait to download a revised version of the app itself, just the content). Event administrators could change the session info even minutes before the event and users could update and see it.

The method also allowed attendees to create and manage their own schedule. Users could mark sessions they wanted to attend either via the site or one of the apps. They could then view their personalized schedule both before and during the conference. From a user perspective this was a huge success.

From administrative side, since the attendence data was synced with the site, it also gave the event organizers some rough total attendence numbers for different sessions BEFORE the actual start. Sessions that appeared to have higher demand could be moved to bigger rooms accordingly.

Like most conference apps, we also chose to put various bits of static info in the app. As I had to explain to different organizers, you can't just extend an existing site into a mobile app. Unlike a CMS like Drupal, each dynamic app functionality takes longer to develop, so where the content was likely to stay static, we built it into the app as static. As such, we elected to keep our about pages, organizer pages and sponsor lists as embedded content.


From a technical perspective, building Mobile Apps with Android and iOS wasn't that easy. It's also not without additional time and cost. Many times a responsive, mobile design is enough since it allows users to have a reasonably good experience on whatever device they use.

From my personal builder and developer perspective, it wasn't quite as hard as I imagined it could have been either. Neither easy nor hard, this approach carried various challenges.

For iOS, we were fortunate to have a preexisting library that made developing an iOS onto of an existing Drupal Site: Drupal iOS SDK from Kyle Browning. This library significantly helped in creating our iOS app. Specifically, this library abstracted out several common features like logins, pulling node data, etc as well provided an add-on library for integrating flags.

Like a lot of US-based development, we started with iOS and then built the Android app after. There was no doubt though that we were going to build for both platforms. Unfortunately there wasn’t a preexisting library to use but the basics and structures in the iOS library helped clarify what we needed for the Android version.

In conclusion, mobile apps are the more recent and current tech wave. In some cases mobile apps are superfluous. But for Drupal-powered conference sites, a mobile app can be a good fit to improve the user experience and interaction before, during and after you event.

Tags: Drupal Conferenceconferencesmobile appsiOSAndroidDrupal PlanetPlanet DrupaldrupalDrupal Commerce Mark Koester @markwkoester Mark has worked on Drupal since the early days of D6. He is passionate about open source as well as entrepreneurship. When he isn't building, he enjoys traveling and speaking one of his many foreign languages. Chengdu, China

clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#1

On github - ma, 2014/04/21 - 4:03pm
April 21, 2014 clemens-tolboom opened issue clemens-tolboom/drush_alias_crud#1 Non-existing path give parent keys.

clemens-tolboom pushed to master at clemens-tolboom/drush_alias_crud

On github - ma, 2014/04/21 - 3:45pm
April 21, 2014 clemens-tolboom pushed to master at clemens-tolboom/drush_alias_crud
  • 3a32456 Added delete and fixed some bug.

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

Planet Drupal - ma, 2014/04/21 - 3:18pm

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.


Frederick Giasson: Managing Resource Type Entities (Screencast)

Planet Drupal - ma, 2014/04/21 - 2:53pm

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.


clemens-tolboom pushed to master at clemens-tolboom/drush_alias_crud

On github - ma, 2014/04/21 - 1:32pm
April 21, 2014 clemens-tolboom pushed to master at clemens-tolboom/drush_alias_crud
  • 7474d18 Initial addition of drush command.

clemens-tolboom created repository drush_alias_crud

On github - ma, 2014/04/21 - 1:29pm
clemens-tolboom created repository drush_alias_crud April 21, 2014

clemens-tolboom commented on pull request clemens-tolboom/uml-generator-php#43

On github - ma, 2014/04/21 - 9:50am
April 21, 2014 clemens-tolboom commented on pull request clemens-tolboom/uml-generator-php#43

Looking good ... deleting branch. Thanks.

Metal Toad: Pond Life Ep.3

Planet Drupal - ma, 2014/04/21 - 9:15am

Welcome once more to the pond! Last week we touched on SASS and it's importance to the developer workflow. We also walked through an introduction of Drush and Capistrano. Both of those tools are key environment tools for anyDrupal/PHP configuration.


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

Planet Drupal - ma, 2014/04/21 - 9: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.


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.


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.


Drupal core announcements: Approachable tasks for Drupal 8 Beta 1

Planet Drupal - ma, 2014/04/21 - 3:28am

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.



Subscribe to build2be/com/e aggregator