Tutorials – WordPress Tavernhttps://wptavern.com
WordPress News — Free as in Beer.
Thu, 24 May 2018 01:30:38 +0000 en-US
hourly
1 https://wordpress.org/?v=5.0-alpha-433119006382A Very Brief Introduction to Version Control and Githttps://wptavern.com/a-very-brief-introduction-to-version-control-and-git
https://wptavern.com/a-very-brief-introduction-to-version-control-and-git#commentsThu, 28 Sep 2017 22:31:59 +0000https://wptavern.com/?p=75177(more...)]]>This post was contributed by guest author Peter Suhm. Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict, bringing his work along with him as he goes.

Have you ever done this?

Most of us have.

Do you know what the technical term for it is? Version control. Your own, homemade, delicious implementation of version control!

Okay, how about this?

Version control right there!

What I’m trying to show with these two examples is that all developers use some sort of version control. Some use Ctrl-z to roll back to a previous version, some use a zipped backup in a Dropbox folder and some use a dedicated version control system (VCS), such as Git. All the things we are trying to accomplish by backing up our files, commenting out old code and stashing it away in another “final-FINAL” zipball has been taken care of already. All we need to do is to embrace these VCS tools that we have available in our tool belt.

Git is not complicated to use. It might seem difficult and overwhelming but in your day to day life you will probably use a maximum of 3-4 different commands. Learning how to use 3-4 commands to properly have version control of every single change ever made to your code base is a great deal compared to the “final-FINAL” approach.

Here’s what version control looks like:

This is a screenshot of the WordPress Git mirror on GitHub. Every time a change is made to the code base, it is recorded with Git and there is no need to copy the whole code base, throwing it into another folder, zipping it and naming it “final-FINAL-F-I-N-A-L”. If you dive into the WordPress code base on GitHub, you can find commits dating back to 2003, made by “someone” named saxmatt!

Let’s dive into one of these commits, as they are called in Git:

This is the diff (Git jargon for difference between 2 commits) for the “class-wp-widget-text.php” file. The red line is being replaced with the green line below it. No need to comment it out to save it for eternity, like in that other example. Git will do that for us and we can forever and always refer back to this commit to see what was replaced and with what.

Of course, the full WordPress code base is a large project with many collaborators. However, no project is too small to benefit from Git. Once you master those 3-4 commands, using Git in your day-to-day developer life becomes second nature, just like hitting Ctrl-s. It might not be obvious right now, but when you pull out an old project months or years later, having version control helps you catch up and gives you the confidence to change things without fearing disaster.

So I challenge you to learn Git! Not necessarily deeply, just a little bit.

]]>https://wptavern.com/a-very-brief-introduction-to-version-control-and-git/feed1175177Composing a WordPress Development Environment with Dockerhttps://wptavern.com/composing-a-wordpress-development-environment-with-docker
https://wptavern.com/composing-a-wordpress-development-environment-with-docker#commentsMon, 20 Feb 2017 18:23:39 +0000https://wptavern.com/?p=66335(more...)]]>This post was contributed by guest author Peter Suhm. Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict, bringing his work along with him as he goes.

In the last few years, a wave of virtualization technologies have swept through our WordPress development environments. The one that’s sounded the most promising to me has been Docker: lightweight and flexible. Yet, until recently, getting Docker up and running was an overwhelming task – especially on a non-Linux machine. If you managed to get it up and running in a virtual machine (using Vagrant or similar), getting port-forwarding to work would make you give up and just use Vagrant instead.

Now it’s different.

With (a stable) Docker for Mac and Windows and Docker Compose at hand, getting Docker up and running is easy and pain-free. With Docker Compose you can tell Docker exactly what you want your WordPress development environment to look like and it will take care of it.

What is Docker?

Docker is a technology that makes it really simple to create isolated containers for your applications and websites to run in. These containers can be combined and modified to fit the needs of your applications. Docker is utilizing the Linux Containers technology (LXC) where multiple isolated environments can share the same Linux kernel – making it very lightweight compared to something like Vagrant.

The Docker ecosystem is built around containers. In the Docker Hub, you can find an endless number of containers that other people have built or you can build your own using a Dockerfile. When building your own, you can start from scratch using the base Ubuntu image or extend someone else’s image.

You can share local directories with your containers and link the networks, so they can talk to each other – just like you know it from other virtualization technologies. However, this is where it gets complicated which leads me to Docker Compose:

What is Docker Compose?

Docker Compose is what makes Docker available to mortals like you and me. As the name implies, Docker Compose is a tool for composing Docker containers. That means defining your services (containers), setting up the network between them, sharing local directories with them, and a few more things.

With Docker Compose you create a simple file in the root of your project that describes the setup required by your application/website. For a WordPress theme that might mean a container to run WordPress, a container to run MySQL and a container to run Gulp or Grunt. This can very easily be defined in a docker-compose.yml file that can then be shared with your team members. This means that you can now share your WordPress theme, including an isolated WordPress environment to run it in. Hurray for virtualization!

Why use Docker?

There are a few reasons why Docker is an attractive technology for me. Here are the most important requirements I have for my development environment and how Docker solves them:

Clean Mac: In an ideal world, I prefer not to install anything related to my development environment directly on my Mac. I work on so many different projects that this gets unmanageable. When one thing works, another doesn’t. I also travel a lot and should something happen to my computer, I want to be able to set up a new machine in minutes.

Shareable: I often work in teams, so sharing my development environment with teammates is crucial. This is possible with Vagrant, but it’s still very tricky to keep environments in sync across teams.

Lightweight: This is important, especially when on the road. Try running a few Vagrant boxes compared to a few Docker containers and see what I mean.

Extendable: Extending Docker is very easy. For example, I could extend the official WordPress container and build it with WP Pusher pre-installed, since I (obviously) always use it.

Mirror production: My development environment needs to be as close to production as possible. With Docker this is easy, since Docker can be used in production as well.

My Docker development environment

This is the very simple Docker setup I use for development of my WP Pusher plugin: A WordPress and a MySQL container. Both of them use the official Docker Hub images, so setting it up is very easy.

My docker-compose.yml file looks like this:

It describes two services: a MySQL 5.7 database and WordPress running on PHP 5.6 and Apache. The database is using a volume on my local machine, so data will be persisted every time I shut off the container. My current directory (in this case a plugin) is mounted into the wp-content/plugins directory. This allows me to work on my plugin in a completely isolated WordPress environment – without installing anything, besides Docker, on my Mac. The WordPress container forwards port 80 to my local machine, so I can access it as “localhost” in my browser.

If you want to try it for yourself, and have Docker installed on your machine, just add the file to your plugin (or theme) and run:

$ docker-compose up -d

In order to see which containers are running, just run:

$ docker ps

This a very simple setup that is easy to extend and build upon.

I hope this post made you curious about Docker and WordPress. Thanks for reading along!

Links

]]>https://wptavern.com/composing-a-wordpress-development-environment-with-docker/feed1766335Git and WordPress: 3 Tips to Do It Betterhttps://wptavern.com/git-and-wordpress-3-tips-to-do-it-better
https://wptavern.com/git-and-wordpress-3-tips-to-do-it-better#commentsWed, 08 Apr 2015 18:15:24 +0000https://wptavern.com/?p=41770(more...)]]>This post was contributed by guest author Peter Suhm. Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict, bringing his work along with him as he goes.

This article is based on a few ideas, thoughts and opinions I have about Git and WordPress. There is still no de-facto standard for how these things are dealt with in WordPress and I think it is our responsibility, as a community, to have discussions about them. These are my opinions and I would love to hear yours as well.

Let’s get right to it.

R-E-S-P-E-C-T

I have ranted about the subject of repository structure before and I have strong opinions about it. In my opinion there is one – and only one – way to structure Git repositories in a WordPress context. That one way is the one-package / one-repository approach. Let me explain why.

While working on WP Pusher, I have seen many different approaches to structuring Git repositories. Two approaches are especially common, and, in my opinion, equally bad.

The first one is Git-it-all, where everything, including WordPress core, plugins and themes are put under version control. The other one, and more common, is wp-content-under-version-control. I say that both of them are equally bad, because no matter what, you are going to have a lot of 3rd party code included in your Git repository, which quickly becomes a mess. Every time WordPress or one of your plugins or themes ships a new update, you will have to somehow deal with it within your version control system.

The argument for having WordPress itself under version control is most often to lock down the version of the code. This seems a bit redundant to me, since WordPress is already developed using version control (SVN) and comes with a version number for each update. Why would you need to manage that yourself when it is already managed for you? Today, installing WordPress with Composer is super easy and then you can control your version from the composer.json file. There are no excuses. Do not include WordPress in your Git repository.

The second approach, wp-content-under-version-control, is often chosen as an easy way of deploying multiple plugins that might depend on each other. Still, I am not buying it. Having 5, 10, or even 20 Git repositories in your wp-content directory is really not an issue. Also, if your plugins depends on each other, take a look at must-use plugins.

So here is the deal: You need to treat each of your packages (be it a plugin or a theme) with respect. You need to give each of them their own Git repository. They are their own entities and needs to be separated. Keeping them locked up together makes it impossible to share code across projects. It is the way Git is supposed to work, it is the way Composer is supposed to work, and it is even the way WordPress itself works.

To Ignore, Or Not To Ignore

Yes, that is the question and I do not have the answer. I am, of course, talking about the .gitignore file. The file that tells Git which files and directories to exclude from version control. Actually, the real question is: Should you precompile your dependencies before shipping your plugin, or not? (I will focus on PHP dependencies, since I do not know enough about front-end things.)

In an ideal world, you would never ship something like Composer dependencies with your package. It would be up to the user to compile and fetch those dependencies that fit their specific environment. That is the whole point of dependency management tools. However, in WordPress, there is absolutely no sane way to handle these PHP dependencies. So if you are shipping a WordPress plugin that relies on 3rd party dependencies, I would say “ship it all”, even though it feels very wrong and awkward.

This is bad, though, because what happens when Mailchimp for WordPress ships with one Composer package in v1.0.0 and WP Pusher ships with the same package but v2.0.0? Oh, the horror. The plugin that is loaded first will get to autoload its classes. The others will not (since it would result in a “class exists” fatal error). I probably do not need to explain why this is bad.

As a WordPress developer, you can try to mitigate this by making sure that the functionality you rely on is actually available at runtime, but this is not optimal. However, I really think this is WordPress’ responsibility. We cannot do PHP without using 3rd party code. That would be stupid. So as I said: No clear answer. I guess it just depends.

Exporting Repositories aka Zippin’

Recently, someone on Reddit proposed that people start to include a .gitattributes file in their repositories, containing export instructions for Git to use when archiving repositories (zipping them). Basically, by specifying it in your .gitattributes file, you can make Git ignore files that you only need for development.

The Reddit thread was specifically targeting authors of packages distributed with Composer, but we can use this trick as well. If you exclude files from exports, they will not appear in the zip archives that you can download from GitHub or Bitbucket. This is nifty, especially if you use a tool like my WP Pusher to move files from Git to WordPress, since it can drastically minimize the size of the archive files. No need to ship files such as assets, that are already compiled, and unit tests to end users.

Before I knew about this trick, I manually deleted these files before shipping the plugin. Now it is done automatically.

There you go. Just a few things I want you to think about and consider if you are a WordPress developer using Git. Thanks for reading along.

]]>https://wptavern.com/git-and-wordpress-3-tips-to-do-it-better/feed2141770How to Set Up a WordPress Development Site with Codio’s Free Cloud-Based IDEhttps://wptavern.com/how-to-set-up-a-wordpress-development-site-with-codios-free-cloud-based-ide
https://wptavern.com/how-to-set-up-a-wordpress-development-site-with-codios-free-cloud-based-ide#commentsWed, 21 Jan 2015 21:21:08 +0000https://wptavern.com/?p=37626(more...)]]>

Codio is a cloud-based IDE that is primarily used in the education sector but is also available to developer professionals. The service provides instant coding environments with support for code editing and a large array of popular programming languages and software components.

By making the IDE available to users through the browser, Codio eliminates the hassle that educators experience when setting up development environments for students. Projects created in Codio are accessible both in the classroom and at home, which helps students continue their learning outside of the classroom.

Codio offers a free account that gives you 256 MB memory per project and 2 GB storage per project. Other pricing tiers cater to teachers, students, schools, universities, and professionals. However, the free account is perfect for creating a quick development site with WordPress, and you can set it up in under five minutes.

Step 1: Create a New Project

After creating an account with Codio, you’ll be greeted with a prompt to create a new project. Click through to get started with a new project that will contain your development environment.

You’ll now have the opportunity to choose from three different starting points: an empty project, a starter pack, or a GitHub import. Select “a starter pack.”

This will take you to a page that lists all of Codio’s certified starter packs, which help you easily get started with technologies like Angular, Node + Express, Drupal, Ruby on Rails, and more. There are a dozen starter packs that are certified and supported by the Codio team.

Fortunately, there’s a starter pack for WordPress that will automatically set up MySQL, Apache, and PHP. This makes the setup process quick and hassle-free, and you’ll be using the latest version of WordPress in just a couple minutes.

After you select the WordPress starter pack, you’ll be returned to the project page. Free accounts are limited to public visibility on projects, so you may need to upgrade to the Pro plan if you require private projects.

Step 2: Configure WordPress

After you complete the project setup, you’ll be dumped out onto the readme file for your project where you’ll find instructions for configuring and installing WordPress. If you’re bothered by non-capital P’s in WordPress, steady your nerves and remember that someone made this for you to use for free.

Navigate to “Configure Project” in the top menu and then follow the instructions in the terminal to run the configuration script. When prompted for your password, press Enter. This is the only action you need to take during the process.

Step 3: Install WordPress

Once configuration is complete, navigate to “WordPress Login” in the top menu. This will take you through the normal installation process.

Once you’re in, the last required step is to go straight to plugins and activate the Permalink Fix & Disable Canonical Redirects Pack plugin, which you’ll find pre-installed. Visit the front end like you normally would and you’ll see your shiny new WordPress site.

The URL for your site will look something like this:

http://theory-opera.codio.io:3000/wordpress/

Within the Codio interface you can easily edit WordPress core, theme, and plugin files, as well as upload new files. If you have WordPress projects hosted on GitHub, you can easily import those into Codio to make changes and push those changes back to the repository.

The cloud-based IDE is very similar to using WordPress on Koding in many respects, and I found it equally easy to set up on both services. Both provide a quick way to do some testing, without having to set up a development environment on your local machine. If you decide to experiment and break everything, it’s safe and easy to start over. Codio’s friendly environment provides a great way to get your friends or children started with using WordPress.

Since Codio was developed with educators in mind, the dashboard has a handful of helpful tutorials for learning about Git, an introduction to HTML and CSS, and an introduction to Javascript. If one of your 2015 resolutions is to get started learning some technologies outside of WordPress, such as Ruby, Python, or Angular, Codio is a great option for getting development environments up and running so that you can start learning right away.

When Google Reader was laid to rest on July 1, 2013, many users flocked to Feedly, one of the most popular alternatives. Even if you don’t use Feedly, it’s likely that many of your blog’s readers do. Therefore, if you want a true picture of the number of your RSS subscribers, digging into Feedly’s numbers should be part of your research.

Find Your Feedly Subscriber Count on Mobile

Feedly’s UI is notorious for being less than intuitive and confusing to navigate. If you poke around, you can find a rough number of your subscribers. If you’re using a mobile device, simply search for your blog (even if you’re already subscribed), in the top search bar and it will display a rough count.

Find Your Feedly Subscriber Count in the Web App

If you’re looking for your subscriber count in the web app, click your site in the left sidebar among your subscriptions and then look for your total subscribers under the title.

That’s not too difficult, but what if you want to know the actual count of your Feedly subscribers? After all, there’s quite a difference between 3,001 and 3,999, especially when you are looking at setting goals. Once you pass 2,000, it seems that Feedly resorts to fuzzy rounding to the nearest thousand instead of reporting actual figures.

Feedly Insight Plugin for WordPress

WordPress sites can install a plugin called Feedly Insight to get an exact subscriber count. It utilizes the Feedly Cloud API to tap into more exact data about your feed(s). Once you install the plugin, you’ll notice that it adds its own top level menu where you can click on the “Feedly Insight” submenu item. Scroll down to the search bar and enter your URL. It will return a few interesting stats, including languages and an exact subscriber count.

You can also search your competitors’ URLs in order to see how well they’re doing at attracting subscribers. After performing your research, you can keep the plugin if you want to keep track of your Feedly stats via its dashboard widget, or you can uninstall it and check back again later.

Having a full picture of RSS subscribers is important for publishers who want to tailor their content to appear better in feed readers. For example, if you find that you have a large number of Feedly subscribers, you will want to make sure that each post appears with an image. Feedly doesn’t have the ability to fetch your featured image. Instead, it grabs the first image displayed within your post to show as the thumbnail in its reader. If your post has no images, it will show a blank as the thumbnail, which isn’t ideal. Adding an image to each post will help you to avoid this.

You can also claim your own Feedly hashtag using this Google form, which allows you to have more control over what people find when they search for your brand or your #name.

If you’re a publisher, you cannot ignore Feedly, even if you’re not a fan of the product. Feed readers are still going strong and Feedly seems to be leading the pack after Google Reader died. If you have never checked to find out how many people are reading your blog through Feedly, you may be surprised. To get a rough idea, just log into the app. The Feedly Insight plugin offers a more detailed look and an easier way to monitor your stats.

This post was contributed by Ryan Hellyer. He is from New Zealand, lives in Germany, and works as a full-time WordPress geek for Forsite Media in the Netherlands. He spends his time building WordPress plugins and getting up to mischief in his adopted home of Berlin.

I have an issue with WordPress caching plugins. It’s not that I don’t like using them, or that they’re junk (most are, but that’s a separate issue). No, the problem is that most people don’t have the foggiest idea how WordPress handles caching internally, and what causes their site to run faster.

Static page caching

Most caching plugins do what is called static page caching. They cache a complete page, including all of it’s HTML. This is terrific, as it means that WordPress doesn’t need to regenerate the page every time someone visits it, but it means that those pages will be out of date sometimes when content is updated. Anyone who has used these plugins can usually attest to cursing at their site due to to the cache not updating when required.

Object caching

For a very long time, WordPress has had a caching system baked into it. Most WordPress developers I’ve met have no idea this exists. Some have used transients, which are a part of the WordPress caching API, but in my experience, very few developers properly understand how they work.

By default, WordPress includes an internal caching system. If you use get_option( ‘something’ ); somewhere in your site, then run that same code later on in that page, WordPress will only need to load the data from the database once, as it caches it for use later on in the page load. It does this via the wp_cache_add(), wp_cache_set() and wp_cache_get() functions.

Transients behave in a similar way, but by default can store the data for use in subsequent page views by storing them in the database. Storing information in the database is resource intensive though, so transients must be used sparingly to avoid hammering the database too hard and actually causing the site to slow down rather than speed up.

What we need is the ability to store information in a persistent way (for use on more than the current page load), which can be written to and from extremely rapidly (unlike caching in the database).

Persistent object caching

Although the object caching system in WordPress was designed to only work on a single page load by default, the smart folks on the WordPress core team ensured that it was trivial to plug into this and provide a way to store data however you want and for as long as you want. Awesome!

A normal WordPress plugin cannot be used to provide persistent object caching in WordPress. You need to manually create a drop-in file called object-cache.php, which sits in the wp-content folder. Some of the larger (bloated?) plugins, will automatically generate this drop-in file in your wp-content folder.

Once installed, the object caching drop-in will cache anything utilizing the WordPress caching API. This includes transients, which will automatically stop using the default database layer and instead make use of whatever object caching back-end is available.

Some of the earlier implementations of object-cache.php files for WordPress simply stored the data in the database, or in flat static files. But there are a multitude of better backends/places to store small pieces of data like this, and there are many different object caching drop-ins available for WordPress to hook into these various systems.

In-memory data stores – ninja fast data storage

MySQL is fast, but nothing compares to just throwing some data into RAM for maximum performance. With this in mind, many people who are much smarter than I, have developed systems for allowing us to store random bits of data in the server’s RAM. The most popular of these is Memcached, but there are others including APC and Redis which are very popular. Since they store their data in RAM (when possible) and are designed to be fast rather than reliable, they are insanely fast at both data storage and retrieval.

With a database or flat file caching back-end, you can not refresh your cache rapidly, or store tiny bits of data. With an in-memory data store, those problems do not exist. For this reason, use of an in-memory data storage back-end can provide an enormous performance advantage to sites using them in conjunction with the WordPress object caching API.

To make use of one of these, simply ensure that Redis, Memcached or APC are installed on your server, then install one of their corresponding drop-in files (you have to get the correct one or all hell will break loose).

Once you have an appropriate object caching drop-in installed, you should notice an immediate increase in performance. WordPress caches a lot of data internally and none of that will need to be queried on every page load.

It is entirely normal to see a stock WordPress installation go from 20+ MySQL queries per page down to 4 queries, as the object caching backend takes care of storing all of the data which does not change between page loads. The WordPress API always attempts to refresh the cache when required; there are some instances in which this does not work perfectly, but it is usually a flawless cache refreshing process.

Faster static page caching

There are ways to serve and refresh static page caching plugins via the WordPress object caching system too, including via the Batcache plugin, provided by the kind folks at Automattic. This is beyond the scope of this blog post, but it is worth investigating if you also require static page caching.

Conclusion

Caching within WordPress is complex. Object caching is a vital tool for your toolbox, as it can provide a huge performance improvement without requiring you to resort to full page caching.

This post was contributed by Tomaž Zaman. He is the founder of a Danish startup called Codeable, a WordPress-only outsourcing service on a mission to help WordPress companies and enthusiasts from all over the world effortlessly scale their businesses. He spends his free time with his wife and four kids.

A vast majority of online articles about speeding up your WordPress site mention and use a plugin called W3 Total Cache (or W3TC for short). Rightfully so, because it’s a great, all-in-one solution to get your WP site fast with relatively small amount of work.

However, I’m not really a fan of all-in-one solutions, mainly because they bring a lot of complexity to the table, and as far as WordPress plugins go, possibly introduce compatibility issues and upgrade headaches.

That is why I decided to look for alternatives that would still make our (secure) WordPress site really fast and a friend recommended to look at mod_pagespeed, which turned out to be a great solution for making our WordPress really fast, with minimal effort.

Prerequisites

This article assumes you have at least basic knowledge of linux (all our examples are Ubuntu-based), know how to use the shell, and most importantly, you host your site on your own VPS. Shared hosting isn’t going to cut it, since we need to set up a customized version of nginx, which supports mod_pagespeed.

Note that all commands that start with the dollar sign ($) indicate it’s a unix command, and you don’t actually enter that dollar sign into the command.

Main ingredients

As the title suggests, we’ll need a couple of programs installed on our server; The main one (for caching purposes) is called Varnish, which basically stores all your HTML output onto a temporary folder on disk and serves that instead of delegating requests to WordPress. It has one flaw, however – it does not support SSL termination, which is why we need Pound for.

The last two components we need are Nginx (it’s a web server like Apache) and a PHP process manager called PHP-FPM, since Nginx does not support modules.

Of course you also need to generate a certificate key and buy a certificate for this setup to work. Entry-level certificates are quite cheap, some starting with less that $10/year, which makes it a no-brainer.

Getting started

Provided you have a clean, fresh VPS ready, SSH on to it. Protip: If you use Linux or Mac OS locally, you can add the following a shortcut to ~/.ssh/config(create this file if it does not exist):

This allows you to run the following command to log into your server shell: $ ssh MyHost.

Once logged in, it’s time to install all the necessary components that we’ll need via a package manager, in our case apt-get.

Run the following command: $ sudo apt-get install php5-fpm php5-cli php5-mysql varnish pound mariadb-server-5.5 unzip You’ll be prompted to enter the root password for MariaDB, which is a drop-in replacement for MySQL, twice. We did not install Nginx at this point because the version that comes as the default, does not support mod_pagespeed, which we need, so we’ll install it manually. To do that, visit the official documentation and follow the guide, with one exception, replace this line:

This will make sure you also include modules that will help you GZIP static assets and allow you to track correct IPs in your WordPress, respectively. Once done, you should have Nginx installed in /usr/local/nginx/.

If you try to visit the URL (or IP) of your server at this point, nothing will happen, because we haven’t configured all the components properly yet. Once we do, the communication schema between components on our server will look something like this:

Pound

Let’s start with the outermost component, which should listen on two standard ports, 80 and 443 (HTTP and HTTPS, respectively). Edit the file /etc/pound/pound.cfg and put the following contents in:

Before restarting pound with this new configuration, you’ll also need to have a PEM certificate file in the defined folder, which you can create by following these instructions. You’ll also need to edit /etc/default/pound and set startup=1.

That’s it! Pound is now configured and after running $ service pound restart (on Ubuntu, other distributions may have different commands for service manipulation) you should be able to visit the configured domain. Of course, you’ll get an error (503 Service Unavailable), but that’s okay, we’re not done yet!

Varnish

Next, we need to configure Varnish. Edit the file `/etc/varnish/default.vcl and put the following in (delete everything else):

I won’t go into much details here, because official Varnish documentation does a much better job at that. Three things worth mentioning here are the lines that PURGE the cache (delete it), which comes in handy to have within WordPress so that updated parts automatically initiate cache removal. There are several plugins for that, we use Better WP Varnish, but any will do.

The second thing to mention is cookie handling. This configuration prevents logged in users to see cached versions of WordPress for easier debugging and previewing.

Last, we also use a custom header (X-Cache), which equals to either HIT or MISS so you can easily debug and see whether Varnish fetched a cached version (HIT) or not.

As with Pound, it’s now time to restart Varnish to load the new configuration: $ service varnish restart.

Nginx and mod_pagespeed

Almost there! The final piece of the puzzle is Nginx. Because we didn’t use the package manager to install it, we first need to set up an init script that will register Nginx as a daemon (a program or a process that runs in the background). In order to do that, run the following commands:

This downloads the init script, makes it executable (because it’s essentially a program) and registers it with the operating system so it can start at boot time.

Once that’s sorted, we need to configure Nginx by editing the file /usr/local/nginx/conf/nginx.conf. Locate the first server block in the file, and replace it with the following code (this assumes you have your WordPress installed in /srv/www/yourdomain.com):

The top half is just basic configuration for our virtual host which enables rewrites and delegates PHP processing to PHP-FPM (listening on a socket).

What’s interesting here is the pagespeed part. After turning it on, we need to properly map URLs so that mod_pagespeed will know when to trigger its magic. After that, we enable/disable various filters and it’s up to you to which level you want mod_pagespeed to modify/optimize your HTML so go ahead and play with them. My favorites are ones that automatically combine CSS and Javascript files, optimize images and rename them according to their last-modified time, so we can have a far-future expiration date.

There’s only one caveat: Make sure to disable convert_jpeg_to_webp filter. The name of the filter is pretty descriptive but can pose a problem because of Varnish. If the very first visitor of your website uses Chrome, Varnish will pass the request on to Nginx and it will detect that and serve images in WEBP format, filling the cache with them. All subsequent users will then get that cached version, but as WEBP is not yet widely supported users with other browsers won’t be able to see the images!

Now it’s time to see if our effort was fruitful; Restart Nginx to load the new configuration ($ service nginx restart) and visit the website. UH-OH! You probably don’t see what you expected, right? That’s because Varnish is working, and probably serving erroneous version in case you visited it before. The fix is simple, just clear all Varnish cache ($ varnishadm "ban req.url ~ /") and you should be able to see the proper output.

To verify, you might want to inspect the response locally: $ curl -i https://yourdomain.com. In the response you should see two headers: X-Cache and X-Page-Speed, which indicates you’re now a webmaster of a considerably faster WordPress website!

What about benchmarks?

I’ve been asked about benchmarking the results, but in this case, I don’t believe it would make much sense. There’s plenty of Varnish benchmarks out there, but mod_pagespeed isn’t just about speed (despite it’s name). As per it’s documentation it can do a whole lot to optimize your website output in terms of asset concatenation, minification and serving.

That being said, if you still prefer having hard numbers for this, feel free to test it out and report back and I’ll be more than happy to update this article with your findings.

Conclusion

What I didn’t address in this article is WordPress installation, GZIPping, error handling and various possible corner cases, but I think this tutorial should give you a good base to start off with on the path to improved user experience.

]]>https://wptavern.com/speed-up-your-wordpress-site-with-pound-varnish-nginx-and-mod_pagespeed/feed3530100How to Create a Quick Style Guide for Client Websiteshttps://wptavern.com/how-to-create-a-quick-style-guide-for-client-websites
https://wptavern.com/how-to-create-a-quick-style-guide-for-client-websites#commentsFri, 29 Aug 2014 22:23:12 +0000https://wptavern.com/?p=29499(more...)]]>The business of building WordPress websites is exploding, and most agencies and freelancers have more work than they can handle. Clients are attracted to WordPress because of how easy it is to manage content. In the old days, if you had a website built, you would still need to hire a developer to make updates to your content or design. WordPress makes it possible for anyone to create new posts, pages, products, etc., without any technical experience.

The flip side of this is that your design may be in danger when everything is so easy to edit. If you want to keep branding consistent across a website, you may need to include a style guide to breakdown the design you’ve created.

Having a style guide for reference is especially important if you are passing off a CMS to a client who will be using it to create content on a regular basis. Without a guide your client may go nuts with customization features that may be built into the theme. Before you know it, he will have used 10 different typefaces in various places and multiple header colors and sizes. The beautiful website you created can end up looking like digital goulash in the end, which is no good for your portfolio.

I’d like to introduce you to Stylify Me, a handy new tool that can automatically create a quick style guide for any website. Simply enter the site URL and the app will return its background colors, text colors, typography, and image dimensions.

Here are the colors you get when you input WordPress.org:

It also returns the typography and image dimensions found on the homeapage.

The download for your style guide comes in the form of a PDF, a somewhat inconvenient file type that many clients seem to love for whatever reason. Obviously, this is just a quick start which you can further edit and fine tune. Some homepages may not lend themselves as well to demonstrating the site’s style. In that case you may want to select another content page from which the app can extract styles more representative of the site as a whole.

The Stylify Me app was built on NodeJS and PhantomJS. Its creators, Annabelle Yoon and Michael Mrowetz, wanted to provide a tool that would allow designers to research sites more efficiently, without having to inspect each element. The app is hosted on Heroku using the multi buildpack and is MIT-licensed. Check out the code on GitHub to see how it works.

Stylify Me gives you the ability to quickly generate a style guide that will help your clients keep their websites within the realm of the original design. Providing a style guide adds an extra touch, which demonstrates that you care and are invested in your client’s success.

]]>https://wptavern.com/how-to-create-a-quick-style-guide-for-client-websites/feed1229499WordPress in the Cloud: How to Set Up a Development Site with Kodinghttps://wptavern.com/wordpress-in-the-cloud-how-to-set-up-a-development-site-with-koding
https://wptavern.com/wordpress-in-the-cloud-how-to-set-up-a-development-site-with-koding#commentsThu, 03 Jul 2014 08:07:33 +0000https://wptavern.com/?p=25728(more...)]]>

Koding is an online development environment where you can create and run apps in the cloud. The platform encourages collaboration and social interaction with an integrated activity stream where you can post status updates, code snippets and topics for discussion.

Koding includes an Ace code editor and a Linux terminal to your own private virtual machine where you can build applications or work with popular apps from its catalog. It currently supports Python, Java, Perl, Node.js, Ruby, C, C++, PHP, and Go. Setting up a WordPress development environment is simple and can be done in just a few minutes. In this tutorial we’re going to walk through the process step-by-step.

Step 1: Sign Up for Koding

While Koding has several pricing options, you can set up a WordPress site on the free developer plan without a problem. This is great for some light testing and experimenting. However, your VMs will be turned off within 15 minutes of idle time, deleting all of your sessions. Files are saved but it’s annoying to have to restart your VM, so you may want to upgrade if you end up using Koding regularly.

Step 2: Install WordPress

After you sign up with Koding and confirm your email address, you should already have your first VM set up, i.e. vm-0.username.kd.io. Navigate to the apps catalog and select WordPress.

Click on the button to install WordPress instantly. If you’re prompted for your password while the install script is running, simply press enter twice. You shouldn’t need to enter your password unless you’ve changed the root password for your account, otherwise you’ll get an error establishing connection with the database. You should see this screen when the installation is successful:

Click on the link to begin the famous 5-minute installation process. Once it finishes, you’ll be able to log into your new WordPress development site at http://username.kd.io/wordpress/

Wondering where to find your WordPress files? You can access them on the Dev Tools screen. WordPress is installed under the /Web/wordpress directory. Here you can view and edit any of the files in the app.

Step 3: Install FTP

In order to install themes and plugins you’ll need to first install FTP and connect it to your VM. Go to Terminal and install the PureFTPd apt-get package, by entering: sudo apt-get install pure-ftpd. Your Koding password is your root password, and you’ll be prompted to enter it.

Type “help ftp” in the terminal to display your host and username. This will give you the information you need to connect to FTP via Filezilla or another external client. The credentials follow this format:

However, when you’re trying to install a plugin or theme in the WordPress admin, your host will be “localhost.” The FTP username will be your Koding username and the password is your Koding password. Enter this info on the connection information screen when prompted and you’ll be able to install plugins and themes:

One advantage of working with a cloud-based IDE is that it doesn’t take up any of your computer’s resources. Your code is available anywhere that you have an internet connection. Setting up a WordPress development environment on Koding makes it easy to experiment with new plugins or themes and collaborate with other developers, even when running on the free developer plan. In under ten minutes you can be up and running, ready to start coding up experiments on a live server with public previews.

Pocket is a handy service for saving articles to read later. It has mobile apps for every platform and its own reader that makes any content easy to read on the go. Once in awhile you read an article that really inspires you. Pocket’s tagging feature makes it possible to share those articles on your own blog.

With a little bit of help from the IFTTT (If this, then that) service, you can easily reblog articles to a WordPress site. IFTTT triggers and actions are packaged into recipes. Here’s the recipe we’ll be starting from.

In order to use it, you’ll need to activate both the WordPress and Pocket channels when prompted. This will require you to put in your username and password for your blog so that IFTTT can access it to funnel content over.

First, you’ll need to create a trigger. Even if you’re starting from the recipe above, you can customize the “reblog” Pocket tag to something that works for you:

Next, you’ll need to set the action. You can customize the HTML to include the image, the excerpt (or opt for the full content), and link to the original article. You might even put “Reblog:” before the title, just to be clear.

The final step is to set up categories and tags for the post on your WordPress site. If you’re entering a new category here, then you’ll want to make sure this category exists on your WordPress site so there’s no conflict.

Before clicking the update button, you’ll need to choose from the post status options: publish immediately, save as draft, or publish as private. The simplest reblog option is to publish immediately. However, if you want to add your own thoughts at the top of the post or adjust it in any way, then you might select the “save as draft” option.

After you save the recipe, you’ll be ready to go. Anytime you want to reblog an article from Pocket, all you have to do is apply the tag you set in the recipe:

The re-blogged article will then get sent to your blog and placed under the correct category. IFTTT checks for new trigger data every 15 minutes for personal recipes, but sometimes the checks happen more frequently.

Re-blogging articles and adding your own thoughts is an easy way to keep fresh content flowing on your blog and to show people what you’ve been reading lately. The best part of this recipe is that it lets you hand-select the articles that you want to push to your blog. Once it’s set up, the only action required on your part is adding the “reblog” tag to Pocket articles. Everything else will happen automatically after it’s triggered.

]]>https://wptavern.com/how-to-reblog-articles-from-pocket-to-wordpress/feed125503How to Set Up Text Message Alerts for a WordCamphttps://wptavern.com/how-to-set-up-text-message-alerts-for-a-wordcamp
https://wptavern.com/how-to-set-up-text-message-alerts-for-a-wordcamp#commentsWed, 28 May 2014 19:08:24 +0000https://wptavern.com/?p=22934(more...)]]>

WordCamp Miami is one of the largest WordPress events in operation, with 770+ attendees and a large group of organizers and volunteers who turned out for its most recent 5th anniversary edition. It ran earlier this month with four days (Thursday – Sunday) packed full of activities. Multiple venues, parking areas, presentation tracks, catering and food vendors can all add to the likelihood of unexpected delays or changes in schedule.

How do you keep that many people informed with updates? Text alerts were the glue that kept everyone together on the same page, according to organizer David Bisset. WordCamp Miami utilized MailChimp’s Gather service to shoot out reminders and changes of schedule.

Many WordCamps use MailChimp to organize event emails. The Gather app allows you to text message your MailChimp email subscribers to keep them updated throughout the event. Subscribers can respond to organizers individually with no app or setup required. For example, if you want to alert everyone where parking is located, you can send a quick text in the morning. Attendees can also alert you to any problems.

When you set up a new event with Gather, it gives you a customizable signup form that you can share via Twitter, email or your MailChimp account. It also gives you a phone number to use that is separate from your personal number, so you can retain your privacy. The organizer never has access to subscribers’ phone numbers and the service automatically deletes the numbers after the event expires.

Pricing is a nominal fee that you pre-pay for bundles of text messages, depending on the size of your event: 175 messages for $8.99, 500 messages for $18.99, or 2000 messages for $48.99. This includes your new Gather phone number.

Getting Attendees to Sign Up For Text Alerts

Getting people to sign up for text alerts may not be the easiest task, as nobody wants to open up their phone to a flood of unimportant messages or info that’s already printed in the schedule.

It’s a good idea to assure your subscribers that you’re not going to overload them with texts. Make sure they know their numbers will be deleted after the event and that you’ll send only the important stuff. WordCamp Miami did a good job of this on its text alerts signup page:

We will keep the notifications to a minimum. They will involve any last-minute session/room changes, after party information, and emergency information.

Bisset had three separate text message channels for the event, including one for general attendees, volunteer corps, and WordCamp organizers. He said that it kept their team from having to run around and holler at each other for help during the event.

As an attendee and speaker at WordCamp Miami, I can attest to the fact that these text message alerts kept everything running like a well-oiled machine. I would highly recommend them to any organizer who is looking to improve the overall event experience for attendees and volunteers.

]]>https://wptavern.com/how-to-set-up-text-message-alerts-for-a-wordcamp/feed622934VVV Site Wizard Automates the Creation and Deletion of WordPress Development Siteshttps://wptavern.com/vvv-site-wizard-automates-the-creation-and-deletion-of-wordpress-development-sites
https://wptavern.com/vvv-site-wizard-automates-the-creation-and-deletion-of-wordpress-development-sites#commentsThu, 22 May 2014 19:30:50 +0000https://wptavern.com/?p=23348(more...)]]>photo credit: i is Ashby – cc

If you already have VVV up and running on your machine, download the wizard script:

git clone https://github.com/aliso/vvv-site-wizard.git

You can run ./vvv from the directory where you placed the script, but if you want to run it from any directory and not have to enter the path to VVV every time, you can edit the vvv root in the vvv-site-wizard/vvv script. Uncomment the line that begins with path= and add the path to your VVV setup. You’ll find it at the very top of the file:

You may also need to edit your bashrc file to make sure you can run vvv from a folder included in your PATH environment variable. Save and refesh your terminal and you should be good to launch your new site wizard.

The script’s Github homepage includes a list of options available for the vvv command, including site creation and teardown, setting the domain and site name, whether or not to provision vagrant or just create the site directory/files, path, the WordPress version to install, and the option to turn on WP_DEBUG and WP_DEBUG_LOG.

However, none of these options are required. If there’s a required piece of information missing from your original command, the script, in true wizard fashion, will prompt you for it, as shown below:

Once you proceed, the wizard will go about doing all the work of creating your new development site, including setting up the file in the nginx-config folder and creating the vvv-init.sh, wp-cli.yml, and vvv-hosts files. You’ll get a success message when it’s finished:

You can now visit your new development site in your favorite browser. Thank the wizard and get back to work! If you want to delete a site, running the teardown command (vvv -a delete mysite) will remove everything the wizard created, with the exception of the site’s database.