Tag Archives: wordpress

On Citizenship in Open-source software development

I’ll steal the TL;DR from the author:

TL;DR: By giving an actual social status to the people contributing to a repository, GitHub would solve the problem of zombie-projects with a scattered community. By allowing these citizens to actually collaborate with each other, instead of just with the owner, repositories will live as long as the community exists, completely on auto-pilot.

Ignore “GitHub” for a second and replace with WordPress.org. Upvoted contributions to by_the_people_ branches on plugins could be an interesting way of addressing the stale plugin or unresponsive plugin author issue.

On Citizenship in Open-source software development

v0.6 of Varying Vagrant Vagrants has been pushed

Plenty of changes and plenty of contributions this round. Great stuff!

  • Add WordPress Unit Tests
  • Option for custom shell provisioning file
  • Pre/Post provisioning hooks via additional shell scripts
  • Flags system to disable portions of default provisioning
  • Grab stable WordPress from latest.tar.gz vs SVN
  • Append custom apt sources list to default
  • Update to SVN 1.7.9, addresses specific Windows permissions issue
  • Move wp-cli to /srv/www/ for easier contributions

v0.6 of Varying Vagrant Vagrants has been pushed

Varying Vagrant Vagrants has moved (a bit)

Code, ,

Varying Vagrant Vagrants started off 4 months ago as a shot in the dark to solve a problem I was having. As development progressed, it became immediately clear that this was something we wanted to have in the 10up bag of tricks while we’re working with varying production environments. The contributions from other 10uppers have been fantastic and it quickly became obvious that this should grow in 10up’s area of GitHub rather than in my little personal corner.

Things have come a long way and we now have a great base to start branching from. The next hope is to see custom Vagrantfiles from groups like WordPress.com, ZippyKid, WPEngine, DreamHost, GoDaddy, Bluehost, or anybody else doing WordPress hosting.

We’ll keep the pressure going on that front and over the next few days do a better job of explaining the overall goal for Varying Vagrant Vagrants, how we’ll use it internally, and how you may be able to use it or a variant for your own development process.

In the meantime, if you’ve already cloned the repository, please make sure that your git remotes are up to date if you’d like to pull in changes.

Hi WordPress, Meet Vagrant

Code,

Over the last few months I’ve been planting seeds with every WordPress developer I run into with the hope of convincing them to use Vagrant to manage their development environment. The basic pitch has evolved with time and now that I’ve had the chance to fine tune it for 10up’s recent developer summit, I’m going to lay it out here as well.

LAMP via MAMP / XAMPP / WAMP

It helps to start with what we’ve been working with so far. The first step to developing for WordPress is to make sure your environment meets the minimum requirements. As of today, these are PHP 5.2.4 and MySQL version 5.0 or greater.

The beginning of WordPress development was often like the wild west. Cowboys abound, PHP files were edited in some form of a text editor and uploaded directly to the server for testing. White screens were a good indicator when things went wrong.

As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a basic development environment could be setup with relative ease. White screens now happened locally first and more rarely in production.

MAMP, XAMPP and WAMP came along and provided a few click method of creating a stable LAMP sandbox for us to play in. With the minimum requirements for WordPress development met, things got stable and stale.

Meeting Environment Requirements

Rather than meeting minimum requirements, Vagrant provides a flexible way for a developer to meet environment requirements.

How about a server running Ubuntu 12.0.4, nginx, PHP-FPM, MySQL, memcached and the PECL memcache extension? Vagrant does that.

And CentOS 6.4 with nginx, PHP-FPM, MySQL, memcached and the PECL memcached extension? This too.

Or Debian 6 with page caching provided by Varnish or Redis… Can also do.

But wait.. still working with that project hosted on Apache, MySQL and PHP?

Vagrant does that.

This Matters?

This matters. The closer you can be to your production environment during development, the more confident you can be that the code you are pushing has been tested properly.

When that tricky cache expiration issue appears, the tools will be immediately available to confirm and troubleshoot it. When somebody on your team needs to jump in to help on a project, only a couple commands stand between them and a full matching system.

And at the end of the day, when you are done with development, one command powers off this amazing virtual environment and leaves you with a personal computer.

Go Try It and Chime In

10up has a pretty decent setup going over at Varying Vagrant Vagrants. A walkthrough from a few weeks ago is up at Evolving WordPress Development With Vagrant. We’re continuing to cruise ahead with a common nginx, MySQL, PHP-FPM and memcached setup, but we’ll be branching off to our other environments shortly as well. If you have an environment you’d like to see matched, fork the repository and give it a go.

And If Your Name Is Mo Or Barry…

Hi!

What we have in our default provisioning so far is pretty close to a basic version of the WordPress.com server environment. We would love to help create a Vagrant setup that matches production as closely as possible and can be used by anybody developing a project with that in mind. Ping me when you’re game. :)

Cache issues be gone!

Evolving WordPress Development With Vagrant

Code, ,

Yesterday we tagged version 0.2 of Varying Vagrant Vagrants, an evolving Vagrant configuration with an end goal of providing a system to pass development projects between team members at 10up for easy ramp up on projects. While any development project can be supported, our initial focus is WordPress. If you’re doing any kind of WordPress development, you should check it out. If you check it out and you fall in love, you should think about working with us.

UPDATE 04/12/03: This post is a great intro and provides good context  for the overall Vagrant discussion that’s been happening. Quite a bit has changed in the last few weeks and I would recommend stopping by Hi WordPress, Meet Vagrant for some of the latest fodder. Thanks!

What is Vagrant?

Vagrant is an open source “tool for building and distributing development environments”. Created by Mitchell Hashimoto, it provides a method to automatically provision a headless virtual machine for use with virtualization software such as VirtualBox. The various configurations of these virtual machines are sandboxed away from your local machine.

What is VirtualBox?

VirtualBox is open source virtualization software from Sun Microsystems. It provides a method to handle these prepackaged virtual machines, or boxes, that are configured with Vagrant.

What is Varying Vagrant Vagrants?

Varying Vagrant Vagrants is an exploration into the world of of Vagrant and how it can help to make development efficient and in sync with production systems. It replaces the common MAMP or XAMPP setups that we have become familiar with and ensures that all members of the team can develop in the same environment for a project without worrying about the operating system on their local machine.

One development environment is currently provided with Varying Vagrant Vagrants.  This includes Ubuntu 12.0.4 with Nginx, PHP-FPM, MySQL and Memcached. While this does not match every production environment, it has become a very common setup for highly scalable WordPress sites. It is these sites where developing in sync with production can be the most important. The closer we can come to matching the exact environment, the more likely we are to catch bugs and environment specific situations before deployment.

How Do I Get Started?

Getting started is easy, and will more than likely take you less than 30 minutes.

  1. Download and install the latest version of VirtualBox for your operating system.
  2. Download and install the latest version of Vagrant for your operating system.
  3. Clone or download the Varying Vagrant Vagrants repository to a local directory.
  4. Navigate to the new directory and type `vagrant up`

With that, your virtual machine is running. Test it immediately by going to 192.168.50.4 in a web browser. To start working with WordPress, one more step is necessary.

  • Modify your local machine’s hosts file so that `local.wordpress.dev` is mapped to `192.168.50.4`.

Once mapped, visiting `local.wordpress.dev` in your browser will bring up an initial WordPress installation. Follow through that to create your first WordPress development environment in Vagrant. Themes and plugins that you are developing can go into the respective `www/wordpress-default/wp-content/` directories.

From here, you should experiment.

If you are familiar with object caching, the common plugins for working with PECL memcache can be installed. Memcached itself is already installed and running for when you’re ready.

If you start poking around the internal documentation for Varying Vagrant Vagrants, you’ll see quite a few places where you can hook in with customizations of your own to continue to extend the development environment.

What’s Next?

Two goals are driving the development for the next releases of Varying Vagrant Vagrants.

  1. Provide a way to start with one of multiple WordPress configurations. Multisite is an obvious addition, but it would also be nice to include configurations for object caching as well as helpful development plugins.
  2. Provide a way to pass projects around with a Vagrantfile and WordPress configuration included that can help others jump in to assit immediately.

Please feel free to pass along any feedback or issues with the current release via the GitHub issues page. Any input is much appreciated!

If you want to geek out on some context for my Vagrant experience so far, check out these posts:

A WordPress Meetup Introduction to Vagrant – What You’ll Need

Code, ,

Note: I’ll be giving a couple of talks about getting started with Vagrant over the next couple months and I intend for this to be a decent description covering some of the basics those who are attending should complete. If are planning on attending in PDX or Seattle, please read this through and complete the steps as best you can.

I wrote an initial blog post a couple months ago that highlights my fascination with Vagrant and may help give a broad overview of the problem I was trying to solve. Keep in mind that I went from eager excitement to mind blown user of Vagrant within 24 hours. This will be you.

Now, ignore everything there and start from scratch.

VirtualBox

VirtualBox is an open source (GPL) cross-platform (that’s everyone!) virtualization application. Oracle provides a great overview in its first steps documentation here - https://www.virtualbox.org/manual/ch01.html

  1. Download the latest version of VirtualBox (4.2.6) for your operating system and install it on your computer. https://www.virtualbox.org/wiki/Downloads
  2. Download the matching VirtualBox Extension Pack (4.2.6), the same for all platforms, and install it on your computer. Having VirtualBox installed should make this a recognized file type. https://www.virtualbox.org/wiki/Downloads

Vagrant

Vagrant is an open source (MIT) tool that allows you to setup one or multiple development environments on your local machine that are sandboxed away from your operating system. The getting started guid describes it best:

“Vagrant uses Oracle’s VirtualBox to build configurable, lightweight, and portable virtual machines dynamically.”

I’ll go into much more detail during the presentation, but this is a good start.

  1. Download the latest stable version of Vagrant (1.0.6) for your operating system and install it on your computer. http://downloads.vagrantup.com/tags/v1.0.6
  2. Read the overview page of the getting started documentation for Vagrant. If it doesn’t make sense, don’t worry. A familiarity with the terminology will be helpful. Bonus points for every page past the overview section you read. It will all be helpful the second time around. http://docs.vagrantup.com/v1/docs/getting-started/index.html
  3. Additional reading is available under the general documentation section. http://docs.vagrantup.com/v1/docs/index.html

Create a project.

Vagrant is best explained when you are already up and running with it. To best be prepared for the meetup, it would be great if everyone had the following completed.

  1. Somewhere on your computer, decide where you want a local environment to live and navigate to that directory. For sanity, I’m going to use ‘pdxwp-vagrant‘ as the environment directory and ‘development‘ as the directory it will live in on your computer.
  2. Navigate to the containing directory via ’cd development‘
  3. Clone the varying vagrant vagrants repository with ‘git clone https://github.com/10up/varying-vagrant-vagrants pdxwp-vagrant`. This will create a directory called ‘pdxwp-vagrant‘ in your ‘development‘ directory that contains all of the files we will need to start up vagrant.
    • If you don’t have git available to you by the command line, you can extract the repository’s zip file into a ‘pdxwp-vagrant‘ directory instead.
  4. Change into the ‘pdxwp-vagrant‘ directory and type ‘vagrant up‘
    • A series of messages will appear indicating that Vagrant is downloading a ~600MB box that will act as the base of the virtual machine that we are building. This box started with a specially packed version of Ubuntu 12.0.4 made available directly from Vagrant’s servers. I then installed nginx, mysql, php-fpm and memcached before repackaging it for distribution. This allows us to skip a lot of the provisioning.
    • Boxes are cached in your user’s home directory under ‘~/.vagrant.d/boxes`. As long as nothing changes with the ‘config.vm.box‘ or ‘config.vm.box_url‘ parameters in your ‘Vagrantfile‘, the box should stay cached on your system until it is deleted so that you do not have to download 600MB every time you start the server.
  5. Once ‘vagrant up‘ has finished, you’re ready to go. By default the IP address of the box is ‘192.168.50.4‘. Add an entry for this IP address to your hosts file that points to ‘local.wordpress.dev‘. This will give you access to a default WordPress install right off the bat.

And you’re ready! At this point, don’t worry about screwing anything up. As long as you have VirtualBox and Vagrant installed and the 600MB box cached to your machine, interacting with the box during the meetup will be a breeze.

See you soon!

WordPress Is Not Caching Your Custom Feed

WordPress, ,

So.

You’ve hooked into the appropriate core actions, loaded a template file and added a quick echo to test the beginnings of your feed. You bring up a browser, load the feed, and are satisfied when you see the output you were expecting.

Now, you code out the rest of the feed. Put in a query, loop over the results and mold your output. Sweet.

Refresh the feed in your browser and bam – same test output from before.

What the?

You hit Google and start searching. One place tells you to delete your transients, another tells you to define your own Magpie cache settings. All of them were written in 2007.

And then you run into this page, which dutifully informs you that WordPress is not caching your custom feed.

You are. In your browser. Clear the cache.

The Evolution of Asides

Technology, ,

For some reason or another I was searching email archives and ran into a ‘brain note’ I sent myself in early 2005 that linked to an article on coding ‘asides’ into your WordPress blog using a combination of a plugin and a bunch of custom code.

I remember being in love with the various link log formats that sites like Kottke had setup at the time and I remember specifically copy and pasting Matt’s code from his post that coined the term ‘asides’. Experiences like this really got me thinking about how software worked and what blogging was.

It’s great that 7 years later it has become obvious that not every post needs to follow one format and that in order for someone to post something in the format they want, no crazy code wrangling is necessary. The evolution of this seems natural, which is the best way, and thinking about how asides happened goes hand in hand with articles like Om Malik’s Blogging Reinvented.

We’re all still figuring out the best way to display the information we want to share while not ignoring the information we want to keep private. At the same time we’re creating more information every day than we ever have. Fortunately, the way things go, we’ll all keep stumbling through this together (some shouting loudly) and look back in another 7 years at how cool everything turned out.

If you run into this post and you’re thinking of fun ways to display information, send me an email or a tweet. I’m projecteuring a bunch right now and ideas are fun.

The (De) Construction Of Twitter

Educer, , , , ,

$new_standard = strtolower("Twitter");

In the last couple of weeks, both WordPress and Tumblr have announced support for the Twitter API.

The immediate benefits are that any forward thinking Twitter client can now also be a WordPress or Tumblr client as well. Tweetie, one of the most popular iPhone clients, has had support for this for a while and immediately became the tool of choice for testing the new features out. Choices for users expand.

So, with that development aside, where next? I see three things.

1) WordPress should publish an official plugin for WordPress.org that enables the Twitter API for any blog. This act alone could create millions of possible twitter servers.

2) WordPress/Tumblr should make a big deal about how their new changes are also already tied in with real time protocols RSSCloud and pubsubhubbub. This helps make the new twitter servers real time.

3) Everybody outside of Twitter should huddle for a brief second and add some new syntax to the existing twitter api that allows for a piece of metadata to be attached (urls to start), call it optional, and implement.

Or, in short– Now that you’ve shown how easy it is to implement Twitter’s API, rip it out of their hands, build a new community, and then market the hell out of it.