This post is part 3 in the series “Hashing out a docker workflow”. For background, checkout my previous posts.
Hola! On Tuesday the DrupalCon 2015 in Barcelona has officially started. It is the day when the lectures are starting, the group photo is to be shot and the first day after greetings, sprints and parties with the community...
Final thoughtsDrupal 8 is a game-changer and I’m excited about the possibilities - especially as the community grows around the world. Meanwhile, it’s back to youtube until I pass out on this no-frills DrupalCon experience - sad to be missing out on all the networking & fun times but sh*t happens, one lives and learns... ;) tags: drupalcondrupalDrupal PlanetPlanet Drupal
The Realityloop team is currently at DrupalCon Barcelona. During the opening keynote this morning Dries Buytart attempted to investigate several questions regarding Drupal's place at the moment.
In particular I was interested when he asked "Is Drupal losing momentum?", even before he continued I thought to myself that this is mostly people waiting on Drupal 8 to get released.
Looking at statistics he showed that this loss of momentum has ocurred in the past, as you can see in the image from Dries' slides shown below, Drupal lost momentum before the release of Drupal 7.
This is known as the Osbourne Effect which posits that "Announcement of a new release slows adoption of the current version." I know that we have clients that are contributing to this as I've had several discussions that start with "should I upgrade my site now or wait until Drupal 8 is released?".
This is a somewhat complex question that depends a large part on the functionality that is required by your site, the budget you have to invest towards module porting, and also the time at which the conversation took place.
The key thing is that after the release, at least since Drupal 6, there has always been a surge in adoption once the next version gets released.
As part of the core mentoring team I am a firm believer that you can predict this by looking at the number of contributors for each release:
- Drupal 5 - 472+ contributors
- Drupal 6 - 741+ contributors
- Drupal 7 - 950+ Contributors
- Drupal 8 - 3,000+ contributors
To me this indicates that there will be quite the surge once Drupal 8 is released, and the exciting news is that RC1 has now been scheduled for release on October 7th.
The Realityloop team is committed to Drupal, and although we are a team of 3, we've been involved in the development of over 100 contributed modules and are already scheduling time to begin work on porting many of the modules that still have a place in Drupal 8.
Drupal already powers close to 50% of the top 100,000 websites, and with one of the largest developer communities of any open source project I truly believe that once Drupal 8 goes stable there will be a surge in growth and a storm of really great sites for us to build.
If you have an upcoming project and would like to talk about building it with Drupal 8 or are interested in supporting the porting of any modules to Drupal 8, please do get in touch with me from October 4th:
- Brian Gilbert Ph +613 8609 6966
If you are interested in hearing more about Drupal 8 the Realityloop team are currently also organising Drupal Camp Melbourne, and unconference which will be held on November 27th and 28th 2015.
DrupalCon Barcelona. Day 2. The Annertech crew were up early (especially given our late night last night) and arrived at the convention centre. Here's our team's "best of the day" list - including one from Marta Paz, whom we've picked up as an honorary Annertechie for the week.
Mark "I loved the talk by Tim Millwood and Dick Olsson about revisions in Drupal 8. We see a lot of tenders for large projects asking for an "audit trail" and the approach being taken with multiversions/revisions looks very, very promising."
This tutorial is written for new drupal developers or php developers who want to learn drupal. You can find the part 1 of the tutorial here: tutorial part 1
Last time, we created a simple recipe module with save and load functionality. The user interface is not very friendly yet, and users have to enter a recipe id in the url to load it.
Today, we are going to improve the usability of the module by adding some UI element to it. By the end of the tutorial, you will be able to add, and...
When you are adding Views, you may have seen an extra option called "Delta".
Several students have asked us about the purpose of this field, because it wasn't clear.
The Delta option is available throughout the site, but ordinary users are most likely to encounter it inside Views. Here's how the "Delta" options appear in Views:
Whenever a user clicks on a taxonony term, they will see a page showing all content tagged with that term.
By default, Drupal shows the most recent layout first, using a teaser display.
But, what can you do if want to sort your content differently, or use a different display? The answer is to use Views to control your taxonomy pages.
In this video from our "Advanced Views" class, Robert shows you how this is done:
Fast changing technologies do not leave a chance to web development services which have lived out their lives. Large images, responsive design, animation and clickable pages – which options still keep popular this year and which will become the issue of nasty taste? Let’s take a look on web development trends 2015.Read more
To the Drupal developers getting started with Symfony, there's a whole new set of vocabulary words we need to learn. In this short SlideShare presentation, I cover a few of the key things you need to know about the new terminology in Drupal 8 including:
- Dependency Injection
- Service Containers
Mumbai, earlier known as Bombay, offers up an interesting mix of history and modernity that cannot be explained in words. You simply have to experience this city.
Here are 10 places and things you must not miss visiting when you come for DrupalCon Asia 2016.
Drupal 8 has comprehensive knowledge about the cacheability of the things it renders. This opens new doors. Did you know Drupal 8 will be able to cache everything at the edge?
For sites with many mobile users (high latency due to network), global audiences (high latency due to distance) and performance-sensitive sites (e-commerce), Drupal 8 will be a huge leap forward.
We’ll be showing how easy and powerful it is using the CloudFlare and Fastly CDNs.Cache tags
Instantaneous purging of all (and only!) the affected pages when an article is updated. No more manual purging by content editors. No more fiddling with URLs to purge. It all just works. Optimally.
Cache anonymous pages without any effort. On your own reverse proxy, and on many CDNs — thanks to standardized configuration.
This sounds nice, but that’s just the anonymous user case. What about authenticated users?Cache contexts
The typical example: a shopping site, users categorized in groups according to interests, and a shopping cart.
Automatic caching of the entire page, minus the shopping cart, on the edge. Reused across all users in the same group. And, if the CDN supports it, even the shopping cart can be cached on the edge (and be kept up-to-date thanks to cache tags). Otherwise only thatneeds to talk to the origin (via AJAX, for example).
Cache authenticated pages without any effort. On your own reverse proxy, and on some CDNs — thanks to standardized configuration.Goals
- The caching concepts
- BigPipe, ESI, hybrid rendering strategies
- A peek at the future: ServiceWorker
Drupal will soon be 15 years old, and 5 of that will be spent on building Drupal 8 -- a third of Drupal's life. We started work on Drupal early in 2011 and targeted December 1, 2012 as the original code freeze date. Now almost three years later, we still haven't released Drupal 8. While we are close to the release of Drupal 8, I'm sure many many of you are wondering why it took 3 years to stabilize. It is not like we didn't work hard or that we aren't smart people. Quite the contrary, the Drupal community has some of the most dedicated, hardest working and smartest people I know. Many spent evenings and weekends pushing to get Drupal 8 across the finish line. No one individual or group is to blame for the delay -- except maybe me as the project lead for not having learned fast enough from previous release cycles.Trunk-based development
The past 15 years we used "trunk-based development"; we built new features in incremental steps, maintained in a single branch called "trunk". We'd receive the feature's first patch, commit it to our main branch, put it behind us, and move on to the next patch. Trunk-based development requires a lot of discipline and as a community we have mostly mastered this style of development. We invested heavily in our testing infrastructure and established a lot of processes. For all patches, we had various people reviewing the work to make sure it was solid. We also had different people figure out and review all the required follow-up work to complete the feature. The next steps are carefully planned and laid out for everyone to see in what we call "meta" issues. The idea of splitting one large feature into smaller tasks is not a bad idea; it helps to make things manageable for everyone involved.
Given all this rigor, how do you explain the delays then? The problem is that once these features and plans meet reality, they fall apart. Some features such as Drupal 8's configuration management system had to be rewritten multiple times based on our experience using it despite passing a rigorous review process. Other features such as our work on URL routing, entity base fields and Twig templating required much more follow-up work compared to what was initially estimated. It turns out that breaking up a large task into smaller ones requires a lot of knowledge and vision. It's often impossible to estimate the total impact of a larger feature on other subsystems, overall performance, etc. In other cases, the people working on the feature lacked time or interest to do the follow-up work, leaving it to others to complete. We should realize is that this is how things work in a complex world and not something we are likely to change.
The real problem is the fact that our main branch isn't kept in a shippable state. A lot of patches get committed that require follow-up work, and until that follow-up work is completed, we can't release a new version of Drupal. We can only release as fast as the slowest feature, and this is the key reason why the Drupal 8 release is delayed by years.
Trunk-based development; all development is done on a single main branch and as a result we can only release as fast as the slowest feature.
We need a better way of working -- one that conforms to the realities of the world we live in -- and we need to start using it the day Drupal 8.0.0 is released. Instead of ignoring reality and killing ourselves trying to meet unrealistic release goals, we need to change the process.Feature branch workflow
The most important thing we have to do is keep our main branch in a shippable state. In an ideal world, each commit or merge into the main branch gives birth to a release candidate — it should be safe to release after each commit. This means we have to stop committing patches that put our main branch in an unshippable state.
While this can be achieved using a trunk-based workflow, a newer and better workflow called "feature branch workflows" has become popular. The idea is that (1) each new feature is developed in its own branch instead of the main branch and that (2) the main branch only contains shippable code.
Keeping the main branch shippable at all times enables us to do frequent date-based releases. If a specific feature takes too long, development can continue in the feature branch, and we can release without it. Or when we are uncertain about a feature's robustness or performance, rather than delaying the release, it will simply have to wait until the next release. The maintainers decide to merge in a feature branch based on objective and subjective criteria. Objectively, the test suite must pass, the git history must be clean, etc. Subjectively, the feature must deliver value to the users while maintaining desirable characteristics like consistency (code, API, UX), high performance, etc.
Feature branching; each feature is developed in a dedicated branch. A feature branch is only merged into the main branch when it is "shippable". We no longer have to wait for the slowest feature before we can create a new release.
Date-based releases are widely adopted in the Open Source community (Ubuntu, OpenStack, Android) and are healthy for Open Source projects; they reduce the time it takes for a given feature to become available to the public. This encourages contribution and is in line with the "release early, release often" mantra. We agreed on the benefits and committed to date-based releases following 8.0.0, so this simply aligns the tooling to make it happen.
Feature branch workflows have challenges. Reviewing a feature branch late in its development cycle can be challenging. There is a lot of change and discussion already incorporated. When a feature does finally integrate into main, a lot of change hits all at once. This can be psychologically uncomfortable. In addition, this can be disruptive to the other feature branches in progress. There is no way to avoid this disruption - someone has to integrate first. Release managers minimize the disruption by prioritizing high priority or low disruption feature branches over others.
Here is a workflow that could give us the best of both worlds. We create a feature branch for each major feature and only core committers can commit to feature branches. A team working on a feature would work in a sandbox or submit patches like we do today. Instead of committing patches to the main branch, core committers would commit patches to the corresponding feature branch. This ensures that we maintain our code review process with smaller changes that might not be shippable in isolation. Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review.
Feature branches are also not the silver bullet to all problems we encountered with the Drupal 8 release cycle. We should keep looking for improvements and build them into our workflows to make life easier for ourselves and those we are implementing Drupal for. More on those in future posts.
The Features module has become a de facto tool in configuration management in Drupal 7. In fact, most Drupal distributions now utilize Features to export configuration and handle updates to the configuration. There is one pitfall - Features was meant to be a way to export a feature set. Features takes a set of configurations and its job is to ensure those are in place. That means customizations to defaults are at risk of preventing incoming changes or loss when updating. That’s not good! You’re using a Drupal distribution so you save time, but now you have headaches because customizations disappear.What is Features Override, then?
That’s where Features Override comes in and allows you to revert your feature modules and ensure configuration sticks. The name of the module speaks to its purpose. It allows you to override a feature and export those changes. But, how? Chaos Tools provides its own alter hooks for its object CRUD API. That means Views, Page Manager, Panels, and any item implementing this CRUD can be exported as a glob of PHP code representing an associative array of objects. Entity API has its own CRUD, too; without knowing much of the history I’d assume Entity API’s implementation was modeled after Chaos Tools. The biggest difference is the Entity API utilizes JSON for moving items around. Features, itself, provides its own alters for items that don’t have an import/export definition - such as field bases, field instances, etc. Features Override is a UI for writing alters in your feature module.Let’s Do This!
We’ll run through customizing Commerce Kickstart 2 - the most download distribution which gets pretty customized. As a disclaimer, I am a maintainer of the project. If you were to install Commerce Kickstart 2 and navigate to Structure -> Features (admin/structure/features) you’d see something like the following:
“Default” means the Features is in its expected state. If we added a new config export or tweaked something, you’d receive it on update. Let’s change that because we want the Blog Post content type to hide the category and tag fields when we’re displaying them as a teaser.
In the above we’ve marked Category and Tags as hidden. In fact, since CK 2.27 there has been an automated test checking this change and Features Override. That’s right - we have automated testing to ensure your changes live on using Features Override (boom.) Let’s look back at our Features.
Now we’re going to create a new Feature called “CK2 Overrides” that will contain our specific changes. That will allow us to upgrade Commerce Kickstart 2 and revert its feature modules and keep our own changes. From the Manage Features page, we will select “Create Feature.” The next step is to pick your “Feature Overrides” component.
So this is where it can get confusing. As you can see there are two component types: “Feature Overrides” and “Feature Overrides (individual — advanced)” Unless you know what you’re doing - just pick the former. Feature’s magic will auto-populate what specific individual overrides are required to be exported. Think of it as nitpicking what specific keys in an array export it needs to alter (because that’s what it is!) Generate or download your feature and enable it!
And now we have nothing overridden!Tips and Tricks
It’s not perfect - nothing is. So here’s a few tips and tricks I’ve learned
- Not all overrides are caught, not all overrides want to stick.
- Enabling an overrides feature sometimes needs caches cleared to kick off a new features component rebuild. Manually reverting won’t kick over the “overridden status."
- An override feature will show up as overridden if the base feature is overridden - sometimes you just need to revert that one.
"Where is my .htaccess file?"
This is a problem that we've helped resolve over and over again at OSTraining.
The .htaccess file is absolutely crucial for the correct operation of many sites, whether they're running WordPress, Drupal, Joomla or similar platforms. The .htaccess files controls the URLs for sites and also adds many important security features.
Today, one more user was having trouble finding their .htaccess file, so we created this tutorial for her.