Live today by what truth we can get today and be ready to call it falsehood tomorrow.
Out of the box, Drupal does a good job of providing securely written code. For instance, core modules sanitize user input and interactions with the database use Drupal's database API to prevent SQL injection attacks. However, Drupal doesn't enforce strong passwords by default which can lead to a scenario that is not too hard to imagine.
Let's say a new content editor named David has been hired. To quickly get him up and running he is given the username david and a password of david123. David logs in and gets to work and doesn't bother changing his password - after all, david123 is easy to remember! (This scenario may seem contrived, but I fear it is all too common.)
It's not unusual for Drupal themes to add an author's actual username into content. An attacker can just scan the text or source code and find something like this:<span class="username" about="/user/88" typeof="sioc:UserAccount" property="foaf:name">david</span> So...
- A quick glance and the attacker knows there is a valid username david
- The attacker tries logging in with some common weak password patterns (ex. david1, David1, david123) *
- ...and Bingo! With david123 the attacker has logged in and the site has been compromised
If the compromised user has admin privileges or can use a WYSIWYG editor that allows PHP execution (which we never recommend), then it's possible the whole server is at risk. In a nutshell, security's not just about depending on securely written code; enforce strong passwords from the start. (While you're at it, make sure admin pages are served over SSL.)
Try the following:
- Password Policy module (enforce strong passwords and hey, expire them too?!)
- Use a preprocess hook or edit your template files to remove the display of user info (Hint: sometimes themes will also add the username as a class class="author-david")
- Secure Pages module (force admin pages to be served over SSL)
There is plenty more you can do, but using SSL and having a strong password policy without advertising your usernames is a solid start. Even better would be to explore two-factor authentication, but we'll leave that for another blog post.
* Yes, Drupal will lock the user out after 5 unsuccessful login attempts, but that in itself means an attacker can easily lock users out of their accounts.
Did you create your website 5 or 10 years ago? It’s time for a redesign. According to a recent Pew Research Center study, 64% of American adults now own a smartphone, up from 35% in 2011. Forward thinking marketers understand that web is far more customer centered than ever. Web traffic has changed, but has your website?
1. Your bounce rate is high
Bounce rates show how long someone stays on your site after viewing one page. If your bounce rate is over 50%, that means 50% of the traffic to your site leaves without navigating deeper into your content. There are a variety of reasons why your bounce rate may be high (including bot traffic), but one key factor is information architecture. If you site was not created with the user in mind and designed in a way that allows visitors to intuitively navigate from page to page, that is likely the number one reason your bounce rate is suffering.
2. Your site isn’t responsive
Can users access your site from any device? The digital consumer, according to a Nielsen study, spends more time surfing the web from a smartphone than from a desktop or laptop. Your site should be responsive to the size and shape of the screen on which it’s viewed. These days, web developers can code a single site to work on every platform. When a mobile visitor comes to your page and sees the tiny font of a nonresponsive site, they’re going to bounce. Peace out. Word to your competitor.
3. You’re pivoting
Plateaus happen. Deciding to change your business or organization can be tough, but once you’ve made the decision, it’s time to update your website. You want the world to see your company as something new, and a few small changes to your site are not enough. Revamp the look and feel of your site--give it a facelift and let your new venture shine through.
4. Your content is outdated
If you haven’t updated your site in the past few months, chances are your content is outdated. Keeping content up-to-date and relevant to your messaging can be challenging, especially if you have a small team, but updating your entire site can give you the opportunity to look at your content with fresh eyes and re-evaluate your content strategy. A content audit, often performed by your web development company of choice, will allow you to identify the content on your site that reaches clients, and the content that is floundering. Removing or restructuring old content is a great way to increase traffic to your site.
5. Your clients (or your team) have trouble using it
Design. It’s your top priority. Think of a website like a house for sale. Is there curb appeal? Once you’re inside, is there an obvious path through the house? Same with your website. Users should be able to intuitively navigate through, find what they are looking for, and settle into a nice comfortable chair. Build your new site only after careful research. Observe how people use your current site, and see through your visitors’ eyes. Ask questions. Let people complain about what’s missing or difficult. Build a beta of your new site and repeat the process until you’ve worked out the kinks.
Thinking about updating your website? Feel free to reach out and let us know how we can help bring your site up to date with your goals.Terms: site updatesite upgradeDesignDevelopmentDrupal Planet
Node teasers are broken and most developers don't even know it, meaning it can be a pain for content creators. If you're building large websites that constantly pump out content, then read on to learn how we fix Drupal's teasers with one simple module...
Modules Unraveled: 143 The Role of Features in Drupal 8 with Mike Potter - Modules Unraveled Podcast
- Let’s start off with the basics, if you don’t mind. Can you give us the 30 second pitch for what Features is? I’m sure there are people listening right now that don’t use Features regularly.
- What kind of data or configuration can you package into a feature?
- What does Features do well?
- Where does Features fall short?
- What are some of the things people currently use Features for, that perhaps it wasn’t intended? Are there issues as a result?
- If you don’t mind, I think it’d also be helpful if you could explain what CMI is in Drupal 8 so that when we compare the two, everyone knows what we’re talking about.
- What does CMI do well?
- Where does CMI fall short?
- With CMI in core, where does Features find its place in Drupal 8?
- How will we use Features differently in D8 as compared to D7?
- Talk about config packager
What was your experience building Features in Drupal 8? Did you get to port code from D7, or was it all from scratch? Is Drupal 8 as “hard” as some people are claiming?Questions from Twitter
- Thomas Svenson
Just want to say I like the direction #Features is taking for Drupal 8. Especially that it is not needed on live site. #UXwin
Drupal is a very popular Open Source CMS solution. According to BuiltWith, 14.2% of top 10k Websites that use a CMS use Drupal. The total number of Drupal websites is more than a million. Popular and well known sites such as Whitehouse.gov, Nbc.com and Weather.com are using Drupal.Drupal is popular among many different website verticals.
Source Drupal is not just a CMS
The functionality of Drupal exceeds what is defined as a CMS. When describing Drupal as a CMS within the Drupal community, I often get corrected that it is in fact a CMF (Content Management Framework). It means that Drupal can be used for other purposes such as simply working as the backend system for entering content, and then displaying the content in a completely different way. This could be for example a mobile application that gets its content from your Drupal website.Drupal is fast to develop
Building the basic functionalities of complex sites often requires no custom code. This makes Drupal fast to develop. Handling content with different fields which can contain whatever data you as content creators want and being able to change these in a very quick way is Drupal's one of main strengths. Building your own “content type” takes minutes and not a single line of code.
The Custom code comes in play when you need something very specific and is often only used to add to alter or add to already existing code. This makes Drupal into a great tool for creating a Proof of Concept quickly. If you have a complex website that you need built, it is very likely that Drupal is the fastest way to provide the basic functionalities. In a short time you could already be demonstrating the main functionalities to your shareholders or peers.Drupal has a large number of contributed modules
Drupal Modules are free to use and generally of high quality. Drupal's functionality can be extended in using contributed modules. A great Drupal website is always a combination of the best modules for the specific purpose of the website. Joomla and Wordpress have paid module ecosystems and many of the good modules you have to pay for, with Drupal they are all freely available on Drupal.org. However not just everyone can release anything to Drupal.org which is where all the contributed modules live. To release a module, developers have to go through a process where your code is evaluated by long-term Drupal developers this goes a long way to keep the standards high.
There is a large number of modules that we as Drupal developers and enthusiasts find very standard, but are missing or hard to configure in other CMS’s.The main contributed modules that give Drupal an edge
Views gives you the ability to create nearly every kind of display for your content. You can display only the parts of your content that you want, and modify it to your liking. A view on your website could be for example “Related content” or “List of latest blog posts” but it could also be something more complex like a Masonry layout for your front page.
Views allows your content can be then displayed in any way you want, from shiny slideshows to traditional HTML tables. With Views you can also build complex search systems without a line of code if that is what your project needs. There is a large number of sub-modules to the Views module that allow you to extend the functionality further.
In the upcoming version Drupal (Drupal 8) this contributed module will have moved to be a part of the core Drupal installation.
Example: In this image there is a view on the left displaying the Articles, and another on the right showing the listing.
Features is a module that is more for the developers. It allows you to store your configuration for Drupal in the code base. This allows you to export configuration from different Drupal setups. It’s a part of every well thought after Drupal build.
If your goal is an e-commerce site, commerce is your go-to module for Drupal. When it comes to ecommerce sites, Drupal is a great tool. Especially when your plan is to build a site where you will drive users with content to your site.
You could have your content in Drupal and use the previously shown Views module to relate interesting products to your users. For example you have an article about “Tuning a guitar” with a tag “tuning” and a view on the page that shows products with the same tag. Drupal commerce provides everything you would need in a ecommerce solution, from cart to multiple payment gateway integrations, and all this for free.
Or to think of it as the other way around, you can easily use Drupal to create a Paywall site that allows users to access your content only after they have purchased a membership.
To test what Commerce can do for you, check out the demo site: http://demo.commerceguys.com/
Rules is a module that allows you to initiate any action when something happens on your website. Let's say a user submits a form, and you want to send an email to that user. With Rules you could implement this. But rules doesn't stop there. You could even add numerous actions to that same submit action, for example you could on top of sending the email give the user a message on the page that “Form submitted” and redirect the user to a page you want them to go after submitting a form. All of this without writing any custom code, and done in the user interface.
This module works well in conjunction with other modules, such as the pre-mentioned Commerce module. With the rules module you could create simple actions that affect product pricing for different user roles, or for example to create sales pricing. The possibilities are endless.
User clicks on a link -> Rules reacts by doing an action (send an email)
- Display suite
Display suite allows you to create specific display modes for your content. Think about how you would want a teaser of an article to look like. You could specify it to look exactly like you want it to and then re-use the display mode in every parts of your site. And by just updating the display mode, all of your teasers will get the new layout. Compare this to having to go through all your layouts every time you're doing a change. A time saver for both developers and themers when working on complex websites.
To give an idea of the extent where Drupal has gone with its contributed modules I will list 5 modules that are very good for their own specific purpose. It is very likely that one or more of these will be used in a Drupal site you're browsing.
Everyone hates spam. Honeypot kills the spam. It’s that simple. If you’re running a website with user-generated content, you’re going to have to handle this issue. This module does it for you without the annoyance of Captcha.
Drupal doesn't come out of the box with a Wysiwyg. This module solves that problem. It’s a plug-and-play module and by just enabling it you will have a fully functional Wysiwyg on your hands.
- Google Analytics
Adding your Google analytics code to your website couldn't be more simple than it is with this high quality module. Just add your UA code and that's it. It also allows for complex customizations if that’s what you need.
Does your website need a map to show locations on? If so getlocations is one of the great solutions Drupal provides to solve all of your location based needs. It supports custom Google maps markers and different map providers.
A very important part of any website is the URL. A good URL structure helps your site to rank better on google, and also to be easily navigatable. That is what the Pathauto module is for. It creates clean, keyword rich URL’s.
All CMS’s have implemented different solutions for this problem, but I believe Drupal's way to be easily the most configurable and complex the same time. With the pathauto module you can simply type in a default “path” for your content which could be for example: content/What gives Drupal the Edge? which will print out as www.yoursite.com/content/title-for-blog. This can be modified to your hearts content in the user interface without any code needed.
Social media is more important than ever. Everyone wants their content to have a chance of becoming viral, your metatags have to be in order. Metatags and configuring them has been an issue as the defaults are constantly improving and changing. Drupal has a great solution for this, which is the metatags module. The metatags module works in a similar way to the before mentioned pathauto module. You can set simple defaults, or go into really complex setups if you desire to do so. The module supports all of the major social networks such as Facebook and LinkedIn (OG tags) and Twitter (Twitter cards). The configuration is very easy and can be done by virtually anyone who has a basic grasp of how they should work.
The Drupal community is large. There is over 1 million users on drupal.org with almost a 100,000 of those actively contributing. In general the users in the community are highly skilled. A huge percent of the developers working with Drupal are actually doing it as their primary occupation. This makes the community very professional and helps to keep the high standards of contributed modules and projects.
It is fun being a part of the Drupal community. Around the world there are numerous events that are hosted in different countries that attract thousands of Drupal enthusiasts to collaborate, network and code together to make it even better. Being a part of these communities is great for everyone involved.Security
When you work with Drupal, you don't need to find security issues from your code yourself. There is a strong security focus within Drupal, and there is a team that continuously reviews contributed code. This keeps the costs of upkeep on a Drupal site low compared to custom platforms. I’ve ran into dozens if not hundreds of issues that I’ve figured out by going through community created patches which I’ve then applied to my Drupal sites. Also the modules you use constantly receive updates with new functionality you can decide to use if you deem it to be important for you.Conclusion
The very high quality and a large of contributed modules, the free support you get from the community, great tools to structure and display content and fast build times on complex sites websites;
All of this is what makes Drupal the ultimate open-source solution for mid/large websites.drupaldrupal planet
While I was mentoring GSoC 2015 Hawk Auth project, we wanted to test the project in D8 sandbox often. Simplytest.me doesn't help here, because Hawk Auth uses Composer Manager to download extenal PHP library. (Another project using this set up is Commerce for D8.) There is an issue of supporting Composer in Simplytest.me queue, but it hasn't been followed up.
Therefore, we tried to use Docker to spin up a new Drupal installation. It was very fast and simple. Below is the documentation:
Step 0: Install Docker
Step 1: Spin up a database
docker run --name drupaldb -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=drupal -d mariadb
(here we created a docker container called "drupaldb" using "mariadb" image, then we created a database "drupal" and set root password to be "password")
Step 2: Spin up Drupal 8
docker run --name d8docker --link drupaldb:mysql -p 80:80 -d drupal:8.0.0-beta13
(here we created a docker container called "d8docker" using "drupal:8.0.0-beta13" image, then used port 80 on localhost for access and linked to the database container we just created)
Done. Now, you can open localhost or 127.0.0.1 on your browser to install Drupal the database. If your localhost port 80 is being used, then you can change this section "80:80" in the above command to something like "1234:80", which will use port 1234 on your localhost.
Step 2.1: if you need to access the terminal of this website
docker exec -ti d8docker bash
(once you in, execute "export TERM=xterm" in your terminal for using text editor)
(if you need to install other tools, execute echo "Find-a-Close-Debian-Repo-URL-FOR-YOURSELF" > /etc/apt/source.list)
Step 2.2: if you want to read the log
docker logs -f d8docker
Step 3: Cleaning up
docker stop d8docker
docker stop drupaldb
docker rm -v d8docker
docker rm -v drupaldb
Drupal is a lot of things. It’s a platform, a CMS, software, and code. But here’s what Drupal is most of all: community.
We started hosting monthly sprints in order to pool our resources and give back to the open source community. We’re committed to maintaining our contributions that Drupal users rely upon - heck, we rely on them, too - and we owe it to this community to keep improving upon them. Not only that, but our own internal community here at ThinkShout grows as a result. There’s a camaraderie that develops when we all rally behind one cause, and it shows after every sprint in the way we collaborate on our projects.
This month, we focused on one of our most widely-adopted Drupal modules: Entity Registration.
There are nearly 10,000 sites currently using the Entity Registration module to power event signups. The module is supported by an active group of 43 developers who have contributed over 500 commits to the project. If you registered for a DrupalCon prior to this year, you’ve probably used this module. It’s been the canonical registration tool in Drupal because of the balance it strikes between ease of use and flexibility. We’ve built everything from simple signup forms for small, free events, to complex paid event registration workflows with tens of thousands of registrants.
The sprint resulted in a much-needed release of the Entity Registration module: 7.x-1.5. We knocked out a chunk of issues, added a bunch of nifty new features, and paved the way for some even bigger new features. Additionally, we made our initial port of Registration to Drupal 8 on a completely different branch.
What’s more, we had our interns on hand to participate in their very first sprint! Daniel even managed to make eight commits to Entity Registration. It was one of the most exciting Thursdays we’d had in a while. And that’s saying something, since bowtie Thursdays are pretty epic.
For this sprint, we broke into three teams. Team one focused on resolving the highest priority items in the issue queue, team two worked on building out a roadmap for upcoming features in the 2.x release, and team three began working on the D8 port.
Team one resolved over twenty issues in the queue and triaged nearly double that. I sat down with developers Gabe Carleton-Barnes, Jaymz Rhime, and Greg Boggs to discuss this latest sprint in detail.
Gabe, your team was responsible for tackling the issue queue. How did you and your team divide and conquer those tickets?
Gabe: We started with the most important issues, and items that were prioritized in the issue queue already. We distributed them among our team, reproduced the issues, and came up with solutions. We had a lot of newer ThinkShout folks working on the queue, and our interns were on hand as well to help. It was a great opportunity for them to to get in there and give some feedback to the community. We were able to also get feedback from the community about these issues, evaluated their proposed solutions, and if they made sense, we implemented them as part of the fix.
What were some of those bigger fixes?
Gabe: One of the more noteworthy had to do with anonymous registrations and permissions. Each time you create an event, you can allow people to register in different ways. Registration by email address is one way, so anonymous users can provide an email address and not necessarily need to log into the site. But in order to make that work, you had to allow anonymous users with a permission called "allowed to register other people." It logically worked at the time, but it was a little confusing for people setting up the module for the first time. So we took that out, which also provides a bit of a security buffer so you don’t have a bunch of anonymous users signing up with several different emails.
Let’s shift gears and talk about features. It sounds like there are some exciting changes in the works for the Entity Registration module.
Greg: We started the process of refactoring entity registration in a big way. I created a roadmap for the 2.x release of the module, which is important because there are contributors active in the Drupal community that are contributing to our module. So if we’re going to commit large chunks of new features to the module, it’s important to describe those to the other active developers working on the module so they know what’s coming and can participate in those changes.
Jaymz: We developed a plan for implementing the biggest new features, and we’ve made some headway in service of those new features. We’re hoping to have these features ready to roll out in a month or so.
Greg: There are two big features we’re prioritizing right now. The first is making entity registration work with any kind of entity, which is important for Drupal sites that use more than just "users." This is a massive change that will drastically affect how this form will work. Right now, only users can register for events. With this feature, any entity will be able to register, whether it’s a contact, and email, etcetera, which is going to give both site owners and event registrants more options for both managing and registering for events. The second is the implementation of multiple registrations on a single event registration form.
Jaymz: Both of these are features that have sort of worked in the past, but needed some fine-tuning. So now we’re adding true support for both of them.
Greg: So many people use this module, and many of them are new to Drupal, which means this module has a very active issue queue. One of my top priorities is to respond to these issues, which I did during the sprint, ensuring people knew where to go for more support, reviewed proposed solutions, and so on.
Jaymz: We really appreciate the support from the community, and we owe a lot of this module’s success to their contributions. It takes a village sometimes, or in this case, a team sprint, and Entity Registration is proof of that.
There are a lot of exciting things in the works for Registration. We can’t thank the community enough for their support of this module, and we’re looking forward to bringing it to Drupal 8. In the mean time, we hope you’ll give 7.x-1.5 a whirl and let us know what you think! Be on the lookout for updates about our progress and the new features coming in the near future.
A simple module for using RRSSB in Drupal.
It can be used like this:
For us, DrupalCon is the most fun time of the year. There’s nothing better than getting together with our friends, colleagues, and community to work and celebrate together.
While the sessions, BOFs, and other work-focused moments are indelibly important, the bonds we build and the friendships we make are just as critical to the continued growth and success of the project. That’s why we'd like to invite you out to Trivia Night.
Michelle Krejci (craychee), engineer at Palantir.net, joins Mike Anello, Ted Bowman, and Ryan Price to talk about grand Belgian statues, things in Chicago that only tourists love, why we're all confused about the thing called "continuous integration" and all the tools and technologies around it. Michelle breaks it all down for us and provides a reasonable entry point for beginners. Recent Drupal news, picks of the week, and five questions round out the rest of the episode.
Everyone bills hourly, and as it turns out just about everyone hates it. This process makes clients feel cheated, and agencies exasperated.
At the end of the day there's usually at least a hint of disappointment in both how long it takes to get paid, and/or how much it all came to.
You come to expect that you are going to be disappointed 99% of the time. So most of us just cross our fingers and hope the project doesn't become hell for everyone at the end of the month.
But this makes zero sense. There is so much more we can do to change the way that we run our consultancies, and so this summer I began experimenting. (Note: Blocks for September are starting to book, so if you think this is for you at all, get in touch.)
I've considered block billing for years, but thought transitioning would be some dramatic ordeal. You know tell ALL the clients, change ALL the forms, and it was some work...but the start...the start was so so simple...
A little column in a table of rate options. I'd heard that competing against yourself was a good thing. So, I decided to list three price options for some new potential clients. Block billing just happened to be one of them. I even did this for a well established client, and guess what it worked there too!
The client ALWAYS chooses block billing. It's been kind of awesome. Because it turns out client's like to have a general idea of what they're getting too.
Would this work if I only offered block billing? Probably, but even then I would give options, control is such a fleeting thing on a web-project for clients give it anywhere you can.
Would this scale? If you scale the size of the block, say a week, this works well for even larger agencies. In fact I learned it from watching @brenandunn who's advice is aimed at consultants, but scales quite nicely to agencies as well.
The goal of block billing is to make the focus on the features of the project not on the time spent. This way the website, the users, you, AND the client all win. If the focus is only on the time spent, it's very easy to lose perspective quickly.
So here's how it works, and the awesome results.Read more
You just bought a beautiful new home. You spent a lot of money, so you want to get the most out of your investment by looking for opportunities to make it income-producing while residing in it. Along comes a friend with a novel idea. A local manufacturing company exceeded its monthly waste allotment and needs a new location to store its surplus HAZMAT material. This company will pay an extraordinary amount of money – $1,000 per barrel per month – to take up what would otherwise be unused space in your basement.
So... would you do it?
The potential of a massive passive income stream can be enticing. However, in this case, the risk you’d take on is enormous. What happens if the barrels are faulty – or they leak? What if they drop in transit – and crack open? What if there’s a natural disaster – a fire or a flood? How widespread might the damage be? Would you face fines for contaminating the environment? What about the resell value of the house? And if the waste leached out, how would it affect your family’s health?
The fact is that the possible damage is so severe that most cities, states, and counties forbid HAZMAT storage in residential property.Credit Card Processing
Storing, processing, and transmitting payment card data also comes with potential risks and rewards.
On the one hand, adding an eCommerce component to a website can open up a sizable income stream, which the merchant can then use to grow the website or offset the initial build cost. However, the effects of credit card breach can be fatal to a business: customers may lose trust and take their business elsewhere; credit card companies may lose money from fraudulent charges; and the merchant may be required to pay for significant upgrades without the budget to do so – as well as face fines as high as $200 per credit card transaction affected.
Similar to managing hazardous materials, a single breach wipes out gains and even leaves the merchant stuck cleaning up the mess.
Mostly a feature module which brings in the concept of "Friends" and also blocked users. This is for use within the Comstack circle.
Continuing from last week, the primary focus for me this week was to focus on the permissions for users and their credentials as provided by Hawk. This involved the following:
- Allowed admins to restrict individual role’s maximum number of credentials
- Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
- Allowed administrators to make exceptions to certain users=
Allowed admins to restrict individual role’s maximum number of credentials
For Hawk, I have added a configuration form in Admin > Configuration area which allows admins to specify a maximum limit for every role having permission to have Hawk credentials, they can specify 0 for a role to have no limit. In case an user has multiple roles with limits, maximum limit will be used for that role.
For example: There are four roles: A, B, C, D and a user has: A, C, D. A has no limit, B has 2, C has 3 and D has 5. Since the user has A which has no limits, the user will also have no limits to the number of credentials they can have.
Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
I have split each CRUD permission into it’s own separate entity and added a separate fifth permission which grants admin access to all hawk credentials and settings. The CRUD permissions apply to individual user’s credentials. An admin can restrict a role to have credentials but not create them, allowing creations only by administrators. They can restrict them the ability to edit their revoke permissions, but add credentials and so on so forth. Hawk admins automatically get all permissions as well as ability to view and edit other’s credentials.
Allowed administrators to make exceptions to certain users
This was the most time consuming part of this week’s sprint, any user having hawk administrator permission can now add, edit or delete any other user’s hawk credentials even if that user doesn’t have the required permission and the admin can also override the limit set for the roles. For example, if a user cannot delete credentials they can request an administrator to delete one for them or if a user cannot add credentials they can do the same. The reason it took quite a bit of time was because this required a little refactoring in the way Hawk handled forms and permissions. Previously everything was assumed to be in the context of current logged in user but that required changing to the user whose profile was being viewed.
For now that’s it for the week, next week I’ll focus on further improving the module. Maybe this time I’ll finally get the chance to implement unit tests unless some other idea pops up.
Thank you for reading!
It's only a matter of time. You encounter a bug in Drupal core or a contributed module, search the web for the issue you are encountering and more often then not, you are not the first person that has encountered the issue. You find an issue on Drupal.org and if you are really lucky, there is a viable patch associated with it. Hopefully this patch will one day make it into a release, but this won't slow you down. You apply the patch, it fixes the bug and all is well with the world. That is until it comes time to this contrib module. Maybe a different developer is performing the update, or maybe it is just you months (years?) later. You don't neccesarily remember that you previously patched this specific module and when you update it, you unintentionally overwrite the patched fix, reintroducing the bug.
To lessen the chances of this occurring, we want to be able to track all of the patches that have been applied, and ensure that they are re-applied every time the underlying code has been updated.The Old Way
In the past, we manually tracked patches in a directory at the top level of our git repository. Within this 'patches' directory, we have a folder for Drupal (core) patches and a folder for each contrib module that has had a patch applied. When a module is updated, it is up to the developer to consult this directory structure and identify any patches that may need to be reapplied. While this is technically a viable system, it is easy to see that there is at least one major flaw. It is not uncommon for a developer to simply forget to check the patches directory.Drush Patch File
Recently, we have begun to utilize Drush Patch File to improve this workflow. Drush Patch File endeavors to simply document and track what patches have been applied, and automatically reapply patches when a module has been updated.
With Drush Patch File, our legacy 'patches' folder still exists, but we replace its contents with a patches.make file similar to the one below:; Required attributes api = 2 core = 7.x ; Core patches. ; D7 Backport: theme_table() should take an optional footer variable and produce <tfoot> ; @see https://www.drupal.org/node/1892654#comment-6956588 projects[drupal][patch] = "https://www.drupal.org/files/Add_tfoot_support_to_theme_table-1892654-1.patch" ; Remove Html::resetSeenIds() call during form processing ; @see https://www.drupal.org/node/1831560#comment-7629461 projects[drupal][patch] = "https://www.drupal.org/files/d7_form_html_id_1.patch" ; Contrib patches. ; devel ; Prefix tables in dpq() output ; @see https://www.drupal.org/node/2330035#comment-9105857 projects[devel][patch] = "https://www.drupal.org/files/issues/2330035.1-dpq-prefix-tables.patch" ; Fix incrementing invalid property in _hive() ; @see https://www.drupal.org/node/2332361#comment-9118425 projects[devel][patch] = "https://www.drupal.org/files/issues/2332361.1-hive-object-corruption.patch" ; entity ; entity_property_default_render_value_by_type() throws warnings on list properties ; @see https://www.drupal.org/node/2237141#comment-8669433 projects[entity][patch] = "https://www.drupal.org/files/issues/2237141.1-list-warning.patch" Getting Started
- Clone the Drush Patch File repo into your project at 'sites/all/drush'.
- Create a patches.make file as detailed above, preferably outside of your docroot in a 'patches' folder.
Point drush to your patches.make file by adding the following line in '/sites/all/drush/drushrc.php':
$options['patch-file'] = '../patches/patches.make';
Drush Patch File's README provides detailed instructions on how to add new patches, check patch status, and apply all specified patches.The Best Part
The best part of Drush Patch File, besides managing the tracking of all of your patches, is that it will reapply your patches automatically when you update a module!drush up devel > The following indicates that the patches were successfully re-applied. Install location sites/all/modules/contrib/devel already exists. Do you want to overwrite it? (y/n): y Project devel (7.x-1.5) downloaded to sites/all/modules/contrib/devel. [success] devel patched with 2330035-1.patch. [ok]