Same WordPress plugin, new name

A little while ago, I created a plugin called Suspend Transients. It is a helpful tool that allows developers to bypass get_transient()  calls on any page by clicking a button on the admin bar.

I felt that the name was not accurate so I have renamed it and it is now available for download on as Bypass Transients.

Development is happening on GitHub and pull requests are welcome along with any and all feedback in the comments below!

Thanks Adam!

WordPress 4.7 was just released and it marks the sixth release in a row that I have been lucky enough to contribute to.

Contributing to WordPress core has always been a personal goal for me and while I had made attempts in the past, it wasn’t until I joined 10up that I was finally able to contribute back to the open source project that pays my bills.

Contributing to WordPress Core is not hard in and of itself but what can be hard is the ramp up. WordPress is 13 years old, that’s a lot of project history to grok! Besides that, there is trac and the technical side that a new contributor has to figure out before they can even get to place to start writing code.

Having someone to help you navigate the waters of WordPress core contribution is invaluable. For me, that person was ( and still is ) Adam Silverstein, a friend,  and fellow 10upper. Without his help, guidance and patience, I would probably still be trying to figure out how to get someone to look at my tickets 🙂

Adam was recently given commit access to WordPress Core and I wanted to congratulate and thank him for everything he has done for me personally and for the larger WordPress community.


Better Unit Testing with DataProviders

When unit testing your code, there are times when you need to test the same method or function with a variety of different parameters. For example, we have a function to check to see if a passed email is both valid and not already in the list of known emails:

We can run a simple test on this by creating a new test class:

The test above will pass but it doesn’t cover all of the possibilities that this function could run into in the real world. What happens if the email already exists or is not a real email? We need those tests too.

We have a couple of options to create those tests:

  • Write a new test function for each possible combination.
  • Use a DataProvider and run the same test using that data it provides.

Option 1: Write more tests.

Let’s start by looking at the first option. We will need to write a new assertion for each of the possible cases. Which looks like this:

These tests are valid but there is a fair amount of duplication in the code. The only real differences between the three assertions are the expected result, the email we’re adding and the known list. The rest of the code is the same.

What if we have a way of passing those three items as parameters to the same test? Well we do, it’s called a DataProvider.

Option 2 : Use a DataProvider

At its base, a DataProvider is a function that returns an array consisting of the parameters for each assertion to be run:

In practice, DataProviders usually returns an array of values for each test simply because at the very least you will want to pass the expected result of the test and a value to pass to the code your testing.

We’ll need to refactor our test code a bit in order to use a DataProvider:

As you can see, the testing function now accepts 3 parameters that will be passed to it from the DataProvider which looks like this:

** Just an aside here, the name you use for the Data Provider doesn’t matter, I tend to use the convention of using the test function name and changing test_  to data_  to make the association clear. ***

Each of the arrays being returned contains the parameters, in order, that the test function is expecting; The $expected_result , the  $new_email  we’re adding and the $list_of_known_emails

At this point, we have our testing function and the DataProvider ready but they don’t know about each other. Connecting them is easy, we simply a new annotation to the testing function and PHPUnit will make the connection for us:

Now when we run our tests, the test_is_new_and_valid_email  test will run for each index in the DataProvider array and will be passed their parameters. If you ever need to add another test case, it’s a simple as adding a new array to the DataProvider!

As you can see, even though there is a little more setup involved for a DataProvider, your tests become more concise and easier to maintain and extend.

Here is the final test class with some comments:

What do you think of dataProviders? Are they useful? Please let me know in the comments!

New WordPress Plugin: Suspend Transients

Recently while working on a project in WordPress, I found myself adding and remove code to bypass cached transients. Needless to say, this was not a great solution. It caused needless code churn and sometimes it MAY have gotten committed to master.

As a result, I wrote a new WordPress plugin that will allow me to bypass transients on any given page.

I give you Suspend Transients!

It’s available on GitHub and pull requests are welcome!

Should we trust WordPress Core translations?

A while ago I was working on a patch to refresh the code for the default widgets that are included with WordPress Core. One of the changes made was to replace the i18n methods currently in-place with their counterparts that escape and translate the output. This is a pretty common practice as translation files can be a potential attack vector for hackers. VIP will usually request that this is added to any strings being translated and it is part of the 10up best practices.

One of the comments made was that Core trusts it’s translation files. For the sake of moving the ticket forward, I reverted those addition but it does lead me to a larger discussion of why we are trusting translation files. Another conversation referenced (#30724) pretty clearly states the reasons that core strings are not escaped but I think we should re-examine that policy.

The argument that we should trust the because they can be vetted by the team is somewhat valid in my opinion however, what if a malicious script is used change the location of file that is loaded? At that point, it doesn’t matter how well-vetted the original file is, it’s been replaced. If the escaping methods were being used, then the worst that could happen is that the strings look strange – which is a lot better than malicious script tags being rendered all over the page.

Adding these functions into Core, doesn’t hurt anything. It just makes Core a bit more secure. We are already escaping data being rendered in attributes and form fields so why not translated strings as well?

Another benefit to having using these functions in Core is the education factor. Many developers ( myself included ) learn the “WordPress way” of doing things by looking at Core source code. Developers may have no idea that their translation files are a potential entry point for hackers and so by having the code they are learning from set the example, they ( hopefully ) will follow suit.

I’d love to hear your thoughts in the comments below.

Setting up Unit Testing for WordPress Core

Recently I was running into issues with VVV running some units tests for AJAX. I was not able to remedy the issue so I decided to create a testing environment from the SVN repo directly.

I went to the page on the codex and while the information there was great, part of the instructions are to setup a different database for your tests but not how to get mysql setup and ready for anything to connect to it.

After a bit of digging around I found a simple approach for setting up a test suite for WordPress core unit tests. This setup does not account for viewing WordPress in a browser it was really only meant for unit testing but you could easily set that up as well if required.

Using homebrew, install mysql

Once installed, start the server

Once the server has started you can login using the default user (root) and password (blank)

You may be prompted for a password  if so, just hit enter.

Now you can create the tables as needed. There are two commands here because we need a database for WordPress regular use and one for unit testing because the test suite will drop all of the tables in the database each time it’s run.

That’s it! Now your databases are all setup to use.

Next, checkout the WordPress repo into your user folder and change to that directory

Now edit the wp-config.php and wp-test-config.php adding in the appropriate database connection info for each.

I found that I needed to set the DB_HOST constant to instead of localhost to have the connection work.

If everything is setup correctly, you can run the unit test suite from inside the root of the core repo.

Once you’re done with your testing you stop the mysql server as it can cause conflicts with other tools that use their own mysql installations.

That’s it! Happy unit testing!


First WordPress core props!

It was a very simple patch, just removing some code that is no longer needed, but now that ticket #31485 has been committed, I will have contributor props for WordPress 4.2!

Update: 4.2 was released today and I am very happy to have played a (small) part in it!

Photos or it didn’t happen!Window_and_Credits_‹_Ryan_Welcher_—_WordPress


Debug Bar Tracer Plugin

I have just released a new plugin called Debug Bar Tracer. It is meant to work with the Debug Bar plugin that should be a staple of any WordPress developer’s toolkit. The idea behind it is quite simple – I am always printing data out to the browser when developing and it always breaks the page and looks horrible. This plugin just adds a new panel that will show you the location of the call ( complete with file name and line number ) as well as the data you are sending out.

Please take a look and let me know what you think!


Bye bye ActionScript

So I’ve decided to retire the Action Script section of my website. I don’t really work with Flash all that much anymore and to be honest, I’m getting quite rusty at it. The posts will still be available but I won’t be adding anymore moving forward.

Dreamweaver Command – French Characters

I recently developed a Dreamweaver command to automate a process I hate to do manually – turn French characters into their HTML entities. It’s pretty straight forward, highlight the copy you want to scan, select French Characters under the Commands menu and follow the prompts.

To install, unzip the files and drop them into your Commands folder.

I wrote it for CS5 but have since tested it in CS6 and it works.