Scott Walkinshaw

It’s easy to get comfortable using a project. Especially one that you’ve worked on and helped to create. Which is why it’s even easier to lose the perspective of a new user. Here’s what the default config looked like for a WordPress site in Trellis as of ~3 days ago: # Documentation: https://roots.io/trellis/docs/local-development-setup/ wordpress_sites: example.com: … Continued

Trellis now comes with automated Let’s Encrypt integration for free SSL certificates and the best HTTPS setup. HTTPS is now more important than ever. Strong encryption through HTTPS creates a safer and more secure web while protecting your site’s users. Google even started using HTTPS as a positive ranking for SEO purposes. Roots believes in … Continued

I wrote a blog post about on improving password security in WordPress and the Roots team created a plugin called wp-password-bcrypt to improve it a few weeks ago. Late Friday night, a few people (including myself) got into a Twitter argument about these security issues. Andrew Nacin, a Lead Developer of WordPress, ended up tweeting … Continued

We’ve released the wp-password-bcrypt plugin to improve WordPress password security by using bcrypt instead of insecure MD5 password hashing. March 21st update: see the follow-up post on password security for more information and corrections on some errors made in this post. WordPress, and its community, love to parrot that it powers 25% of the web. … Continued

As Trellis finally gets closer to 1.0.0, some useful features have been contributed in the past few weeks. MailHog Pull request by @louim Dealing with emails in development is never fun. The two common solutions are usually: Ignore it and hope it works fine on production Set up real SMTP credentials to send emails Enter … Continued

Roots has a number of projects now with the two most popular being Sage and Bedrock. This is reflected on our site with those two projects being front and centre on the home page and in the top nav. It’s time to promote a third project alongside those two: Trellis. Trellis is the new name … Continued

Bedrock was created with Capistrano as its built-in deployment tool and its remained that way for almost 18 months. Very soon, the Capistrano specific files and configs in Bedrock will be moved to its own separate repository but still easy to use. You can follow the progress at https://github.com/roots/bedrock/pull/163 and check out the new repo. … Continued

There's been quite a few updates and improvements to Bedrock since the initial release that it warrants a new post and a quick look into the changes. Web directory The biggest change was introducing a web/ subdirectory that contains your WordPress application and the WP core only. Previously everything was in the same root project … Continued

Bedrock is a modern WordPress stack that helps you get started with the best development tools and project structure. Bedrock's main features: Dependency management with Composer Automated deployments with Capistrano Easy development environments with Vagrant – coming soon! Better folder structure Easy WordPress configuration with environment specific files Environment variables with Dotenv Bedrock is meant … Continued

This is the introduction to a 12 part series for turning a WordPress site into a Twelve-Factor App. Want to turn your WordPress site into a Twelve-factor App? Bedrock is a WordPress project boilerplate to help you get started with the best tools and practices. If you aren’t familiar with the Twelve-Factor App: it’s a … Continued

Factor #12: Admin processes Run admin/management tasks as one-off processes The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as: Running database migrations … Continued

Factor #11: Logs Treat logs as event streams Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format. One of WordPress' biggest failings is not providing better logs. Most people immediately think of Apache's … Continued

Factor #10: Dev/prod parity Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas: The time gap: A … Continued

Factor #9: Disposability Maximize robustness with fast startup and graceful shutdown The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys. Most of this factor is already taken care of by … Continued

Factor #8: Concurrency Scale out via the process model Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. In the twelve-factor app, processes are a … Continued

Factor #7: Port binding Export services via port binding This is probably the most difficult factor to apply to WordPress and that's because of PHP. Web apps are sometimes executed inside a webserver container. For example, PHP apps might run as a module inside Apache HTTPD, or Java apps might run inside Tomcat. The twelve-factor … Continued

Factor #6: Processes Execute the app as one or more stateless processes The app is executed in the execution environment as one or more processes. This factor bleeds into the Run Stage and Concurrency factors a bit, but the most important point is: Twelve-factor processes are stateless and share-nothing. Any data that needs to persist … Continued

Factor #5: Build, release, run Strictly separate build and run stages A codebase is transformed into a (non-development) deploy through three stages: Build Stage The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the … Continued

Factor #4: Backing Services Treat backing services as attached resources A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such … Continued

Factor #3: Config Store config in the environment An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes: Resource handles to the database, Memcached, and other backing services Credentials to external services such as Amazon S3 or Twitter Per-deploy values such as the canonical hostname for … Continued

Factor #2: Dependencies Explicitly declare and isolate dependencies With Codebase out of the way, we're already getting into unknown territory for WordPress. Most programming languages offer a packaging system for distributing support libraries, such as CPAN for Perl or Rubygems for Ruby. The packaging/dependency system for PHP is Composer. A twelve-factor app never relies on … Continued

Factor #1: Codebase One codebase tracked in revision control, many deploys The first factor is a good one to start on because it's probably the easiest. Your WordPress site/app codebase needs to be tracked in a version control system. Git, Mercurial, Subversion, etc. Pick one and use it. Git is usually the de facto choice … Continued

Sometimes when doing performance testing, you just want to do a quick test without setting up a full benchmarking test suite. WordPress and PHP offer a few tools for us to use. WP Timers WP has 2 little known functions available for us: timer_start and timer_stop. timer_start (source) just sets a global variable $timestart to … Continued

This is a follow-up to my previous post on Using Composer with WordPress. Read that first for an introduction. Our WordPress project boilerplate, Bedrock, uses Composer for dependency management. A few common questions came up after my last post and screencast. This post will hopefully clear up two of them. 1. How do I make … Continued

This post will give you an introduction to Composer and how to manage WordPress core, plugins, and even themes with it. If you already know what Composer is and how to use it and just want to see how to integrate it with WordPress, you can skip straight to the The Solution section below. Our … Continued