Those who try to gain control of their lives are called rebels, criminals, renegades, and they are inevitably swatted down one way or the other. You shouldn't ask me this question.
At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.
This module generates breadcrumbs by combining the menu trail of a OG Content node's OG Menu entry with the node's OG Group menu entry.
Basically this module takes a node and cleverly climbs its menu structure, factoring in an Organic Group's menu too.
Did you have a great time at DrupalCon Los Angeles but want something to show for it?
We are happy to issue a certificate of attendance in PDF format for anyone who picked up their conference badge or signed in at a training.
Simply submit your request via our contact page with the subject "Request a Certificate of Attendance", and be sure to include the associated order number.
This module allows a user to switch between Mobile Version & Desktop Version using ThemeKey.Dependencies
How would you like to present at one of the largest PHP conferences in Europe? DrupalCon Barcelona is coming, and we are actively looking for sessions for our new PHP track.
Unlike the Coding and Development track, the PHP track is all about the larger PHP community. We're not looking for Drupal-specific talks but for sessions about PHP itself (PHP 7 anyone?), about related PHP tools like Guzzle, general PHP leading practices, software architecture, and so on.
Yesterday (May 19), the Louisiana Legislature’s House Civil Law and Procedure Committee voted 10-2 to return HB707 to the calendar, effectively voting it down, at least for the current session. The bill would allow businesses to refuse, in accordance with religious beliefs, to provide goods and services on the basis of a patron’s sexuality.
Described as the protection of “the free exercise of religious beliefs and moral convictions”, were the bill to pass it would preclude the state from taking “any adverse action against a person, wholly or partially, on the basis that such person acts in accordance with a religious belief or moral conviction about the institution of marriage.”
However, hours after the committee’s vote, Louisiana Governor Bobby Jindal issued an executive order in an attempt to accomplish much of what HB707 is intended to achieve. We’re aware that at least some of the bill’s opponents doubt the executive order may create substantive law. We’re also aware that the U.S. Supreme Court may issue a ruling (before its current term ends in late June) that preempts any contradictory Louisiana law.Why We’re Talking About Louisiana
Earlier this year, we chose New Orleans as the site for DrupalCon North America 2016. Section 86-33 of New Orleans’ municipal code explicitly forbids discrimination by public businesses and stores. In much the same spirit as New Orleans’ code, we want to take this opportunity to unequivocally state that no one at any DrupalCon should be denied service, assistance, or support because of who they are or whom they love.
Community. Collaboration. Openness. These are our ethos. At our core, we’re as committed to these values being principles for how we treat each other as we are for how we do our work.
The very nature of open source means contributions can come from anyone. That means muting voices is inconsistent with our values. That means we believe inclusivity is progress. And that means it’s important we speak when our community asks questions about the risk of discrimination.
Along with logistics—such as available event space, and costs—our DrupalCon site selection process has always considered whether we’d be able to truly celebrate the diversity of the Drupal community and the spirit of the Drupal Code of Conduct. We believe, despite the bill and executive order, that we can still create a safe, diverse, celebratory space for our community in New Orleans next year. We’re happy to bring the diversity of DrupalCon to New Orleans, and we’re confident it’ll be a fantastic event.Talk To Us
We want to hear about your experiences at DrupalCon New Orleans—any and all of them. Tell us your opinions, voice your perspectives, and share what you see. In the meantime, comment on this post, or email us, with your questions and insights.
Normally I’m sitting at home in Iowa, rocking the boxer shorts on the couch. The Xbox controller is in arm’s reach. Or maybe I’m tearing up a single track course on my mountain bike. But this week, none of that. This week is different.
It’s DrupalCon, so you know I have to put away the games and pack up the power brick so I can join in the fun. I ran through this quick Q&A about my plan for DrupalCon with Promet's marketing team to help understand my goals for this year's big show.
GDC Europe 2015 officials are still seeking submissions to the 2nd annual European Innovative Games Showcase at the Cologne, Germany show this August. You still have time! ...
While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, I’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let me sum up the development activity of the different branches.
This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.
The stage branch is where code that’s about to be release (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).
If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.
Low (<=1 month):
- Bug fix updates - Feature updates
These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.
Medium (<5 days):
- Security updates that are no critical and not highly critical
These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.
High (<4 hours):
- Critical and highly critical security updates
For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:
- Code deployment with GIT
- Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.
- Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
- Automated tests reduce the time you spend on quality assurance
Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.
For those of you interested in Drop Guard to automate the process as described in this blog post, please sign up for the free trial period so you can test all its features – for free – and get a personal on-boarding.
I was doing some prep recently (gasp no!) so I figured I’d share. Here is a base located on the ethereal plane for your high magic adventures.
Reasonably close to the center of the bizarre geometry of the planes, the city of Media is a large trading center and rest stop for dimensional travelers of all sorts.
1. The Rock: A huge rock floating in the gray fog of the ethereal plane. It’s surface is rough and blasted and full of all sorts of pockmarks, caves and hidey-holes. While smuggler’s caches, monster lairs, and the like almost certainly contain riches, few venture out of the safety of the city.
2. Tear of Yggdrasil: A massive teardrop shaped piece of amber, embedded into the floating rock. It is assumed that it must have fallen off of a world tree somewhere. How it ended up embedded in a rock floating through the ethereal plane is anyone’s guess. In ages past, a palace was carved into the giant piece of amber. Even older is the spiraling pathway cut into its side leading to the tip which has been carved into a flat plane with upthrust spires of amber like some sort of primitive temple.
3. Media: A large hex shaped city surrounded by a thick stone wall. In the center of the city stands The Anchor, a huge pylon carved with glyphs and runes that helps keep the rock from wandering too far or from rolling to either side. Six main roads radiate from The Anchor to the corners of the wall. The wealthy of the city mostly dwell near the palace, with tradesmen and the middle class centrally located. The areas nearest the wall mostly house farmers and shops that cater to their needs.
4. Temple of the Rejoining: A few decades ago, a group of priests arrived in Media. Claiming the Tear of Yggdrasil was a sign from their god that their pilgrimage was over, they petitioned the noble houses of Media for a wing of the palace to set up their temple, but were rebuffed. Undaunted, they gathered enough money to erect a second wall outside Media proper and built a temple there. While they wait for their god to rejoin them at their temple, they minister to the people of Media.
5. Mushroom Plantations: Beyond each of the gates in the city wall is a raised road leading to a small hilltop fort. Below the roads and forts are a sticky morass of imported earth and garbage and waste collected from the city. Great forests of mushrooms grow in these mires tended by the poorest residents of Media. Mostly housed in the forts, a few of these farmers and loggers reside in the outskirts of the city proper. The forts also hold a small number of soldiers who protect the workers and ostensibly serve as a defense force for the city.
Jim Birch: Using Drupal's Environment Indicator to help visually manage Dev, Stage, and Production Servers
There are days that I work on half a dozen different websites. I'm sure some of you are in the same boat. We make client edits and change requests with rapid effieciency. We work locally, push to staging, test and review, then push to the live server and repeat. I would be remiss in saying that I never made a change on the live or staging site accidentally.
The Drupal Environment Indicator module allows you to name, color, and configure a multitude of visual queues for each of your different servers, or other variables, like Git branch or path. It is very easy to install, and can integrate with Toolbar, Admin Menu, and Mobile Friendly Navigation Toolbar for no additional screen space.
Once installed, set the permissions of the roles you want to give permission to see the indicator. You can adjust the general settings at /admin/config/development/environment-indicator/settings
While you can create different indicators inside the admin UI, I prefer to set these in the settings.php files on the various servers so they are not overidden when we move databases back from Production back to Staging and Dev.
Modules Unraveled: 135 Writing the Book Drupal 8 Configuration Management with Anja Schirwinski and Stefan Borchert - Modules Unraveled Podcast
- What’s it like writing a book for a piece of software that isn’t even officially released yet?
- How long did the writing process take?
- Packt publishing sent us a proposal to write this book in December of 2013. We got started quickly, sending them an outline of the chapters and an estimated page count in the same month. The original estimated page count was 150, it turned out to be around 120. We received a pretty strict time line, having to finish a chapter every two weeks, starting in December of 2013.
- We managed to finish most chapters in two weeks, but some of the longer ones took a little longer since we also started one of our biggest projects we had had until then, also in January. That was pretty tough because that project took up way more than a regular full time job, so we ended up having to write all of the chapters late at night and on the weekends. In May, all of our chapters then went to the editors and we didn’t hear back from the publisher for a really long time.
- We also told them that we will have to rewrite a lot of the chapters since there was so much work in progress with the Configuration Management Initiative and they were changing a lot about how it worked, like going from the file based default to the database default. I think it was in January of 2015 when chapters came back with some feedback and we started rewriting every chapter, which was pretty painful at the time. We were able to update some of the documentation at drupal.org with the changes we found. It felt good to contribution at least a small part, when with our project and the book we had no time left to contribute code to Drupal 8 like we usually do.
- We spent around 40 days on the book between the two of us.
- In December, Packt asked the first publisher to review the book. We had recommended them one of our team members at undpaul, Tom, who has a similar amount of Drupal knowledge as Stefan. We really wanted to have someone from CMI to review the book, like Greg Dunlap. They had turned down reviewing the book after the first chapters were written, because too much would still change. Then after the changes went in we kept recommending Greg but I never heard anything back, maybe he was busy or they didn’t bother to ask. At the beginning of this year they told us the book was planned to be published by March. We recommended waiting because we didn’t expect a release candidate before the European Drupalcon and we would have rather had someone like Greg take the time to review, but Packt had another opinion :) Since most of CMI changes were finished, we didn’t feel too uncomfortable about the time of publishing, and it was also kind of nice to finally be done with this thing :) So it took a little over a year from start to finish. It was published on March 24th.
- Do you expect to need to rewrite anything between now and when 8.0 is released?
- What do you cover in the book?
- We start of with a basic introduction to what Configuration Management in Drupal means, because it is a thing in Software development in general, that doesn’t usually refer to what it is in Drupal, where it basically just means that configuration is saved in files which makes deployment easier. In the first chapters, we make sure the reader understands what Configuration Management means and why version control is so important. We mention some best practices and then show how to use it for non-coders as well, since there’s a nice backend non-technical folks can use, even if you don’t use version control (which of course we don’t recommend). We also have a part that describes how managing configuration works in Drupal 7 (Features!) and then dive into code examples, explaining schema files, showing how to add configuration to a custom module, how to upgrade Drupal 7 variables to the new system and cover configuration management for multilingual sites.
- Who is the target audience of the book?
- Why did you decide to write about Configuration Management?
- We have used Features to deploy configuration changes for a very long time, I don’t recall not using it since we started the company 5 years ago. We have talked about it at several DrupalCamps and Drupal User Groups and always tried to convince everyone to use it. We were really excited about the Configuration Management Initiative and thought it was a very good fit for us.
- Before we started recording, you mentioned that there is a companion website to the book. Can you talk about what content we’ll find there, and what purpose that serves?
- Are you building any sites in D8 at Undpaul?