Today while documenting all the modules that we've removed from core in Backdrop CMS, I realized that we've also been removing a lot of other cruft that's making the system lean and mean. I'd like to document all that for you here (but mostly for myself, for future reference).
Here's the list of modules that have been removed from core:
In this month's Drupal Watchdog magazine Nate & I wrote an article about Backdrop CMS. In that article I described all the people who work with, in, and around Drupal as the "Drupal ecosystem". I'd like to describe here, in more detail, how this ecosystem breaks down - along with some numbers and figures to back up our claims.
I love working with Drupal. I feel fortunate that I found a software and a community where I can work for work, and work for play. It's not everyone who gets to do what they love every day. I get to interact with amazing people from all backgrounds and walks of life, share what I learn, and learn from others. I especially like that this community can often agree to disagree.
Here's where you might disagree with me: Drupal 7 was too hard to learn. Drupal 8 will be harder just by its virtue of being more complex. I want there to be an easier alternative, for example: Backdrop CMS.
I don't recommend trying to stay 100% on top of all updates for all of your modules all the time. However, when a security update becomes available for one of your modules, you should certainly make that update as soon as is reasonable. And while you're at it, that might be a good time to bring everything else up to date as well. Below is my recipe for keeping modules on my Drupal sites up to date, by using two of my favorite development tools, Git and Drush.
Drupal's HTML filtering is an important security feature - we wouldn't want any blogger to be able to post JavaScript tags because that's how XSS attacks - or worse - are launched. In Drupal, unlike other blog systems like WordPress, you can't assume that the people who are allowed to create content are trusted. On many Drupal sites anyone can sign up for an account and start blogging. If those sites allowed JavaScript tags or even form tags to get through the filters it would quickly become ripe with bots and bad people doing naughty things.
I use MAMP for my local Drupal development on my Apple computer.
If you would like to do the same, first download the most recent version of MAMP and install it locally. When you are done, you should have directories for both MAMP and MAMP PRO in your /Applications directory.
To run the application, double click MAMP.app inside the MAMP directory. Once it's up and running, you should see a MAMP widget with a cute elephant icon.
Let's start by adjusting the preferences. I like to run MAMP on the standard ports for Apache and MySQL. MAMP provides it's own ports, and by default uses these instead.
I often hear from people that they are nervous about using the issue queue on drupal.org. This is understandable, the issue queue can be a scary place! Say the wrong thing in the wrong way, and your favorite drupal developers turn into grumpy curmudgeons and mark your issue as 'won't fix'.
Today, I walked to through the process of creating an issue with a friend over lunch, and thought it might be useful to post it here as well. Below you'll find the basic ingredients for creating an issue in the queue.
If you've been working with Drupal for a while, you'll notice that sometimes, a particular module, theme (and sometimes even Drupal core) doesn't quite work right - or - perhaps it just doesn't quite work the way you'd like it to for your particular project.
Fortunately, this is the world of open-source, and you are most likely not the first person to have this problem (or "feature request"). Your first line of attack should always be to search the issue queue on http://drupal.org and see if someone else has fixed this problem for you (or added the new feature). Quite often, you'll find that they have, and there will be a patch in the queue.
Every once in a blue moon, you'll run into a problem with your Drupal site where the solution involves patching core. Start by making sure that you have a safe place to apply your patch. This would be a 'dev' copy of the website, either running locally on your own computer, or in a development environment on the same server (or one that's identical) to your live site. *Never* apply patches directly to your live website - *especially* core patches!!!
[.../drupal-7] >
[.../drupal-7] > wget http://drupal.org/files/606598-core7-port-imagestyles-175.patch
OR, If you don't have wget on your computer (with a mac you will need to install Xcode) then you can do the same thing with curl, as follows
Applying patches is easier than you think! Start by making sure that you have a safe place to apply your patch. This would be a 'dev' copy of the website, either running locally on your own computer, or in a development environment on the same server (or one that's identical) to your live site. *Never* apply patches directly to your live website!!!
For the purposes of the example below, we'll pretend we are patching the panels module.
1) Start from the root of your Drupal site.
[.../drupal-7] >
2) Change Directories into the folder for the panels module
[.../drupal-7] > cd sites/all/modules/contrib/panels [.../drupal-7/sites/all/modules/contrib/panels] >
3) Download the patch file from drupal.org