This Wednesday, April 05 is the release window for Drupal 8.3.0, the next scheduled minor release of Drupal 8. There will be no Drupal 7 bugfix release this month.
To ensure a reliable release window for the minor release, there will be a Drupal 8.3.x commit freeze from 12:00 UTC Tuesday to 12:00 UTC Thursday. Now is a good time to update your development/staging servers to the latest 8.3.x-dev code and help us catch any regressions in advance. If you do find any regressions, please report them in the issue queue. Thanks!
To see all of the latest changes that will be included in the release, see the 8.3.x commit log.
Other upcoming core release windows after this week include:
- Wednesday, April 19 (security release window)
- Wednesday, May 03 (patch release window)
"If you're not testing, you're doing it wrong." I can't remember how many times I've heard those words. Each time, I'd feel a little pang of guilt, a little bit of shame that every day, I wrote code for myself and clients that wasn't tested. I'd be frustrated with the developers who repeated that mantra. Sure, it was easy to say, but hard to live up to. How do I test? What do I test? Should I test? How would I justify the costs?
As a developer who started his career writing custom code for Drupal applications, it was easy to skip testing. Drupal 7 was really quite untestable, at least in any practical sense. Drupal core itself was tested, and big modules like Views, Ctools, and Entity API had test suites too. But finding tests in other custom code or smaller modules was a rarity. Even today, with a vastly more testable code base, documentation for testing Drupal code is terse and hard to come by. It's focused on educating core contributors and module maintainers, not day-to-day developers writing modules to satisfy particular real-world needs.
I hope this series will change that for you.
I will make the case that you should be testing; that you'll save time and you'll save money, and that you won't need to "justify the cost." This series will start from first principles:
- What is automated testing?
- Why is automated testing a net positive?
- How do I write my first test?
- How do I write the one after that? (because that's really where it gets hard isn't it?)
What is automated testing?
I define automated testing as the act of asserting that your code achieves its goals without human interaction.
Types of Automated Tests
There are many types of automated testing. Each serves a specific need and each operates at a different level of abstraction. They form something like a pyramid, your most numerous tests should be at the bottom, as you go higher up the stack, you should have fewer and fewer tests.
At the lowest level, are unit tests (and that's what this series will focus on). Unit testing is code that you write to test or "exercise" the actual custom code that you write. Unit tests isolate very small bits of functionality and assert that your code can handle all kinds of inputs correctly. You might write a unit test to assert that an
add(x, y) function adds numbers correctly.
Above unit tests, are integration tests. Integration tests assert that the small bits of functionality that you tested with unit tests "integrate" together. Perhaps you wrote a suite of arithmetic functions which you unit tested individually. When those functions come together into a calculator, you might write integration tests to validate that they all work in harmony.
At the highest level are system tests. System tests assert that your application works as a cohesive whole. These "acceptance" tests are usually best expressed as the functionality your client cares about. "Can my potential customer use a calculator to estimate a mortgage payment and then call me for a quote?"
There are no definite lines of separation between these types of tests, they all fall along a continuum—it's a curve, not a step function.
It's not important to know exactly where your test falls on that curve, really, it's just important to know that:
- You can test at different levels of abstraction.
- You do not need to test everything at every level of abstraction.
Different Tools for Different Tests
Just as there are different types of tests, there are different tools that go along with them. As with all things in software development, there are lots of tooling choices and tradeoffs no matter what you choose. The beauty of using Drupal, however (or any framework) is that some of those choices have already been made for you either officially or by convention in the community.
At the lowest level, is unit testing. The standard adopted by Drupal 8 is PHPUnit. PHPUnit is a suite of command line tools and base classes that make writing tests easier. Drupal has extended some of the PHPUnit classes with some extra features that make testing code written specifically for Drupal easier. The Drupal class used for unit testing is called UnitTestCase. We're going to take a deep dive into this, and all the Drupal testing classes and tools later in the series.
At the integration test level, Drupal uses a mix of PHPUnit and Simpletest, but is migrating all of its Simpletest based code to extensions of PHPUnit tests that can achieve the same things. In Drupal, the class primarily used for this kind of testing is called KernelTestBase.
At the system test level the lines begin to become somewhat blurred. Drupal calls these “Functional” tests and there are two classes for them. WebTestCase and BrowserTestBase classes can do quite a bit, and are the standard for testing Drupal Core and contributed modules. They work well for contributed modules and Drupal core because they don’t need to test the specifics of a real-world Drupal application and all the configuration and customization that implies.
I hope this post has given you a sense of what automated testing is and some basic terminology that we can share in the next part of this series: “Why Automated Testing will Save You Time and Treasure.”
In recent days there's been a bunch of insightful and thought provoking reflection within the Drupal community (as well as a share of bullshit). I've benefited from hearing perspectives that remind me of my biases and privileged placement as a cis white male. A comment by Melissa Anderson, someone I know and respect, had particular impact for me.
A lot of attention has focused on a particular action by Drupal project owner Dries Buytaert. But many are going deeper.
The trouble with Drupal is not so much any individual action.
The trouble is that, for all its collective trappings and thousands of contributors, Drupal is formally structured as a dictatorship.
Really? In 2017? Yes, really.The Thing About Dictatorship
As detailed in documentation of the Drupal project structure, the self-anointed "benevolent dictator for life" not only exerts ultimate control over code but also "preserves [that is, controls] the philosophy, culture, and principles of the project."
Wow. Think about that for a minute.
The occasional overt dictate can indeed be worrisome. But I'm actually much more troubled by what's so normalized in the project that it passes without comment.
I won't repeat what I've gone on (and on!) about in previous comments and reflections on Drupal's power structure going back over a dozen years. Here's a selection:
- Making Drupal fully 'community-driven': A Proposal for restructuring the Drupal project (January, 2005).
- Will The Revolution Be Drupalized? (September, 2014).
- Tag1 Spotlight: Nedjo Rogers (April, 2015).
But I will add I'm struck anew by what seems to me the unusual depth and reach of the authoritarian model in the Drupal project.
I've often heard it said, for example, that Linux, too, has a so-called "benevolent dictator for life".
True. But, contrary to Drupal, the Linux dictator doesn't individually set the terms of reference of, and appoint every member to, key community structures. (Come to think of it, isn't there something Orwellian about a so-called "Community Working Group" appointed by a dictator?) Unlike Buytaert with the Drupal Association, the Linux dictator doesn't have his name written into the bylaws of the Linux Foundation as a director with own reserved slot, nor has he served as the de facto permanent board president of the Linux Foundation since its inception. He doesn't have a seemingly permanent seat on the committee that vets every nomination to the Linux Foundation board.
And, crucially, unlike Buytaert in Drupal, he isn't a founder and key executive of the Linux company that exerts the deepest influence on the software.
Effective checks on the absolute power of the project founder? It's really hard to find any.
For thousands of people caught up in the Drupal project, what does all this mean in practice? As in many communities, boundaries often blur. Drupal can come to define not only one's work life, but also leisure activities like volunteer coding or meetup organizing, even key daily social links and interactions.
Put that together with a patriarchal model, intimately tied to capitalism and corporate power, permeating all these realms - work, leisure, friendship, community - and you get a deeply troubling degree of influence. One that, precisely because it's everywhere, may be almost invisible. In a community where it's all about personal ties and influence, power seldom needs to act overtly.
"Dictator for life". This, too, is something to think long and hard about. That's a lot of future years. For those who stay, what does it mean, this prospect of being part of a dictatorship culture most of one's life?
There's a tonne of beautiful energy in the Drupal project. There are brilliant and passionate people who care deeply about our community and are rightfully proud of our collective project.
Not thanks to the dictatorship model. In spite of it.
Is what we're seeing the beginnings of a "Drupal spring"? If so, where might it lead?The Coming Fork
Conditions are ripe for a fork of the Drupal project. But what kind of fork?
For a software community mired in regressive power dynamics, a fork can be a positive source of renewal, allowing participants to resolve contradictions and carry forward the project's best attributes.
Or a fork can replicate the same regressive crap that prompted problems in the first place.
Worse--given the current context, a fork could reinforce and enshrine forms of cis white male privilege.
So the key question is not so much whether to fork. Rather, it seems to be: if so, how?
A cultural fork
Yes, there are deep problems with Drupal's code base, many resulting from the warping effects of corporate interests. But the primary challenge of a fork is not about code. It's about culture.
The dictatorship model in Drupal runs deep. So, no, a light makeover isn't going to cut it. A fork needs a radical cultural reset.
We need to look to voices of diversity and inclusion.
We need to create room for critical perspectives and insights that too often have been shouted down by louder voices in the project--ones that, over and over, have rushed to attack questioners of the founder's prerogatives. (I speak as someone who's repeatedly been targeted for my critical voice. And sometimes, yes, silenced.)
We need to deeply question a culture that promotes living for the cause as a positive or even a required leadership quality.
In the Backdrop fork of Drupal, I and others promoted a "project management committee" structure, replacing the single dictator with a group of lead contributors. And I do think the more diverse and inclusive Backdrop leadership team is a huge improvement over Drupal.
But, here, is it enough? Not nearly.
I personally want to look for inspiration and ideas to the platform cooperative movement, which is opening horizons for free software collectively owned by those who use and build it.
That vs. dictatorship? I know where my heart is.
A fork should draw in existing progressive initiatives and structures in and around the Drupal space.
One that I'm involved with is Drutopia.
We've also got an expending number of engaged, radical organizations and cooperatives in the Drupal sphere. How do we draw them in? Or, maybe better put: how can we be open to them drawing us in?
A fork shouldn't require people to switch
Strategically, a new fork will probably have the most scope and impact if it doesn't force people to switch immediately to something new. Instead, it could work as a drop-in replacement for Drupal 8--and future Drupal versions.
For those familiar with the MySQL database, think MariaDB, the community-led fork of MySQL. If you already use MySQL, you can switch very painlessly to MariaDB--and get some great improvements for your effort. Your existing MySQL databases just work. The MariaDB project maintains compatibility by merging in changes from MySQL.
In the same way, a Drupal fork could "just work" if your site was originally built on Drupal.Moving Forward
Crises in authoritarian systems play out in familiar ways. There will be - there already are - calls for a brand of "healing" that involves returning to the fold, reflecting sagely on lessons supposedly learned, and pledging renewed faith in the beneficent leader. Ah, I see one such post just appeared from the Drupal Association. Right on cue.
And there will be organizing on the ground. By those of us truly fed up with a corrosive patriarchal agenda, one that once again masks its power behind a false and exploitative language of inclusion.
Who are hungry for progressive change.
This is a joint statement from project lead Dries Buytaert and Megan Sanicki, Drupal Association Executive Director.
Over the last week, the Drupal community has been in a debate over the various decisions made by us in relation to long-time Drupal developer Larry Garfield. As with any such decisions, and especially due to the circumstances of this one, there has been controversy, misinformation and rumors, as well as healthy conversation and debate. Many people feel hurt, worried, and confused. The fact that this matter became very public and divisive greatly saddens all of us involved, especially as we can see the pain it has caused many.
First off, we want to apologize for not responding sooner. We had to take a pause to process the community’s reaction. We also wanted to take the time to talk to community members to make sure all of the concerns were heard and understood. This was further complicated by the fact that we don't have a playbook for how to respond in unusual situations like this. We also want to acknowledge that our communication has not been as clear as it should be on this matter, and we are sorry for the added confusion.
We want to thank all of the community members who stepped in to help. Many spent days helping other community members by listening, hosting discussions to foster healthy, respectful conversations, and more. You have helped many people and your caring acts reminded us once again why we love to serve the community and why it is so special.
Over the last week, we talked to many people and read hundreds of posts in various channels. These are some of the things that we heard:
People are afraid that they will be asked to leave the community because of their beliefs or sexual lifestyles.
There are concerns about Drupal leadership playing "thought police" on what are and are not acceptable viewpoints to hold.
People want to hear more about the timeline, information gathered, and how decisions were made.
People don't understand why there weren’t any ramifications for those who participated in gathering information about Larry's private life.
People believe Dries has too much authority.
People believe that a decision this complex should not be made by a single individual.
And we heard much more.
We know this has been difficult for all involved. There is no quick solution to the current situation; it will take time to heal, but we want to make a start today by providing better insight into our decision-making process, answering questions with the FAQ found below, and by placing a call for improvements in our governance, conflict-resolution processes, and communication.
Addressing community questions and concerns
One of the main concerns that has been voiced is that a long-standing member of the Drupal community was removed, based solely on his beliefs being outside the "norm". We feel this is not representative of the situation.
We want to strongly emphasize that Drupal is an open-minded and inclusive community, and we welcome people of all backgrounds. Our community’s diversity is something to cherish and celebrate as well as protect. We apologize for any anxiety we caused you and reiterate that our decision was not based on anyone’s sexual practices.
Dries and Megan based their decisions on information from a variety of sources, including the Community Working Group and Larry himself. This information included:
(a) reports, both formal and informal
(b) some of Larry's online interactions, both on and off Drupal.org
(c) information provided by Larry during subsequent discussions to get clarity
(d) information from one or more members-only sites.
It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.
Insights from this collection of information caused us to take action, particularly given Larry's prominent leadership role in the community, which leads to a much greater impact of his words and actions.
We heard that many would like to better understand the timeline, information gathered, and how decisions were made. While the news of last week was a complete surprise to most, it is important to note that this has been a careful, and deliberate process that has been going on since October 2016. Following the Drupal community's governance, the Community Working Group attempted to provide conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries, as project lead. This was consistent with their existing policy and process.
Dries discussed the information from the Community Working Group with Megan and some board members. Dries, as project lead, made the decision about Larry’s role in the project during this discussion.
Some have asked why Larry was removed from the community and not just from his leadership roles. The answer is that Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project, and that context helped inform Dries’ decision.
Dries, with the support of the Community Working Group, had the first of what was intended to be a number of conversations to resolve any remaining concerns.
Megan was informed about Dries’ decision, and also reviewed the information provided by the Community Working Group. Based on that information, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.
Larry appealed Megan’s decision to the board, which only has oversight of the Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements, met in a special Executive Session attended by all board members, and upheld Megan’s decision. Dries recused himself from this vote, so the board could make its decision independently.
After the appeal process, Larry chose to publish his own account of what happened, effectively ending the process in the middle of what we expected to be a series of constructive discussions. This resulted in several loose ends.
After Larry’s second blog post, on Tuesday, March 28th, he reached out privately to Dries to discuss how to resolve matters and find the best way forward.
We remain committed to working on closure for this situation with care and respect for everyone involved. Dries and the Community Working Group hope to have a private discussion with Larry in the coming weeks.
Many have also expressed anger over how the information about Larry came to light, and whether there will be consequences for those who participated in gathering information about his private life. The Community Working Group is currently handling this situation through their standard process.
What needs to change
We are fortunate that we do have governance in place. We have never encountered a situation like this before, where a decision this complex had to be escalated and made. This extraordinary situation highlighted areas that we need to improve. From our own observations and what we heard from the community, we identified some specific areas of improvement (but by no means all):
Diversity, equality, and inclusivity issues are complex and require new perspectives and approaches, especially as we assess and improve our Code of Conduct.
It is not healthy or wise to escalate difficult decisions about code of conduct or community membership solely to the project lead.
We need to clearly define our values so that everyone knows and agrees to the context in which the community works together.
We need to figure out how to balance transparency with the need to maintain a safe space and provide confidentiality for individuals in order to resolve conflicts in a way that causes minimal disruption to our community.
There is a lot to address. We will launch several initiatives to find solutions to the problems above. We want to collaborate with the community, the Drupal Association, and outside experts on these efforts. It is important that we take these steps. We value our special community and we want to make sure that it has the right structure and sound governance to remain healthy and vibrant.
We want to begin healing to start right away and that starts with us talking more with the community. We will host online meetings and a meeting at DrupalCon Baltimore on these topics where we can have a healthy dialogue. This will provide community members the opportunity to talk directly with the Community Working Group, Megan, and Dries to propose solutions to some of the governance challenges that brought us here.
Finally, we want to acknowledge this has been a very difficult and unprecedented situation. We realize not everyone will agree with our decisions, but we hope all can understand the care we took in deliberating and the intention behind our actions. We appreciate the community’s patience on this matter, and we look forward to taking these steps in collaboration with you.
When did the conflict resolution process start?
October of 2016.
Who is responsible for what decision?
Dries, as project lead, made the decision about Larry’s role in the project after the Community Working Group escalated to him when they felt they could not resolve the issues surrounding this matter.
Executive Director of the Drupal Association Megan Sanicki made the decision to to remove Larry’s speaking and track chairmanship at DrupalCon.
Larry appealed the DrupalCon decision, which then went to the Drupal Association board who reviewed material provided by the Community Working Group along with Larry’s statements. They upheld Megan’s decision. Dries recused himself from this vote.
What was the process followed for each decision?
The Community Working Group, which is part of Drupal’s governance structure, provided conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries. This is consistent with their existing policy and process.
Dries discussed the information from the Community Working Group with Megan, and some board members. Dries also met with Larry. Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project. That context informed Dries' decision. It is also important to note that Dries intended to have more discussions with Larry to determine what the decision looked like, but those conversations ended when Larry chose to post publicly.
Megan was informed about Dries’ decision and also reviewed the information provided by the Community Working Group. Based on Dries’ decision and information learned from the Community Working Group materials, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.
Larry appealed Megan’s decision to the board, who only have oversight of Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements and upheld Megan’s decision. Note: Dries recused himself.
What information was used to inform the decisions?
(a) reports, both formal and informal, (b) some of Larry's online interactions, both on and off Drupal.org, (c) information provided by Larry during subsequent discussions to get clarity, and (d) information from one or more members-only sites. It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.
Did Dries overrule the Community Working Group?
No, he did not. The process is designed so that the Community Working Group can escalate issues to Dries if they cannot be resolved. This process was followed.
Is the Drupal project “against” people who practice BDSM or other non-mainstream sexual practices?
Absolutely not. We are an open-minded and inclusive community.
Will there be repercussions for Klaus Purer’s conduct?
The Community Working Group is handling this situation through their standard process.
Thank you, Drupal community - I want to express my sincere thanks to everyone who helped me prepare this presentation, sharing their insights into how Drupal fits into bigger and better ways of doing business. The fact that we can all talk about this so openly while competing for business is one more sign of how special the Drupal community is. I’m so glad you all choose to “open source” some of the ways you are succeeding and help the rest of us along the way! And thank you Drupal Camp London organizers for the invitation to give a keynote address at your conference, and thanks to the audience for your presence and warm reception despite the early hour on Sunday.Drupal isn’t enough anymore
10 years ago, just having a website was transformational. But pretty much every business has one nowadays; they're a commodity. You need something especially good looking, functional, or powerful for it to be special. Your skillset--the ability to make functional, powerful websites--was also transformational, a good base for running a business. Now that is largely a commodity, too. Competitors like Wordpress.com, Squarespace, Wix, Shopify, and others offer solid, attractive, basic websites with lots of useful functionality. And they are only getting easier to use with every release.So don’t sell Drupal!
What's the answer? How do you stay relevant and build a sales pipeline today? Don't sell Drupal. Move up the value chain. If you simply receive instructions to put a banner here and a slideshow there--to turn someone else's plan into code and nothing more--you're not where you need to be on that chain.
Placing yourself and your business higher up the value-creation chain means offering more than writing code, more than offering to build Drupal websites. You need to offer more: business value. You might have special insights or expertise. You might be able to solve the problems of a particular industry or vertical especially well it. You could deliver value through something you build with Drupal. Drupal might be one of your weapons of choice for facilitating digital transformation, or marketing, or what have you ... and you have a choice: specialize or diversify ...Keynote Drupal Camp London 2017 - video
- Why hanging out the Drupal slate isn't enough anymore.
- Questions and problems that businesses need help with today ... That you may be able to answer.
- Examples of Drupal-based businesses delivering more value than just Drupal code.
My thanks once again to all of the following people and everyone else whose ideas and actions helped inspire me and help our community:
- Florian Lorétan - Wunder
- Alex Urevick-Ackelsberg - Zivtech / Probo.ci
- Tim Deeson & Christiann Jansen - Deeson
- Megan Sanicki - Drupal Association
- Lukas Fischer - NetNode / OpenInbound
- Dave Ingram And Andrea Rosi - Acquia Lift
- Adrian Rollet & Ronald Ashri - Roomify
- Dominique de Cooman - Dropsolid / Cooldrops
What it was like being part of the Drupal apprenticeship scheme.
Automatically add a Table Of Contents (TOC) to your Drupal pages to make it easier to navigate long articles.
Now I'm working on a new Drupal 8 module "LandingPage Framework". By the fact it's a package of several modules and themes.
Project page: https://www.drupal.org/project/landingpage
I still don't have a stable release but there is a version that you can start to play with and let me know if it worth to continue the development. The module use the power and the magic of Drupal Paragraphs. Paragraphs approach provides beautiful flexibility in content management because you can get any Drupal functionality in paragraph entity and you can set paragraphs on each page in individual order.
The main goal of that package is simplification of Drupal based LandingPage development. I want to provide several out of box solutions that can cover the main cases of LandingPages such as Event page, Product page, Promotional page, CV/Portfolio page etc. But I want to provide extremely unlimited options to customize the page.
Please visit this page to take a look on very simple example of Landing page build with that module:
Also you can get more specific technical information in README.txt
I'm not going to write a long post, because one image better than 1000 words.
Please see a quick screencast in that post, it's only an introduction that allow you to catch an idea. I hope I'll do the serious of screencasts to explain how you can use LandingPage Framework, how you can customize LandingPages and how you can do your best in Responsive Design.
Blog tags Planet Drupal LandingPage Drupal 8 Comments
Did you miss last week's Lunch & Learn Event about open marketing in Ghent? Dropsolid CTO Nick Veenhof explains his quick-and-dirty proof of concept for integrating the Showpad environment with the Drupal CMS.
In the current economic and digital environment, companies are realising that integrated approaches are the future. The time that, for example, sales and marketing act as individual parts of a company is definitely long gone. Luckily, there are plenty of options available for companies to drive business results, such as open marketing platforms.
Recently we have had the honor to present, together with Showpad & Survey Anyplace, a lunch and learn about leveraging these kind of open marketing platforms to boost customer experience. Showpad and Drupal have many things in common, but how do you make sure you are not managing your assets in two separate places - for example in Drupal and in Showpad? As a company, you don't just want to use the right platforms, but you want to use them in the most efficient way.
In preparation for the lunch and learn, we were asked to demonstrate how the technologies that Dropsolid and Showpad use (Drupal & Showpad API) integrate with one another to maximise efficiency.
The first step was consulting Showpad’s API, which is well documented and can be found when logging into their system.
Here's the short version of the demo:
If you're interested in more details, you can watch the extended version on our YouTube channel as well.
Some of the challenges we faced is that Showpad didn’t have a fully featured SDK for PHP. However, there were proofs of concept available that suggested ways of working with the Showpad API. After some exploration I decided to adapt one and contribute it back to github. The adaptation makes the existing, non compatible, library compatible with Guzzle 6 so that it natively works with Drupal 8’s composer dependencies and thus, the Guzzle version that is shipped with Drupal.
After the library was working as expected, I tried to make a quick and dirty implementation in Drupal. Just a warning: this Drupal code does not adhere to the code standards, nor do I recommend you to implement it this way. It is merely proof that integrating the two is not a work of months, but of mere hours. You can find the Drupal code I used at https://github.com/nickveenhof/showpad-api.
Did you miss our Lunch & Learn? Read the complete recap here.Add new comment Header image Teaser image Publish to Drupal planet On
Over the past couple of years I’ve attended quite a few conferences like DrupalCon Amsterdam & Barcelona, DrupalCamp Vienna, European Drupal Days, Drupal Developer Days and SymfonyCon Berlin.
Last weekend I had the opportunity to attend and speak at my first WordCamp. My friend Jam and I spoke about Challenges and Solutions in Getting your Open Source Company to Contribute which we have done many times before.
My colleague Ronald Ashri was also speaking about An AI Bot will Build and Run your Next Site… Eventually, sharing some of our work on chatbots and applied artificial intelligence
We do this because we firmly believe that organisations can achieve far greater success if they work together and improve the world while they do so. As with other conferences I was greeted by a warm and welcoming community. The fact that I’m from the Drupal community didn’t bother anyone and it was relatively easy to find common grounds with everyone I met. So far no surprises, because we all shared a love for open source technology.
That said, I did find that this conference and the people that attended vastly different than what I experienced at any other tech conference to date. The main difference being their focus on diversity, accessibility, inclusivity and user experience. As it turns out, not only WordPress is extremely user focussed and easy to use, so are its conferences. They have gone out of their way to make the conference as inclusive and accessible to everyone. To list a few of the things that stood out for me:
- Creche - You’ve got kids? WordCamp has you sorted. For a mere £5 per child per day your kids are close and taken care off while you attend your favourite sessions. This lowers the bar for people with young children that otherwise maybe wouldn’t be able to attend.
- Life essentials boxes - napkins, sanitary pads, tampons, you name it they’ve made sure they’ve got it. Not just in the female facilities, but in the male facilities as well. An awesome gesture of acceptance and inclusivity for transgender attendees.
- Speech To Text Reporters - Each room had two Speech To Text Reporters that provided live session transcription. One transcribed the current session, while the other corrected any errors in the previous transcription so that it can be used with the session footage that will be posted on the internet.
A post shared by Jeffrey A. "jam" McGuire (@horncologne) on Mar 18, 2017 at 2:33am PDT
But the differences were not limited to the organisation only. The attendees and sessions seemed different as well. Most conferences I’ve attended were mostly visited by developers and most sessions would be about “How to do something awesome with framework A”, “What changed between version X and Y” or “How your application can communicate with API Z”.
The technical sessions didn’t offer me many new insights, but reaffirmed that all software communities face (and solve) the same problems and challenges and the non-technical sessions reminded me that as developers we have a responsibility to our users. The responsibility to ensure that they can access the information our products provide and that no-one is excluded from being able to access that information. All in all WordCamp was highly similar, but also very different.
Yes it’s still attended by developers, but they are not necessarily the majority. I’ve spoken with designers, business owners, entrepreneurs, user experience designers and project managers and heard a lot less technical talk while walking around the venue. The focus seems to be more about “I’ve got a business and want to find out how WordPress can help me make the most of it” than “I’ve always used WordPress and now want to know how to apply it to this new project”.
Looking back at the other conferences I’ve attended I think a lot can be learned from the WordPress community. The session diversity, clear communication and open atmosphere encourage a wide range of attendees, which in turn allows people with entirely different roles to talk to each other and gain a better understanding of each other’s (business) needs and be inspired by their ideas.
WordCamp London turned out to be all that’s good about tech conferences. I like it, sign me up for more!
We’re hiring in Europe at the moment - find out more about working at Deeson.
Last week we attended and sponsored the Drupal Developer Days in Seville where we also had two well attended sessions. Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8 and Advanced Configuration Management with Config Split et al. attached here are the promised slides, as well as a few updates about the modules.What's new in Config Split
As we posted about before, drush supports the Config Split workflow since 8.1.10. In the next version drush will drop the support for its
--skip-modules flag and people using it should upgrade to using Config Split.
Split Storage in Database
Previous versions of Config Split allowed to set an empty split folder which resulted in the configuration to be lost. To avoid saving the configuration into files under version control one would therefore have to set up a temporary directory and save the split there. But with the last development release a separate database storage is used when not specifying a split folder. This allows configuration to be "stashed" in the database for a deployment. A specific export first is still and will always be necessary by design.What's new in UI Patterns
Following a productive BOF meeting at DDD, it was decided to move everything that concerns defining and displaying patterns locally into a separate module.
This will allow for a better and more solid architecture: the main UI Patterns module will be solely responsible to provide plugins and other glue code: it will then be responsibility of modules implementing component library integrations to expose their components using pattern derivers.
Discussion is ongoing at https://github.com/nuvoleweb/ui_patterns/issues/86 and more generic future plans are being dicussed at https://github.com/nuvoleweb/ui_patterns/issues/76Tags: Drupal 8Drupal PlanetAttachments: Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8 Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8
40% of users abandon a website that takes more than 3 seconds to load.
Websites are typically viewed on a large variety of devices with various systems, it may be handheld device or desktops, might run a Mac OS or have Windows but the bottom line is when a visitor is on the homepage of your website or loading items on the e commerce portal or using some other functionality on the website they expect it to be fast and move with the speed of their finger swaps.
What affects Website Performance?
Performance of a website depends on a lot of factors, the performance of the code, factors that have been kept in mind while making that code, number of visitors currently viewing the…
The Crellpocalypse in the Drupal world last week has shaken the entire community. This event and its handling have called our fundamental values and structures into question. We’ve had fights on social media, calls for Dries to step down, and valuable contributors stepping away from the community. I have friends on every side of the situation, but all I can think is: This seems like the perfect time for a singing, dancing, spandexed pageant about the Drupal community.
Why? For those who don’t know, I’m one of the authors of the DrupalCon Prenote, the “pre-keynote” show that kicks off DrupalCon right before Dries’ keynote. The organizer (and my officemate), Jeffrey A. “jam” McGuire and I have been living our own special version of the crisis (Read Jam’s post about taking sides on this here). Our friend Larry Garfield has been an enthusiastic part of the Prenote ever since his first appearance as “Lord Over-Engineering” at Drupalcon Austin. Dries has often played a special guest role, too. With Drupalcon Baltimore looming on the horizon, everything seems to be coming together in one awful moment full of painful reminders – and it’s just when we’re supposed to be cheering for “community.” That awful conjunction is what makes this next Prenote in Baltimore more important than ever.
I have a tremendous respect for how painful this whole situation is for everyone involved. This very public meltdown, which has already done tremendous material damage, is made even more painful by the personal friendships of the key people involved. Klaus, Dries, and Larry have been colleagues for more than a decade. Even if this was only a private falling out, it would have been a painful one. And this is a public explosion. I can’t imagine the emotional strain that each of them is under right now. Internet mob outrage is a terrible experience, made much worse when it comes from your friends and colleagues, directed at your friends and colleagues.
And this is exactly why we need a Prenote right now. Because this is terrible shit that we’re wading through, and the Prenote exists to remind us of why we should keep going. The Drupal community – not the specific leadership, but the agglomeration of people, practices, code, and rules – has a lot that’s worth fighting for. We are the largest open source software community in the world, with a uniquely personal connection to its members. An incredible diversity of contributors from every culture imaginable who, for the most part, manage to work very well together.
The Drupal community is on the leading edge of how a community of this size and diversity can work. No one has ever done this before. Things like our Code of Conduct, Community Working Group, and conflict resolution process, can seem like established and unassailable systems. They aren’t. Go read the version history of those links; we just get a group of people together at a Drupalcon or on video conference to try to figure out how to handle this stuff, and then codify it in writing. We take models from other kinds of communities and try to adapt them, we suggest crazy new ideas and directions. As a community, Drupal actively and aggressively tries to figure out how to make itself more diverse, and less conflict prone. Humanity has never done collaborative communities on this scale before, and the Drupal Community is on the bleeding edge of it all.
The cost of the bleeding edge is that we make mistakes. We set off conflicts, we discover new kinds of obstacles. We muddle through every time, and then in retrospect try to find a better way forward for next time. I don’t mean to diminish the size or importance of any of these conflicts. They can be serious, existential crises.
- When Acquia first formed and started to hold outsize influence, it was an existential crisis. We had to figure out how to handle a conflict of interest in our leadership, and what to do about a (then) totally asymmetrical services market. Acquia is now just one large player of several in the Drupal marketplace, and Dries found a compromise between his interests that has lasted almost a decade.
- When Nate and Jenn forked Drupal into Backdrop CMS, it presented another existential crisis for our community. We had never had such a credible fork from such key community members before. It was the apex of a crisis in the development direction for the whole project. We had to figure out how to address developer experience, how to work with a forked project, and even how to continue working with the forkers themselves. Backdrop is now a normal part of the ecosystem; Jenn and Nate remain important and welcomed Drupal community leaders almost four years later.
- We have had critical tensions, messy relationships, and fallings out with some of our most appreciated developers and community leaders. Whether it’s offense taken at Morten, or outbursts from Chx, these have divided our community and forced us to solve diversity problems that no one else has ever had to deal with.
I could go on. The point is: With each crucible, we the Drupal community must try to learn and build better systems for the next time.
So right now, in the midst of all this anger, this prejudice, and these accusations, I’m here to say: we will learn from this, too. The Drupal community is extraordinary, but we must adapt in order to survive. Losing Larry is a big hit to our community in almost every dimension. This public explosion has been a big hit to us in almost every other dimension. The arguments and animosities we’ve unleashed feel like they will tear us apart. But we must look forward. We must use this event for introspection and carry on as a better, improved community.
Do you think Larry was punished for thoughtcrime? Pitch in and help build a system where the next Larry can’t be treated that way. Do you think Dries and the DA deserve our trust in their decision? Join up and help make sure the next iteration preserves the strength of independent leadership.
The prenote is about why we are here, why we’ve stayed here all these years. Because it’s fun, because it’s supportive, because we love it. Sometimes the best way to start addressing your pain is through humor – and we desperately need to start addressing this.
However you feel about the Crellpocalypse, please don’t leave. Not yet. Stay, and help the community improve. Don’t stay for your job. Don’t stay for Dries, or the DA, or Larry. Stay for the community.
tl;dr: Use a Samba share in the VM mounted on the host instead of using a Vagrant synced folder, and use Drupal VM 4.4's new
drupal_deployfeatures. See the video embedded below for all the details!
I've often mentioned that Windows users who want to build modern Drupal sites and apps are going to have a bit of a difficult time, and even wrote a long post about why this is the case (Developing with VirtualBox and Vagrant on Windows).
As a Drupal themer, it's rare that I choose something other than the Bootstrap base theme for a new project. Besides its quality and popularity, there are some specific technical reasons why Bootstrap is such an attractive option.The internet loves Bootstrap
This makes Bootstrap the top JS Framework worldwide and the second most popular JS library ever used, right after jQuery, which is used across 72% of the web. This means that there are a lot of docs and examples out there to use as a guide.
Thousands of developers know Bootstrap and work with it every day. And because Bootstrap is not Drupal-specific, you can use Bootstrap for your Drupal theme and your other non-Drupal projects. Front-end developers who know Bootstrap can be more easily on-boarded on your project if you go with Bootstrap as a base theme.A Bootstrap theme doesn't have to look like Bootstrap
If you start with Bootstrap and don't customize the styling of your theme, of course, you will end up with that classic Bootstrap look and feel. But the magic of Bootstrap isn't just about how it looks. It is also how it behaves and the way it provides us a solid framework of interactions and components that we can easily customize to the most precise design specs.
Parts of Bootstrap like the grid, breakpoints, messaging and modals are generic components that you can reuse and restyle for your projects pretty easily. As a themer, you can either change these using the Advanced Theme Settings or do these custom on your project.
Advanced Theme Settings
Since Drupal 7, when Bootstrap theme was created with a lot of settings that allow site builders to customize it out of the box and without coding. This is a very common practice across most Drupal themes, but on this specific case, you can "tweak" Bootstrap library specific components that integrate with your Drupal site like the Navbar, Breadcrumbs, Modals and so on.
Even if you are not an experienced Drupal Themer, you can jump into the Settings and start moving things around while customizing your website's appearance and behavior.
Another great feature is that you can set to use Bootstrap library from a CDN, change the library version you want to support and even use different "skins" from Bootswatch.com.
For a complete list of the theme specific settings, refer to the Bootstrap Theme Settings Docs.
Your theming style matters
In 2016, among many other projects, we developed a couple of Drupal 8 corporate websites on top of Bootstrap theme for the Council for Responsible Nutrition and CARTaGene. On both projects, designers were free enough to come up with their concepts without knowing we were going to use that specific framework to make these come to life and get launched.
By the way, did I mention that this site you see right now, is also Drupal 8 + Bootstrap Theme based?Drupal loves Bootstrap
In a previous blog post, I talked about "Drupal Theming and Site Building: 6 Best Practices' and listed a set of criteria to use when considering a base theme for your Drupal project. So here's how the Bootstrap theme measures up against these criteria:
- How many people use it? The Bootstrap theme had more than 140,000 Drupal 7 & 8 reported installs as of March 2017. That is more than 10% of Drupal sites out there and is the most-installed theme for Drupal 8 so far.
- Is it increasing? Over time, more and more front-end developers are adopting Bootstrap, according to the installation statistics from Drupal.org.
- Is it being maintained? Bootstrap theme is actively maintained. Just check the issue queue.
- How do I get started? Well, the documentation is extensive and detailed. There is even a specific website for it at http://drupal-bootstrap.org.
- How secure is it? Stable releases are covered by the security advisory policy.
In Drupal 8, there are templates files for almost every HTML component printed on the page, so you can easily customize the way that Bootstrap classes are applied. This makes it really easy to use the library the way you want. You're not stuck with the decisions made by the base theme developers.The Amazing People Behind Bootstrap
Last but not least, Open Source does it again:
Bootstrap Library Github repo is mainly managed by @mdo and @fat plus an active community of contributors. The library started in 2011 and since then it's been constantly increasing with more and more contributions every day.
For the Drupal base theme there is also a long list of contributors, but I'll give a special mention to Mark Carver, who takes care of leading the project development as the main maintainer and does an amazing work while carefully mixing these two technologies in the best way possible.
If you jump into the issue queue, you will notice that, just because a patch works, doesn't mean it will go into a base theme used by +140,000 websites as an update before being carefully reviewed and tested by the community. Thanks a lot to Mark and everyone else behind the theme.How to Get Started?
If you are new to Drupal:
- Start with Drupal
- Download and Install Bootstrap Drupal Theme
- Take an Intro to Drupal Training
- Take a Drupal Theming Training
If you have some Drupal theming experience I suggest you read about:
- How to Integrate Material Design with Drupal
- Planning Your Drupal 8 Theme: Choosing a Base Theme
- Drupal Theming and Site Building: 6 Best Practices
And if you are an advanced Drupal Themer, we would love to have you contributing back:+ more awesome articles by Evolving Web
How to move fast, be flexible, and maintain high quality while building a digital experience.Tags: acquia drupal planet