How to Become a Contributor to WordPress? Baby Steps… To Big Dreams!

Are you passionate about the Web and Free Software Movement? Are you looking for an opportunity to play your part? Perhaps you’ve considered contributing to the WordPress project? This tutorial is for you! Our free software developers have contributed to the core of the application and now they’d love to introduce you to the development process of the most popular on-line publishing platform in the world. Cheer up and follow these steps to get started!

Subscribe
You can begin your journey by subscribing to a variety of platforms used by contributers. This helps you establish a connection with the community and remain in touch.

WordPress
Subscribing to WordPress is a must. WordPress.org serves, among other things, to document procedures and publish information related to its development platform. This will be your main reference, so subscribe and log in.

Once you are connected, we invite you to consult the section of the website concerning Development and to get to know the different teams and their missions. This is also a great opportunity to subscribe to various newsletters if you wish to follow a particular stream of development (marketing, modules, themes, documentation, etc.)

Slack
People discuss their contributions via the Slack collaborative communication platform. They hold meetings, disseminate information and help users reach their contribution objectives. On Slack, you will find all the influential developers in the WordPress community, it is the ideal place to ask them questions!

Please read the subscription documentation carefully. The procedure can sometimes be confusing. If you are having trouble signing in to your WordPress.org account, visit the subscription page and the new instructions will show up. You can then sign in using this link: https://wordpress.slack.com/.

Trac
Your last step before contributing! Check out the Trac ticket manager. Every change in WordPress is documented here. The main developers use this tool to approve and integrate changes to the core. To ensure effective, accurate and coordinated development, using documentation is mandatory. Now we can get started with developing for WordPress…

Following the Best Practices
Let the fun begin! Before writing code, you will need to integrate the project’s best practices and development standards. Some documents will be more useful to you than others. We suggest that you focus on these sections: Core Contributor Handbook, Best Practices, and Writing Patches. For PHP developers, you will also be interested in the PHP Coding Standards and Core API documentation.

The Environment
The majority of developers use Varying Vagrant Vagrants (VVV), which runs under all operating systems. VVV is an open source Vagrant configuration focused on WordPress development. It is mostly used to develop themes, modules, and plugins as well as for contributions to WordPress core. It may be a bit complex to install optional Vagrant modules, so if you are using a Linux environment, just make sure you have the “build-essential” and “libc6-dev” libraries before you get started. Feel free to work with other tools as well. VVV is not the only choice you have. But if you choose any other tools, please do not forget to report your developments on WordPress’ core code repository, to track the testing and progress of your contributions!

Here is an example of installing a development environment using VagrantPress and Git deployed with Ubuntu.

git clone https://github.com/vagrantpress/vagrantpress.git
cd vagrantpress
vagrant up
rm -fr tests
git clone git://develop.git.wordpress.org/ tests
vagrant provision

SVN and Git
You have probably noticed that the code repository uses SVN. If you wish to contribute to the heart, we strongly recommend using it. But there is no obligation, it is also possible to go through Git. You will find the documents you need to use for these two versioning systems in the following libraries: How to Use Subversion for developers, plugin, codex for SVN and Using Git for the second.

CSS and Javascript
WordPress compresses some resources. To enable you to work, you must disable this function in the “wp-config.php”. Add “define (‘SCRIPT_DEBUG’, true);”.

Code Validation
WordPress code standards are most likely different from those you are used to. A code format checker can provide great help. Use PHP_CodeSniffer with the WordPress Coding Standards. You can also read the WordPress style guidelines for detailed installation instructions.

Test-based Contribution
Did you know that you do not have to be a seasoned developer to contribute to WordPress? For example, testing is a good way to participate in development while learning. Trac lists the corrections to be tested. If you are starting out, work first on non-urgent corrections.

Baby Steps… To Big Dreams!
Yes, contributing to a free software project is indeed a huge investment of your time. Reading, setting things up, making configurations, downloading, etc.

However, once you’ve passed the first steps and made your first few contributions, you will officially be a free software contributor! Now take this chance to make your first baby steps and realize your big dream of becoming a free software developer!

 

Automated Interaction Testing For Major Web Browsers

To improve and accelerate Web sites and applications testing, developers often use a class of tools called “headless browsers”. These tools are used to test the behavior of web browsers automatically, without visualization.

The most popular headless browsers are currently PhantomJS for http://en.wikipedia.org/wiki/WebKit, the layout engine of Safari and Chrome, and SlimerJS for testing under Gecko, Firefox’s layout engine.

We can also use CasperJS to facilitate the creation of test scenarios with the PhantomJS JavaScript API. Here is a short demo on “Automating with PhantomJS and CasperJS” by Chris Hawkes:

 

Finally (drum roll please!), the development of a new tool for Trident – the layout engine of Internet Explorer – started on Github this fall. That is important to note because over 50% of desktops browsing the Web are still equipped with a version of Internet Explorer, from version 6 (4.92%) to version 10 (17 , 5%) inclusive. In fact, TrifleJS is another add-on to PhantomJS for the .NET Windows environment.

What does this mean for web developers?

With these tools we can now:

  • Create screenshot scripts to see our web projects rendering in each of these three layout engines;
  • Check all the links of a web project and make sure that there is no 30X/40X/50X errors (e.g. 300,404,501);
  • Create integration tests for complex forms with 10,000 field entries;
  • Create an army of robots grabbing all the images of cats on Imgur. 🙂

Please check this website again after the New Year if you’re interested. I will try to set up a short demonstration and post it in my next blog post.

Modernize your deployment practices with Vagrant

Vagrant LogoA recurring problem in the world of web development is the complexity associated with setting up a suitable environment for each new project. If we’re lucky, we have up-to-date textual information to perform that setup. Even in that shiny world where we’re lucky, the time required to follow those textual instructions vary depending on the technical skills of the developer. Even when those instructions are up-to-date, it’s not rare at all to routinely spend many hours trying to set this new environment up.

Here at SFL, we recently started integrating Vagrant to our projects in order to modernize our deployment methods and results so far are very encouraging.

What is Vagrant?

Vagrant is a command line library allowing to quickly create and provision virtual environments through VirtualBox. It allows, with one vagrant up command, to create a VM from scratch and automatically configure it to host your project. For the configuration part, it’s integrated with Puppet, which is good for us because that’s already what we used here at SFL to manage our machines.

Benefits

Environment setup speed. What used to be a more or less relevant set of textual instructions is now executable Puppet code. This means that a new developer being brought to a project has one single command to type:

fab deploy

and within minutes, the site is ready to be used locally.

Setup reliability. Gone are the times of textual instructions that fall into obsolescence and make new developers want to tear all their hair off (well, the hair tearing part is not entirely gone, but at least it’s not over environment setup anymore). If the Puppet code becomes incorrect over time, it’s very easy to spot immediately and correct it.

Homogenous deployment environments. There used to be a time when we developers had to describe to our sysadmins the production environment that we needed for a new project, and then they would do their best to understand what we meant and build it. Now, with Puppet, developers and sysadmins speak the same language. The same code that is used to build a local environment can be reliably used by sysadmins to replicate that environment elsewhere.

How to use it?

How you use Vagrant depends on the type of project you use it with. For example, our Django projects use a mix of Vagrant and Fabric to perform setup and deployment. The Puppet side takes care of “OS specific” setup (installing packages, configuring Apache, creating databases) and Fabric takes care of “Python code specific” setup (pushing the code to the environment, pip dependencies, South migrations).

I’ve published, on Github, a sample Vagrant-enabled Django project that looks a lot like what we do internally so you can easily experience the potential of that solution. If you have Git, VirtualBox, Vagrant and Fabric installed on your machine, you can run this project (from nothing) with these commands:

git clone https://github.com/savoirfairelinux/django-vagrant-demo
cd django-vagrant-demo/deploy
fab deploy

Then, you can visit http://demo-django.local:8080 and see the newly-deployed site.

The deploy script will ask for your sudo password because Vagrant and the Fabric script need to modify your /etc/hosts file to make demo-django.local to 127.0.0.1.