I've been meaning to write up a blog post about how to go from a HTML template (purchased from a place like https://themeforest.net) to a Backdrop theme. As a developer with only a smidge of design skill, I have found this to be a workable alternative to hiring a designer for custom work.
Below you'll find a very a rough outline of the steps I follow:
This guide is intended to help people using Cloudflare to speed up and protect their Backdrop CMS sites.
Step #1
Create three Cloudflare PageRules to exclude the Backdrop cron page and the link to run cron as an admin from Cloudflare’s caching and performance features:
Step #2
If you have a valid SSL certificate on your server, you'll need to navigate to the Cloudflare Crypto section and update the SSL setting to `Full (strict)`. Without this setting SSL will be terminated at the Cloudflare edge server, and all traffic on your server will come in through port 80 instead of 443.
The breakpoint for a Smartmens menu to go from displaying only the hamburger to displaying the whole menu is 768px by default. I had a site where I needed the breakpoint to fall at 1120px instead, here's how I changed it:
I started by copying two CSS files from backdrop core into my theme. The two files were named menu-dropdown.theme.css and menu-toggle.theme.css and are located in the core/modules/system/css/ directory.
I then opened both copies of these files in my editor, and changed every breakpoint that was 768px, to 1120px. The breakpoints are specified in ems, so that meant replacing
@media (min-width: 48em) {with
@media (min-width: 70em) { I then added both these stylesheets into my theme's .info file, like so:
Working with Git is great, but before you see the real benefits of using Git you'll need to have your project hooked up to a remote repository.
Most people enter the world of Git when they are brought on to a project with multiple developers. In this case, there is likely already an existing repo, and all you need to learn to do is pull the latest changes, and push your own.
First, you'll need to get a local site up and running. You can do so using MAMP, Kalabox, or any other tool that makes that easier, but make sure you can find out where the files are saved on disk. You'll need to get there from the command line to follow along with the rest of this post.
Open your terminal, and navigate to this location. I do this using the cd command. cd stands for "change directory".
Tools like Git desktop and Acquia dev desktop allow people to use Git without understanding how it actually works. These tools are a fantastic on-ramp to the world of Git, but at some point I hope that everyone gets a chance to work with Git directly from the command line. This will complete your understanding of what happens when you push those buttons in the desktop applications, and make you better at using both! Here are some basics to get started.
First, you'll need to get a local site up and running. You can do so using MAMP, Kalabox, or any other tool that makes that easier, but make sure you can find out where the files are saved on disk. You'll need to get there from the command line to follow along with the rest of this post.
Open your terminal, and navigate to this location. I do this using the cd command. cd stands for "change directory".
I've written about how to manage your configuration directory in version control (Git) several times, but now that I've done it in the wild on a few different sites, I thought I'd write it up here as well.
Note: this figure-8 approach works best when there is only a single developer on the project. If there is more than one, this approach can get confusing, and I prefer the versioned staging directory approach.
Below I have outlined how I set up most of my sites, with the Git root a directory above the webroot. This allows me to keep things that should not be web-accessible (like config!) in version control.
I tasked myself with rebuilding my dad's old Durpal 6 site, www.stellarsoftware.com, to Backdrop CMS in one weekend.
I decided to rebuild from scratch rather than upgrade so that I could test more of Backdrop, and catch and fix bugs in the process (I found a handful - all now have PRs in the queue). After the site was built, I then needed to recreate the theme.
I started by opening an issue on drupal.org in the queue for the old Drupal 6 theme, Aeon5. I asked politely if the current maintainer would be interested in working on or maintaining a Backdrop CMS version of the theme. It is, after all, their work, and they should be aware of what's going on, even if they aren't interested in being involved.
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.