Despite the somewhat ironic tone of the title, this is exactly what’s happening. People have predicted the inevitable collapse of Flash ever since Apple kicked it off the iOS platform, but now Google is hammering the final nail into the coffin. That’s right, Flash is being phased out of Chrome, apparently later this year, some time in the fourth quarter.
It won’t be gone altogether, mind you. The plan, for now, is to continue to bundle Flash with Chrome, but it will not be enabled by default. That is to say, Chrome will not play Flash content automatically, and instead ask the user if they’d like to enable it. Attempts to detect Flash with JavaScript will, apparently, find nothing. Similarly, any attempt to redirect the user to Adobe’s own download page will be blocked, again presenting the user with the opportunity to enable the plugin.
All roads have been leading to this point for years, but this may be the first time that anyone’s made a solid step toward killing Flash on the desktop entirely. Mind you, there will be temporary reprieve for the top ten sites that still depend on Flash, including Youtube, Amazon, and Twitch. Those sites will still have Flash enabled automatically, but Google wants to remove those sites from the list as fast as they can.
So that’s it, guys. Linux fans, rejoice! That’s one less non-free package for you to worry about. Everyone else, revel in the increased speed, security, and laptop battery life. Ding, dong, Flash is dead, or it will be soon enough.
While that’s undoubtedly great for us all as web users, it does mean that a number of developers and designers will have to get cracking. There are a large number of older websites and platforms that use Flash. However, it’s mostly used for displaying media, so the conversion shouldn’t take too long.
Once used to describe a jobless creative, the term has now become a badge of honor to many — and it’s looking to gain even more currency in the next few years.
With the rapid rise in technology and mobility over the past decade, the idea of working remote (outside of the traditional office) has been top of mind for many. What’s even more interesting is that many aren’t only leaving the office, but the 9–5 grind all together.
Believe it or not, freelancers now make up almost 40% of the workforce. Take that in for a sec.
Forty. Percent.
Why are there so many freelancers?
Well, aside from the boom in technologies that facilitate a more mobile but still connected life, I think many have been drawn to the idea of working whenever, from wherever, for whoever.
Once you’ve tasted that life, it can be hard to go back.
That being said, it isn’t all roses. We may have abandoned the 9–5 life, but the hours aren’t much better when you’re running your own brand and business. In fact, you give up the 9–5 for “working damn-near all the time.”
And you may have left your boss behind at your fancy corporate job — but now you have a lot of bosses. Each new client becomes your new boss (though hopefully, a really nice one), and you need to take care of them so you can continue to attract and retain new bosses down the road.
That being said, at the end of the day you (and you alone) are in full control of the projects you work on—and when you work on them. Which is something you simply cannot get in your typical office job.
Companies are also driving the change
Instead of hiring a full-time designer who requires a full-time salary, benefits, and workspace, a company can bring in a contract designer.
The contract designer won’t need a desk. They won’t need benefits. And typically, their pay correlates directly to the work they’ve already done (not what they’re going to do).
For many businesses, this has become a very attractive alternative to the full-time employee and will continue to become more popular in the coming years.
Why freelancing may be for you
Freelancing can be one of the most liberating experiences of your professional life. Taking the leap to working for yourself and being solely responsible for the money you earn is very rewarding. Knowing that, in many ways, the amount of work you put in directly affects how much you earn is empowering in ways few full-time jobs can match.
The most popular side-effect of the freelancer lifestyle is the ability to travel. Without being locked down to any particular office or location, you’re free to let your wanderlust take you wherever you please. As long as you have internet, you can work.
The work also caters to the creative who craves new things on a regular basis. (And don’t we all?) Some projects may last months, but you can freely choose which projects you take on and how long they’ll last. Having the ability to try new things on a frequent basis leads to more experience, education, and relationships you can’t get anywhere else.
Is freelancing for everyone?
I’ve spoken to hundreds of freelancers, but even more people who are looking to become freelancers.
“How do I get started?” is one of the most common questions I hear.
And it is a leap.
It’s very different from your typical 9–5 job. You go from being told what to do to having full control of your to-do list. On the surface, this sounds amazing, but keep in mind that many things that your company used to handle for you are now on your plate, including:
Taxes
Taxes are much easier when others take them out for you. It’s much more difficult to put it aside yourself, let alone calculate how much needs to go to Uncle Sam. It’s also important to note that taxes themselves are different for freelancers, where in many cases you need to pay quarterly and fold in self-employment taxes.
Paying yourself
Life’s much easier when you get paid every two weeks like clockwork. For freelancers, getting paid becomes much less predictable, and cash flow can get tight. Keep afloat involves a balance of scheduling and client communication, but does seem to stabilize over time.
Managing your own time
With a full-time job, we’re usually handed a standard working day of 9 a.m. to 5 p.m. As a freelancer, there’s no quitting time, unless you create one for yourself (which is easier said than done). Managing your schedule becomes one of the more difficult things you’ll encounter in your freelancing career.
But we want to help you take the plunge
We get it: being a freelancer isn’t easy. But we also know how incredibly liberating it can be.
So we put together this free ebook, The Freelance Web Designer’s Guide, and filled it with tips, tricks, stories, and more to not only help you get started, but also help the seasoned freelancer become more successful.
With all the buzz around the new Captain America: Civil War movie I decided to base a series of videos on characters from the Avengers. I wanted to showcase the power of Adobe Muse combined with widgets from Muse For You, and these characters were a perfect way to do that.
I used a combination of widgets to animate Ant-man, Spider-man, Captain America, and Iron Man. One particular character I had a lot of fun working with was Iron Man. I created an HUD (heads-up display) interface where a face looked like it was inside the Iron Man helmet and then I animated all the HUD elements with the “Muse Motion 2? widget. I also used the “Shake Shake Shake” widget for things like the targeting system so it looked like a dot was look for something on a radar. I used “The Animator 1.3” widget to animate a few other elements as well. I topped it off by adding the “Gradient Background” widget to add more design over the entire animation.
The main aspect of the animation was the circle animation over the eye of the character within the helmet. The circles around the eye are comprised of 3 circles and with the “Muse Motion 2” widget I was able to animate each circle differently so it looked similar to when Tony Stark is in his Iron Man helmet. I was able to change the speed, direction, and delay of each circle rotation thus giving the effect of movement within the helmet.I downloaded the HUD interface from Adobe Stock and was able to separate out the elements and copy and paste them from Adobe Illustrator into Adobe Muse. One of the great features of Adobe Muse is that it allows you to copy and paste elements directly from Adobe Illustrator into Adobe Muse; making the workflow with images seamless. The images are pasted as Scalable Vector Graphics (SVG) which is now widely supported on most browsers.
Image of an Iron Man Inspired Animation from Muse For You
One of the main goals with these videos and characters was to break out Adobe Muse into its own animating platform. I know a lot of Adobe users are familiar with programs like Flash and Edge Animate, but I wanted to educate users on just how much you can do with Adobe Muse combined with widgets from Muse For You. Picking a topic like super heroes I thought was a perfect segue into animation in Adobe Muse. Hopefully these videos among many others on my Youtube channel will pave the way for animating in Adobe Muse and make web animation less intimidating for anyone looking to create an awesome website without code and complex animation keyframes.
The video above shows the entire process from start to finish of me building this animation within Adobe Muse and using widgets from Museforyoushop.com. The video is titled: Iron Man HUD Inspired Animation (view at top).
I will be sharing my knowledge of Adobe Muse via my weekly blog post on WebDesignerLedger.com. I invite you to check back weekly for news and updates on Adobe Muse :). Happy Musing.
The following is a guest post by Alessandro Vendruscolo, who wrote to me excited to write a guest post about a WordPress tool that I didn’t know much about: Bedrock. It’s not a theme, it’s a way to install, configure, and manage WordPress with security and modern development practices in mind.
Bedrock is an open source project made by Roots that you use as base for WordPress projects.
Why should you care about Bedrock? Let’s take one step back and think about a typical way to work on a WordPress project.
Classic WordPress Workflow
You can download and install WordPress both on your local machine and production server. You can have a git repository for your theme. Deployment can be FTP transferring of theme or git pulling the repo from the server. For some projects, you might want to keep the entire site (even WordPress files) under git as well.
This has issues:
Updating WordPress/plugins from production may break your production site
You have to manually keep track of WordPress/plugin versions
Deploys can be cumbersome
Configuring WordPress is difficult, because the wp-config.php can’t be under version control
Here’s an example of what I mean. You update a plugin locally because you need some new functionality that the updated plugin provides. You write code based on that new functionality. Now it’s time to deploy. You:
Install or update the plugin on the production site (make sure it’s the same version!)
Compile assets
Update the theme on the remote server (using whatever deployment method)
If it’s a new plugin, make sure it’s been activated on the production site
This is a rather manual approach and can be quite error prone. Most importantly, it can cause downtime or fatal errors. For instance, you update the plugin and it’s not backwards-compatible, so it throws errors until the deployment is finished. Or you deploy first and the site throws errors until you update the plugin.
Enter Bedrock
If the issues above sound like something you have dealt with in the past, you’ll like Bedrock. It brings:
You’ll end up with a self-contained WordPress project that installs an explicit version of WordPress and required plugins (composer install) which can be easily configured. All configuration is kept in a .env text file) and deployed (cap production deploy).
Less troubles and more automation! Even onboarding a new developer is easier.
You also get a multistage environment for free. You can have a development configuration for working locally and, a staging configuration for tests, and a production configuration for the live site. You can also define custom configuration, such as backup where you can have a 1:1 copy of the production environment, on a different server.
Requirements
Here are the requirements for working with Bedrock:
You should be comfortable working on the command line.
You need shell access to the server: if your site is hosted on shared host you’re probably out of luck1.
You need to have a working Ruby and gem environment on your machine to perform deploys.
You need to have WP-CLI installed locally and on the server if you plan to use it. It’s not required, but you’ll see later that’s useful (install instructions).
This is in addition to all the normal WordPress server requirements, like MySQL.
Getting Started
Let’s assume a brand new WordPress project. First, you’ll need a copy of Bedrock, which you can get from its repository.
Should I clone or download the repo?
Bedrock’s README tells you to clone the repository, but in my opinion you’re better off downloading it. If it’s something that you plan to regularly keep up to date, go for the clone route; if it’s something that you plan to set-and-forget, go for the download route.
Keeping Bedrock up to date is certainly a good thing (improvements, security, etc) but it can be tricky. You may need to hand-pick changes or try to merge two upstreams. Since it is a starting point, downloading it means you can set it up once and forget about it.
Installation
Now that you have downloaded the repo, you can initialize your own repository for the project.
I keep all my web projects in the Sites folder in my home directory (I develop on OS X) and keep them indexed by their name. I use the `.dev` TLD so I can configure nginx with virtual hosts. This way, even when working locally, I have a configuration that’s almost identical to the live website. (Bonus points compared to using localhost: you get a new environment to work on: cookies, local storage, URLs for caching, etc are not shared with any other site you previously worked on.)
On my machine, I use this minimal configuration to instruct nginx how to host the website. Please note that the root folder isn’t the same as the project. Bedrock puts all public files in the web folder.
Now we need to run a command to let the magic happen:
composer install
As you can see by the output, Composer will install dependencies listed in the composer.lock file, including WordPress itself2.
So, what’s happening?
If you’re new to Composer, I’ll quickly explain what it is and how it works.
Composer is a tool written in PHP that lets you manage PHP dependencies (just like Ruby gems, npm modules, CocoaPods, etc). These days all languages have a dependency manager.
You declare the packages you need in the composer.json file, then declare them with constraints. Having constraints lets you define how Composer will update them when you run composer update.
For example, Bedrock requires an explicit version for WordPress (4.5 at the time of writing) and any version
greater than 2 but less than 3 for phpdotenv.
Every time you execute composer update Composer will try to update your packages to the latest version allowed, and will write down that version number to the composer.lock file.
Now, when you run composer install (just like you did earlier) it’ll install that specific version no matter what, reading from the composer.lock file (This is a reason that using Composer is very safe, just like gem and CocoaPods, and unlike npm, unless you use the shrink-wrap feature).
If you now list the contents of the web and web/wp directory, you will see something you’re familiar with: Composer has moved the wp-config.php file to web and all WordPress files are in the web/wp folder. If you inspect that file you can understand why it’s there.
We’ve everything in place, it’s now time to configure WordPress.
Copy the `.env.example` to `.env` and edit it:
cp .env.example .env
vim .env
It asks you for:
The name of the database you use (I’ll use example_development)
The username that will be used to connect to the database (on my machine I have just one root user)
The password of that user
The host of the database (127.0.0.1 or localhost is fine)
The environment of this installation (development is fine, you can set whatever you want: usually you have development, staging, and production)
The homepage URL that WordPress will use to build URLs among other things (I set http://example.dev)
The URL for the admin page. Leave it as it is and you’ll access WordPress admin pages at http://example.dev/wp. If you change this you’ll also need to move the wp folder contents accordingly
After you’ve saved the file you can proceed to install WordPress (it needs to create all the tables in the database!). You can do this by visiting the website on http://example.dev/ or by using WP-CLI:
config: this is where you configure WordPress. These files can’t be accessed from the Internet, because we set nginx to serve files from the web folder.
config/application.php: this file contains the usual WordPress configuration and is intended to include base settings that are common to all environments.
config/environments/*: these contain environment-specific settings. For example in production it disables errors output.
vendor: dependencies managed by Composer will be installed there, except WordPress plugins and themes; if you inspect the composer.json file you’ll see that these kind of packages will be moved in web/app/{mu-plugins,plugins,themes}/.
web: files included in this directory are publicly available
— only the files that are required are in the web folder (see config above).
web/app: this is the old wp-content folder. It’s been renamed to better reflect its content (this also matches other frameworks conventions, such as Rails and Symfony). This is where your plugins and themes will end up.
web/wp: the whole WordPress package. This should be put in vendor but can’t be because of WordPress limitations.
web/wp-config.php: this file is well-known, but in Bedrock it acts as a loader (it loads settings from the config directory). It needs to stay here because WordPress core hard codes paths.
Configuration and environment variables
As we saw earlier we have multiple configuration files under the `config` directory, and we also have the `.env` file where we put the username/password for the database.
The key aspect is this: if it’s something that’s sensitive (a password or an external service access key) you should put that in the `.env` file and read that with the env('') function. Sensitive information will never be stored in your git repository (the `.env` file is ignored by git) which is a huge benefit. It also allows you to define a different password/key for each machine. Imagine if every developer has to generate their Twitter consumer key or has to generate a new one for testing purposes: if the key is stored in a file that’s tracked by git you have to remember not to add that file to the staging area.
The solution is to add it to the .env file:
[…]
DB_PASSWORD=<password>
[…]
and read that value in the configuration file:
define('DB_PASSWORD', env('DB_PASSWORD'));
Remember that environment-specific files (`config/environment/.php`) are required before the main (`config/application.php`). This means that you can’t override settings. Say that you have the same configuration for development and staging but a different one for production. You can:
define it in every environment file (`development.php`, `staging.php`, `production.php`, etc).
put it in the `.env` file and define it in the main application (`application.php`) file.
Plugins
If your plugin is available in the official plugin registry, you can install using Composer and WordPress Packagist, which is a Composer repository that mirrors WordPress’ official plugin and theme registry.
Bedrock already added wpackagist’s repository, so installing a plugin is just a matter of running the following command to install the latest version:
You can achieve the same if you manually edit the composer.json file and run composer install.
If your plugin isn’t available on the official registry (like custom or paid plugins), you will need to put it in `web/app/plugins` and remove it from the ignore list:
Even better, if you have a git repository for the plugin, you can use Composer directly. Add the following to the repositories array of the composer.json file:
{
"type": "git",
"url": "<repository url>"
}
The repository needs to contain a `composer.json` manifest file in the root, such as this:
When everything above is set, you can run composer require macstories/wp-push-plugin to install it. Composer expects to have at least one git tag on that repository.
Now we have the plugin in place, we can enable it. Head over the WordPress admin page or once again use WP-CLI:
wp plugin activate memberful-wp
This time we don’t need the wpackagist-plugin prefix, as WordPress doesn’t know about Composer.
If plugins need to create files or folders, they should be ignored by git, adding them in the .gitignore file. One example of this is WP Super Cache: it creates two PHP files containing settings.
If plugins ask you to modify the wp-config.php file, move those new settings to `application.php` (or the environment specific one) as explained earlier.
Themes
Themes work the same way as plugins, with two differences:
Their directory is web/app/themes;
Composer’s vendor name is wpackagist-theme.
If you use a theme that’s available on the official WordPress registry you can install it with Composer:
composer require wpackagist-theme/activello
If you’re going to develop your own theme, create its folder under web/app/themes and you’re ready to go. There’s no need to exclude it from the .gitignore file.
In your theme you can query the current environment and take advantage from that. For example, on MacStories (a site I developed with Bedrock), I don’t include the minified assets in development:
$main = '';
if (WP_ENV === 'development') {
$main = macstories_asset_url( '/dist/main.css' );
} else {
$main = macstories_asset_url( '/dist/main.min.css' );
}
// use the $main variable
Another difference is analytics. I only include Mint Analytics in production, using an approach similar to above. Google Analytics is available even in development or staging, but these two environments use a different site ID, so it’s easier to perform tests.
Upgrading WordPress
At the time of this writing, WordPress is at 4.5.2. Let’s say 4.5.3 version comes out. We need to change the required version. You can edit the composer.json file and run composer install or you can just issue the following command:
composer require johnpbloch/wordpress 4.5.1
It will update the `composer.json` file (and also the lock file, since we upgraded a dependency) and install the dependency.
Usually after each WordPress update there’s a database schema upgrade to be performed which you can do by visiting the WordPress admin page. But that’s tedious, so WP-CLI has a command to perform that:
wp core update-db
There’s also another thing to keep in mind when upgrading the database schema: if you use the web UI to do that, and the operation takes too much time, you may encounter HTTP timeouts. WP-CLI skips the HTTP layer and performs the operations running PHP from the command line, which doesn’t have any timeout issues.
Upgrading plugins
Upgrading plugins is similar to upgrading WordPress: if you used Composer to install them, use Composer to upgrade them.
You can run composer require wpackagist-plugin/ to upgrade a given plugin to a specific version or, even better, use composer update to update every package to their latest version that satisfies the constraints set in the `composer.json` file.
When you composer require something (without specifying a version), Composer will by default use the ^ constraint: running composer update will update the package to the latest version that’s not a new major version. Easy peasy.
Capistrano is the de-facto tool used for deploys, and you can use it to deploy WordPress sites.
What is Capistrano?
Capistrano is a powerful tool written in Ruby used mainly3 to perform deploys. Originally it was born to deploy Ruby on Rails web applications, but then it grew to deploy any kind of web application, with plugins to run custom tasks or connect to external services.
There are plenty of guides on the Internet and many conference talks, but to sum it up: Capistrano will connect to your server using SSH and then follow this flow to update a repository on the server and run tasks. You add hooks on every task to perform what you need.
It’s designed to work with SSH keys (so you don’t have to use passwords) and it should connect to the server as an unprivileged user. It can issue sudo commands, but if you need to do that, there’s probably something wrong with your setup. You can learn more about this on the Authentication & Authorisation documentation page. I use SSH agent forwarding so Capistrano is able to pull from the git host using my local SSH key.
On the server, Capistrano works by keeping multiple directories in the directory you set as the target of deploys:
current: this is a symlink to the current version deployed (either the latest one or a previous one if you rolled back).
releases: every time you deploy Capistrano will create a new folder with a timestamp. You can configure the number of releases to keep, and Capistrano will clean up old releases (defaults to keeping 5 releases).
repo: Capistrano keeps the repository on the server and checkouts the correct revision on the server — nothing is transferred from your machine to the remote server.
revisions.log after every deploy or rollback this log will be updated.
shared: contains files and folders that must be shared between releases, such as user uploads.
Each deploy is run in isolation and has its own folder in the releases folder. If something goes wrong, nothing happens to the current version. When it’s done, Capistrano will update the symlink to the version that was just deployed.
In your project you’ll have a Capfile that requires the tasks to run (see the example from the flow) and a deploy.rb file that contains settings.
If you don’t want to use Capistrano
Bedrock supports Capistrano, but it’s not required. If Capistrano doesn’t compel you, or you prefer to use a different tool, or prefer to use no tool at all, you’re free to do so.
The only requirement is that you run composer install on the server, so Composer can pull down WordPress, plugins, and any other dependency your site needs. Otherwise you’ll have a sort of zombie website with just application code but not the application itself.
Deploying with Capistrano
OK, I convinced you to try Capistrano, let’s go on!
The Roots team (the team behind Bedrock) created a separate repository to host the Capistrano integration for Bedrock. This is because Capistrano is not required by Bedrock but can be added at any time.
Create or edit a Gemfile file in the root of the project and paste this content:
source 'https://rubygems.org'
group :deployment do
gem 'capistrano', '~> 3.4'
gem 'capistrano-composer'
gem 'capistrano-wpcli'
end
Now run bundle to have it install the gems. This differs a bit from Roots’ setup, because we grouped these gem in the deployment group and also installed the WP-CLI extension.
Capistrano will be installed by Bundler and be treated as a dependency just like we did with WordPress and Composer earlier. This is useful because every project can use a different version of Capistrano and will not depend on a globally installed one. Also, if there are multiple developers on the team, a locally installed (and synchronized) version of Capistrano ensures that everything will be as smooth as possible4.
Commit both `Gemfile` and `Gemfile.lock` – just as with Composer:
Now we need to set up Capistrano. Capistrano’s configuration will be kept in the git repo. You have to copy the Capfile file and the contents of the config directory from the repository. This is the equivalent of running bundle exec cap install and editing Capistrano’s configuration files.
Since we also installed the WP-CLI plugin, we have to require it in the Capfile. Add the following line after we required the Composer plugin:
require 'capistrano/wpcli'
Edit the config/deploy.rb and set the :application and :repo_url variables and remove the :deploy_to line. If you want, you can also change other settings here. There are many code comments and the documentation is great.
The :linked_files and :linked_dirs variables are important. If you recall from earlier, Capistrano will create on the server a shared folder (shared between deploys). By default, we’ll share the `.env` file and the `web/app/uploads` folder.
The `.env` file contains application settings and needs to be shared for the site to work, and also because this file isn’t under version control. The `web/app/uploads` folder is the old `wp-content/uploads` folder and needs to be shared because otherwise uploads would exist only within a release.
You can probably ignore the rest of the config/deploy.rb file. After line 22 it defines two custom tasks. The first is empty and disabled by default. It can be used for example to restart the web server. If you have something to restart after a deploy, update the task and enable it.
The second task has been added by the roots team and is disabled by default. It’s used update the stylesheet_root and template_root options of WordPress. I’ve never had a reason to change them.
Edit the `config/deploy/.rb` file to set per-stage settings.
You have to update the server setting, because the production env is likely to be on a different server than the staging one.
We’ll move the :deploy_to path setting here, as your staging path is probably different from the production one. You can also override settings set in the main `deploy.rb` file. The rationale of these files is the same as Bedrock environment files.
Now we configured Capistrano and everything should work. Capistrano comes with a check task that, well, checks that everything works.
Run the following command to perform the check:
bundle exec cap staging deploy:check
Capistrano will:
Log in on the server with the user you defined (so you’re sure the SSH connection works)
List repository remote files (so you know Capistrano is able to connect and authenticate with the git host)
Create the directory structure
Create linked folders
Check for linked files
Here’s an example of a Capistrano error we might see:
ERROR linked file /path/to/:deploy_to/shared/.env does not exist on
Create that file (you can use scp .env @:/shared/.env to upload your development `.env` file to the server. At this time, we’re interested in having the file, not having the correct file) and when you’re done check again that everything works. Hooray it works!
Push your changes (otherwise Capistrano will clone an empty or old repository) and run the following to perform a real deploy:
bundle exec cap <stage> deploy
This is the command that you’ll need to remember and run every time you’ll want to deploy your site.
Configuring the remote WordPress
You will have to update the `.env` file on the remote server to set the correct database information and, most importantly, the WP_ENV and WP_HOME settings.
If you deployed to production that must be WP_ENV=production (I don’t know your WP_HOME value).
Your web server needs to serve contents from the current folder, so if locally you had this this setting for nginx:
root /Users/MJ/Sites/example.dev/web;
on the server you’ll have to update it in this way:
root <value of :deploy_to>/current/web;
Installing WordPress on the remote server is just a matter of doing the same things you did on your local machine. You can use the web UI or use WP-CLI, even from within Capistrano.
When you deploy a new version and in that version you install a new plugin, you can use the following command to enable the plugin:
bundle exec cap <stage> wpcli:run['plugin activate <name>']
To perform database migrations:
bundle exec cap <stage> wpcli:run['core update-db']'
Hooks
You can define custom tasks for Capistrano to run, but before doing so, search for an existing solution. Capistrano comes with many official plugins, like Bundler, npm and many other community driven plugins.
For example, say you have a build script that compiles Sass assets. Because of the benefits we talked earlier, you should require Sass in the Gemfile with:
gem 'sass', '~> 3.4'
Now we need to do two things when we deploy:
Ensure the sass gem is installed
Run our own build script
Capistrano-bundler
The first step is easy to achieve: we’ll require the capistrano-bundler gem by adding this line to the :deployment group:
gem 'capistrano-bundler', '~> 1.1.2'
After that you run bundle to install the gem and also edit the Capfile to require it:
require 'capistrano/bundler'
Done. Every time we deploy, Capistrano will run bundle install on the server, after the deploy:updated task.
If you want, set the :bundle_without variable in the `deploy.rb` file:
set :bundle_without, %w{deployment development test}.join(' ')
Doing so will exclude those groups of gems from being installed. Bundler will install less gems (that we won’t need!) and our deploys will be faster.
Running custom scripts
I don’t know how your build script is structured. I’m a fan of make, but you can have anything you want: a shell script, npm scripts, Grunt/Gulp tasks, etc. No matter what, we have to run them, otherwise our site will be without assets.
We can create a custom task easily. Create your .cap (e.g. make.cap) file in lib/capistrano/tasks to have it automatically loaded (otherwise you’d have to explicitly require from the Capfile) with this content:
namespace :make do
desc "Runs make all"
task :all do
on roles :all do
within release_path do
execute :make
end
end
end
before 'deploy:updated', 'make:all'
end
Capistrano will run our task before the deploy:updated task. Since we used the within release_path do … bit, this command will be executed in the correct release/ directory that Capistrano is deploying.
Check out Capistrano’s documentation for more. Hot tip: be sure to use the colon before any argument (it has to do with shell escaping).
Adding a new stage
Bedrock comes with three default environments:
Development (Bedrock only)
Staging (Bedrock and Capistrano)
Production (Bedrock and Capistrano)
You can add a new stage if you need to. An example could be a backup environment that is 100% equal to the production one. The database could be synced periodically or you could setup MySQL replica functionality. In case of failure you’d update your DNS to point to the different host and nobody will notice anything.
To add a new stage:
Create a new environment for Bedrock: `config/environment/backup.php` (you can copy an existing one and update what’s needed)
Create the Capistrano stage configuration: `config/deploy/backup.rb` (again use an existing one as a base)
Setup the server (web server, database, etc)
Deploy the project (bundle exec cap backup deploy:check and bundle exec cap backup deploy)
Be sure the `.env` file contains WP_ENV=production
Migrating an existing project to Bedrock
In this tutorial we created a new project, but Bedrock can be used with existing projects.
If you have an existing WordPress site and want to convert it to Bedrock, you can treat it as if it was a new project:
Install Bedrock
Configure WordPress
Restore your theme
Install plugins with Composer
If you didn’t modify WordPress core files you’re done. If you modified WordPress core files you’ll have to keep your custom WordPress version under version control (you’ll lose easy-Composer-driven WordPress updates, but still have every other feature).
Gotchas and tips
Some tips:
Remember that if [something] created [something else], you shouldn’t manage it. This includes for example: files created by plugins, files installed by a package manager, files uploaded by users, etc — don’t add them to git. If you ignore them, there’s also an high chance they should end up in the linked_files setting of Capistrano.
Don’t store sensitive information in git.
Don’t forget to git push before deploying: I’ve deployed multiple times the same version before realizing that I forgot to push (on the server Capistrano was pulling the same version over and over again).
Use WP-CLI whenever possible: it’s faster and can be executed by Capistrano. Examples include:
wp plugin activate
bundle exec cap wpcli:run['plugin activate ']
wp core update-db
bundle exec cap wpcli:run['core update-db']
You can set Capistrano branch (config/deploy.rb) to set :branch, ENV['BRANCH'] || :master: doing so lets you easily deploy a branch by doing BRANCH=my-feature bundle exec cap deploy (remember to push, see tip #3); if you don’t provide the BRANCH= environment variable, Capistrano will fall back to deploying master.
Using Slackistrano you can post to a Slack channel after every successful deploy.
Recap
I hope you followed and enjoyed this tutorial. I encourage you to create a new site on your local machine to have something to experiment with.
To recap, these are the advantages that Bedrock brings:
Self-contained repository
Easy deploys
Easy multi-stage support
More consistency between environments
Separation between configuration files and everything-else
Congrats on making it through this tutorial. Sorry if it was long and difficult. It’s definitely not for beginners! Hopefully along the way you learned some new tools and leveled up your understanding of all the different moving parts.
The benefits of working like this are well worth it, in my opinion. Now go create something nice!
[^1]: That’s not because you can’t ssh @ (some hosts permit that) but because you can’t install some of the required software — if you’re using a script that runs on the server to build the assets you’re probably fine.
[^2]: Unfortunately at this time it doesn’t exist an official version of WordPress distributed via Composer. Bedrock uses this fork that syncs every 15 minutes.
[^3]: In fact, you can deploy whatever you want with Capistrano: you’re not constrained to web apps, you could deploy iOS apps to a remote server, if that makes sense to you.
[^4]: Later you’ll see cap commands prefixed by bundle exec: doing so ensures that the local gem is used instead of a globally installed one (which might not exist). You should do the same for Sass or any other gem.
There’s lots of neat tricks for reducing the size of JPGs in this article by Colt McAnlis:
With the Average webpage size now larger than the original DOOM game, you have to start asking where all the bytes are coming from, and how you can do more to toss those things out.
While JPG compression is impressive in its’ own right, how you use it in your application can influence the size of these files significantly. As such I’ve assembled a handy collection of things that can help you squeeze out those last bits, and make a better experience for your users.
Some well-established web design basics: minimize the number of choices that someone has to make; create self-explanatory navigation tools; help people get to what they’re looking for as quickly as possible. Sounds simple enough? Now consider this…
An ever growing number of web users around the world are living with dementia. They have very varied levels of computer literacy and may be experiencing some of the following issues: memory loss, confusion, issues with vision and perception, difficulties sequencing and processing information, reduced problem-solving abilities, or problems with language.
This little series is about the things that really accelerate WordPress websites, moving them into the millisecond area of loading speed. A lot of manual work is required, as we found out in the last article. In this part, we’ll do the touch ups that are still left. We’ll tune URLs, put Jetpack on a diet, transform the website into static HTML pages via caching, and make videos load last.
Performance: The Right Permalink Structure
Permalinks in WordPress can be changed at will. WordPress allows us to create any structure we can think of. The natural structure of the WordPress permalinks is called messy URLs, as no clear structure can be recognized. A link right after a fresh installation would look like this:
http://www.noupe.com/?p=123
This structure is not really readable by human and machine, and thus, people started using readable permalinks with keywords.
http://www.noupe.com/example-post/
With WordPress, creating these links can be done very quickly, and at the moment, this structure is still the most popular one. However, many other arrangements are possible, like a date, the category, or tags, for example. This is not smart, though, as permalinks can drain your server’s resources massively. Who would’ve expected that? In general, you can say that strongly altered permalinks are bad for the performance.
Of course, this doesn’t increase the loading time by seconds, but in conjunction with other performance eaters, it is measurable. Link addresses with simple IDs are significantly faster when there are many entries in a blog, or at certain times where the visitor traffic is very high.
Google Pays Close to No Attention to the “Talking” URLs
Times have changed, and Google itself doesn’t seem to care about the talking URLs anymore. The opposite is the case, as Google itself has started to use simple IDs in their URLs, instead of keywords. This can be seen on YouTube and Google+, for instance. Google switches over to paying attention to user friendliness, fast loading times, and good content. The old tricks with the talking address, optimized with keywords, don’t work anymore. Thus, it makes sense to consider using short and fast URLs, and changing the structure for existing projects as well.
Switching Permalinks to Simple IDs
Recently, Google seems to value short URLs more than others. This is a personal observation of mine since I switched my permalink structure from talking to simple IDs on my Democratic Post. Since then, I’ve been receiving more traffic via Google. Thus, I recommend using a simple permalink structure with IDs. Changing the structure for existing projects is no problem either, as WordPress takes care of the necessary redirections from the old to the new URL. A link ID would look like this:
http://andreas-hecht.com/466/
The following screenshot shows the appropriate settings:
Make Videos Load Last
Making videos load last doesn’t make the website significantly faster regarding the pure loading time. But the website builds up significantly faster. At least, the visitor will gain the impression that your blog loads rapidly, as the visible area of the site is displayed far more quickly. To achieve that, the loading of the video is simply moved to the end. When a video happens to be integrated directly into the visible area, a white frame will show for a short period, in which the video will be displayed after it has loaded completely. Now, the loading of the website is not interrupted by videos anymore. The code is very minimal, and consists of two parts:
The Code Snippets for Your Theme’s functions.php:
Part 1: The PHP Function
One click opens the Gist at GitHub
Part 2: The JavaScript Code
One click opens the Gist at GitHub
The second part of the code is only loaded on the page of the article. Those that use videos on pages or the homepage also have to adjust the snippet to their needs.
Caching: Switching a Blog to Static HTML Pages
Even a regular caching speeds your website up quite a bit. However, the PHP interpreter is still called up with every page visit. If you want a really fast website, you need to switch the caching of your website to the creation of static websites. Then, the PHP interpreter is avoided, and the demanded page is immediately called up. This really makes a difference, but it does have its disadvantages.
Advantage:
Each page is loaded a lot faster; the website becomes really fast.
Disadvantages:
No scheduled articles are possible anymore, as the PHP interpreter is avoided.
Solution:
A decent alternative would be calling up the WordPress file wp-cron.php (located in the main index of the WordPress entitiy), using a server cronjob (ask hoster), or a service provider like cronjob.de. – Cachify Wiki
Creating Static HTML Pages Using the Plugin Cachify
The free WordPress plugin Cachify is the fastest caching plugin for WordPress websites if set up correctly. In conjunction with a .htaccess extension, it creates a GZIP-compressed HTML version of each of a blog’s pages.
The .htaccess file can be found in the WordPress main index. The required extension for Cachify has to be copied in above the WordPress rules. Please make a backup before editing the file.
One click opens the Gist at GitHub
The Required Settings of the Cachify Plugin
A Diet for Jetpack
Jetpack is a great plugin, as long as you are careful what you activate. I use the plugin very consciously and only have a few modules enabled. On my Democratic Post, the following modules are active:
Shortcode Embeddings – for Youtube, Flickr, and other services
Website Statistics – for a fast overview of the most viewed articles in the dashboard
Additional Sidebar Widgets – for the display of the most popular articles (Top Post Widget)
Data Backup – for the VaultPress backups
Jetpack’s bad reputation as a performance eater comes from the fact that the plugin loads a stylesheet or a JavaScript or both for each of its possible functions. Unfortunately, it is not possible to decide which scripts and styles you want to be loaded, and which ones you don’t want as you might not even use them at all. Thus, you need to manually decide what is necessary. For me, the plugin loads exactly one JavaScript and not a single CSS file.
I’ve copied the CSS that’s necessary for the top post widget out of the Jetpack CSS file and implemented it in my style.css. Afterward, the Jetpack CSS was prevented from loading.
Part 1 of the Jetpack Optimization: Control Over the Modules
The Jetpack modules can easily be controlled using the plugin, and can also be prevented from automatically activating. Every module that was deactivated doesn’t load scripts anymore. An overview of the settings:
Part 2 of the Jetpack Optimization: Preventing CSS from Loading When It’s Not Needed
Jetpack loads tons of CSS files that are not required in all cases. My website doesn’t need a single one, which is why I deactivated them all. The code for that was written in a way that individual elements can be deleted from it when you need them.
One click opens the Gist at GitHub
The Final Result: A Really Fast Website
The First Run With the Pingdom Tools
The Second Run With the Pingdom Tools
With all the settings we made, we’ve created a website that loads in a matter of milliseconds. Nonetheless, we would not be done at this point, as a lot more is possible. I could forgo the top post widget or the large format images for my ebooks. The de:comments plugin for the comments could be deactivated, and I could use the WordPress comments with a caching for the Gravatars. On top of that, I could kick out the ad blocks from Google Adsense and Plista.
A loading time of 300 milliseconds would certainly be possible. But that is not practicable, in my opinion.
The last couple of months have been nothing short of groundbreaking for the Opera browser and the company. Two months ago, it made headlines with the announcement that it was including a native ad-blocking feature in its browser to increase web-surfing speeds. Then, shortly after that, it announced that it was integrating a built-in VPN into the browser.
It’s safe to say that 2016 has so far been the year of Opera when you compare all these milestones to what competitors Google Chrome, Mozilla Firefox and Apple Safari have been doing. But wait, Opera’s still not done.
A few days ago, the company announced in a blog post that it was debuting a power-saving mode for computers. The collective gasp you probably heard was a sigh of relief from laptop owners the world over, happy that their batteries would be taxed less from now on. The fact that the company keeps rolling out feature after feature shows that it still means to be a serious player in the browser market.
Available in the Opera developer channel, the new power-saving feature is meant to compete directly with Google Chrome, as Opera’s version extends laptop battery life by 50% over Chrome. When all is said and done, this could mean several hours of extra browsing time prior to having to worry about recharging your batteries.
Opera’s designed this new mode to be easy to use and accessible. Users interested in getting more browsing time from saving battery life can click on the battery icon when the power cable is unplugged. Alternately, users will get a reminder from the browser to turn on this power-saving mode when their battery life decreases to 20%.
To accommodate this new feature, Opera had to make a few development changes, such as:
Reducing activity in background tabs
Waking up the CPU less frequently through better, optimal scheduling of its JavaScript timers
Immediately pausing any unused plugins
Taking down the frame rate to just 30 frames per second
Paused animations from browser themes
Tweaking video-playback parameters and prompting use of hardware-driven video codecs
The best part of these adjustments is that the browser speed won’t suffer, but users will still be able to enjoy power savings.
Opera produced empirical data based on actual tests it ran to determine that its browser speed wasn’t affected by this new feature. On a laptop with Windows 10 64-bit, this new Opera developer version outlasted Chrome’s battery life by 50%.
Even with these promising results from Opera, you still obviously have to consider additional factors. For instance, Opera’s great speed in power-saving mode also depends on the sites visited and the type of computer being used.
Although Opera has gotten a lot of positive press these last couple of months, the reality is that very few people actually use it. According to W3 Schools, almost 1.5% of web users use Opera. With Chrome and Firefox being far ahead, Opera is rolling out one killer feature after another to attract more users. Time will tell if Opera’s firsts can bring more new users aboard.
In this tutorial, we’re going to learn how to design a social profile user interface (UI) in Adobe Illustrator.
The Steps (1-18)
1. Create a new document, 3000 x 3000 pixels, with the colour mode set to ‘RGB.’
2. Using the Rectangle Tool, select a light grey and draw a four-sided shape that covers the entire artboard. You can then double-click the layer name in the Layers palette and rename the layer to ‘Background’, and click in the empty box alongside to lock the layer (you should see a padlock icon appear to confirm that the layer has been locked).
3. Create a new layer from within the Layers palette, give this layer a name of your choice, and then paste in the profile photo that you wish to use. Make sure that this new layer is above the ‘Background’ layer. Move the photo off of the artboard for now, and we’ll come back to this later in the tutorial.
4. Using the Rectangle Tool, draw a new four-sided shape (approximately 775 x 490 pixels). Give this shape a fill colour of white.
5. Select the Ellipse Tool, and hold Shift to draw a circle (approximately 290 x 290 pixels). Fill with any temporary colour for now, and align the circle centrally inside the rectangle that we created in Step 4. Different shades of grey are particularly useful when working on a layout to get the basic structure, and can then be refined later in the design process.
6. Select the Type Tool and click anywhere on the artboard to start typing a number of your choice, then press Return and type the word ‘Likes’.
7. Select central text alignment, pick a font, and style using bold/italics as desired.
8. Position the new text object in the bottom left corner of the rectangle, with plenty of space from the left/bottom edge.
9. Copy/Paste the text object two more times, and spread all three horizontally across the width of the rectangle. Use the alignment options if necessary to distribute the 3 text objects equally apart. The numbers can also be adjusted, as well as the titles. For example, consider using Shares, Downloads, Followers etc as ideas for titles.
10. Remember the profile photo that we put to one side earlier? Move the photo over half of the circle, so part of the circle is still visible. Then select Object > Arrange > Bring to Front to ensure that the circle is on top.
11. Select both the circle and photo together holding Shift when selecting, and then go to Object > Clipping Mask > Make. This will crop your photo inside the circle shape. Double-click on this object to now go inside of the shape and adjust the crop of your image. To then exit that specific object group, click the arrow pointing left, in the upper left corner of the document window.
12. Next, we can create a circle with similar dimensions to the profile photo, remove the fill, and give this shape a stroke width and colour as desired. This step is optional, adding a border around your profile photo.
13. Select the Polygon Tool and specify creating a shape with 3 sides (triangle). Select white as the fill colour for this shape, reduce in size, and position centrally and underneath the main rectangle, ensuring that the triangle is pointing in a downwards direction.
14. Ensure that both of these shapes are touching, and in the Pathfinder palette, select the Unite option to merge these two shapes into one shape.
15. Using the Ellipse Tool, create a narrow ellipse that is a similar width to the main rectangle, and position this underneath. With this shape selected, open the Gradient palette and create a new gradient that has black on the left and right sides, with white in the centre. You can drag swatches from the Swatches palette on to the GradientSlider to add these to your gradient.
16. The next step is to go to Effect > Blur > Gaussian Blur, and specify a value for the desired amount of blur. The aim here is to create a ‘floating shadow’ for the main rectangle, and you can adjust the amount of blur accordingly. The overall opacity of this shadow can also be adjusted in the Transparency palette.
17. Increase the height/width of the main rectangle as required to add any other additional details. For example, this could be someone’s Name, Job Title, or a Description etc.
18. Select the main rectangle, and go to Effect > Stylize > Drop Shadow, to specify any drop shadow settings. Adding a subtle shadow can help create a little more distinction between the light grey background, and the white used for the main rectangle.
