This entry is part 2 of 4 in the Unit Tests for WordPress Plugins Series
- Unit Tests for WordPress Plugins – An Introduction
- Unit Tests for WordPress Plugins – Setting Up Our Testing Suite
- Unit Tests for WordPress Plugins – Writing Tests
- Unit Tests for WordPress Plugins – The Factory
In part one of this tutorial series we briefly looked at what unit tests are and we walked through a couple of simple examples to illustrate how we can use them to help ensure our code is working properly. Now it is time to actually setup our testing suite and run our first unit test.
There are quite a few different ways to setup unit tests in your WordPress plugins, but by far the easiest is through WP-CLI, a command line interface for WordPress. Due to its simplicity, we will use WP-CLI to setup our unit tests in this tutorial.
If you are not familiar with or comfortable with the command line, you might be tempted to walk away from unit tests now and maybe come back another day. I am going to try and keep this as simple as possible, so I’d encourage you to stick with me as you will quickly find that the command line is not nearly as scary or difficult as some make it out to be.
Note: WP-CLI requires a unix-based operating system like Mac OS X or Linux. Once our testing suite is setup, everything will be almost identical for all users, but only Linux and Mac OS X users can utilize the WP-CLI tool.
What is a testing suite?
The phrase “testing suite” simply refers to our collection of unit tests and our configuration for those unit tests. When we say that we are going to setup the testing suite, we mean that we are going to install PHPUnit (or similar), we are going to create our configuration file, and we are going to write our initial unit tests.
Watch the video below for a quick example of what running our unit tests looks like:
Once we are done with the steps below, we should be able to run the phpunit command from our plugin’s directory and have our unit tests run.
For this tutorial series, we are going to write unit tests for my Restrict Content Pro plugin.
1. Install PHPUnit
The first thing we need to do is install PHPUnit. The readme file in the Github repository for PHPUnit has the instructions on how to do this.
Simply follow the installation instructions on the Github page and then proceed to the next step below.
If you run into any issues installing PHPUnit, leave a comment below and I will do my best to help you.
2. Install WP-CLI
WP-CLI is also exceptionally simple to install, and you can find the install instructions here.
If you run into any issues installing WP-CLI, leave a comment below and I will do my best to help you.
3. Use WP-CLI to setup our plugin’s unit tests
Now we are almost ready to really get into the fun part of unit tests: actually seeing our unit tests run. Before we do that, however, we need to utilize WP-CLI to create our initial unit tests configuration.
Since I’m doing this along with you for my Restrict Content Pro plugin, I will continually refer to Restrict Content Pro (or RCP). Anytime I do, just substitute in your own plugin’s name.
WP-CLI includes a step-by-step guide of how to setup unit tests in your plugin, but I’m going to walk through it here as well.
First, we need to open the command line and navigate to our WordPress install’s main directory. Your exact file path will be different than mine, so be sure to adjust for where you have WordPress installed.
cd sites/wordpress/
Second, we need to instruct WP-CLI to create the initial unit test files for us:
wp scaffold plugin-tests restrict-content-pro
This will generate all of the files needed for our unit tests. If you now navigate to your plugin’s folder and type ls -l, you will see several new files and folders added.
cd wp-content/plugins/restrict-content-pro ls -l
Before:
After:
The new folders / files created:
- bin/
- install-wp-tests.sh
- tests/
- bootstrap.php
- test-sample.php
- phpunit.xml
- .travis.yml
These files are the foundation of our plugin’s test suite.
Now, run this command:
bash bin/install-wp-tests.sh wordpress_test root '' localhost latest
Replace “root” with the username of your database and replace ” with the database password. Also replace “localhost” with the hostname of your database. You can find all three of these values in your wp-config.php file.
You can now type phpunit into the command line and the unit tests will run:
phpunit
The testing suite that WP-CLI sets up for us includes one sample unit test, which you can see was run successfully. Let’s take a look at the sample test. It is located in tests/test-sample.php:
class SampleTest extends WP_UnitTestCase { function testSample() { // replace this with some actual testing code $this->assertTrue( true ); } } |
If you look at what this test does, you will probably notice that it isn’t really testing anything useful. It simple checks if true is equal to true, which we know it is, but it provides a nice example that is easy to follow.
Now our testing suite is setup and we are ready to begin writing our own tests.
4. Writing your first test
Before we jump into writing an actual unit test, let’s first look how PHPUnit knows what to execute as unit tests. The phpunit.xml file is the main configuration file that instructs PHPUnit on what to do. By default, it looks like this:
<phpunit bootstrap="tests/bootstrap.php" backupGlobals="false" colors="true" convertErrorsToExceptions="true" convertNoticesToExceptions="true" convertWarningsToExceptions="true" > <testsuites> <testsuite> <directory prefix="test-" suffix=".php"d>./tests/</directory> </testsuite> </testsuites> </phpunitd>
This tells PHPUnit where to look for the PHP file that gets everything running (tests/bootstrap.php), defines a few options, and then also tells PHPUnit where the actual unit tests live. In this case, the unit tests live in the tests directory and are all of the .php files prefixed with test-. This means that any file we place in the tests directory and name test-something.php will be considered unit tests. This allows us to easily organize our unit tests into groups, which we will discuss more later.
Note: only methods prefixed with “test” will be considered a unit test. All other methods will be skipped.
Let’s write a quick sample test now to help get a better grasp of what we’re doing. This test won’t do much meaningful, beyond providing a nice example.
To write a new test, all we need to do is create a new method inside the SampleTest class, like this:
function test_sample_string() { $string = 'Unit tests are sweet'; $this->assertEquals( 'Unit tests are sweet', $string ); } |
This does nothing more than setup a variable called $string, set its value to “Unit tests are sweet”, and then checks that “Unit tests are sweet” is indeed equal to the $string variable. If we now run PHPUnit, we will see that we have two tests and both are passing successfully:
Awesome! We have now written a successful unit test. That’s awesome and you are now a heck of a lot further along on your journey to understanding and utilizing unit tests than a huge number of developers.
Let’s now do another quick demonstration. Change our test_sample_string() test to this:
function test_sample_string() { $string = 'Unit tests are sweet'; $this->assertEquals( 'Failing Unit tests are sad', $string ); } |
And now run phpunit again:
Our simple unit test now fails because we are trying to assert that two very-non-equal strings are equal to each other. Since the two strings are not the same, our test fails, and PHPUnit tells us that, including why it failed and the exact line number that failed.
When writing unit tests, there are two main terms we often use to describe what we are doing: “tests” and “assertions”. A “test” is a collection of assertions and an assertion is one check within a test. Each test must contain at least one assertion but a test may also contain many assertions. The sample test we wrote above contains one assertion.
We will learn more about writing tests and assertions in the next part of this series.
Pippin, absolutely awesome!! A few days ago when i checked the EDD github sources (i use the EDD framework for my own plugin “Mashshare”), i noticed that you are using unit tests and hoped you would write a nice how-to about using unit tests for WP plugin development… some day in the future. Now you are doing it! Thats Incredible and a great happenstance. Thanks man, its a pleasure to participate on your experience.
Best,
René
Glad to hear it’s helpful!
You might need to define the WP_TESTS_DIR by running export=”path/to/wordpress-develop/tests/phpunit” if you get an error on running the tests.
Thanks for the tip, I’m sure someone will run into that.
I stumbled with this problem. But I cannot figure out what exactly do I need to do or have. Can you please help? Thanks
Oh, Figured out I also need to download something extra from WordPress trunk for the tests to work. That was causing the problem. I only had the standard WP install.
I just updated the tutorial to include that. I accidentally left it off.
So, yeah – you need to install the WordPress test suite, from svn or git:
http://make.wordpress.org/core/handbook/automated-testing/#installation
http://make.wordpress.org/core/2014/01/15/git-mirrors-for-wordpress/
This contains all that is needed for running tests. You’ll also have access to factory methods for creating mock posts, comments,etc…
That’s where defining the shell variable WP_TESTS_DIR comes in. It points to your checkout of the WordPress test suite which contains a src/ directory and a tests/ directory.
If you use the bash script to install to the tmp folder, then if you’re using Vagrant for example, the folder will be cleaned up after you run vagrant halt.
This is actually for the Travis build process, as on each pull request, it will re-install the tests to run them on Travis.
Hi Pippin,
For quite some time I’ve wanted to start with TDD, but before your tutorial it seemed somewhat complicated and I didn’t invest the time to look further into it. Your tutorial is definitely making TDD much easier to understand for sure!
I guess another thing issue was that I kind of wanted to start with tests for my own plugins, since I don’t have time set aside when working with clients for writing tests.
Anyway, up until three months ago I was really enthusiastic about doing TDD, until I read this article here – http://www.phpclasses.org/blog/post/237-7-Reasons-Why-TDD-Failed-to-become-Mainstream.html . What are your thoughts on that as someone that has used tests for I’m assuming a reasonable amount of time?
I will be starting my own (development) company in the near future and product quality will be one of the top priorities. I plan on doing code reviews for code written by the new developers until they produce the desired quality code(you know, following the WordPress coding standards, not writing hacky-ish stuff, using wp_enqueue_script() instead of writing stuff in the header, etc.). Do you think incorporating tests in all/most of our projects is a step in the right direction?
Note that I plan on starting with people that have little to zero experience with PHP/WordPress and giving them a month or two of training, so teaching them to do tests can be easily incorporated in the training.
Regardless of what that article, and others, say, writing unit tests for your codebase can only be good thing. TDD may not be as prevalent as it used to be, but getting into that mindset is still a huge positive.
Yes, writing tests for your code and others will make your codebase more reliable and will make you a better developer.
For example, just yesterday I found a bug in Easy Digital Downloads that had been there for nearly a year. I found it only because a unit test suddenly started failing (it was a date sensitive bug). If it wasn’t for that unit test, I would likely have never known that bug existed.
That’s fair – I’ll definitely put TDD on my todo list before hiring anyone so that I can make it a part of the training program.
Great tut, as usual. Pretty sure in this sentence: “This tests PHPUnit where to look for the PHP file…” you meant “This tells PHPUnit where to look…”
Corrected, thanks!
Thanks for the tutorial. Can’t wait to read part 3.
A few gotchas I encountered…
I installed this on an existing test server with WordPress already installed so running the install-wp-tests.sh as is was generating errors as it attempted to create the database. The fix was to remove the install_wp and install_db calls, but still allow the install_test_suite function.
The other issue I encountered was that the plugin I was testing doesn’t have a file names after the folder name (i.e my-plugin & my-plugin.php). The fix was to modify the /test/bootstrap.php file, updating the _manually_load_plugin() function to include the correct file.
Scratch that. I still needed to install WP and the DB so no need to modify the .sh file.
The plugin I was testing had a dependency so to run it correctly I had to again modify the /tests/bootstrap.php file and update the _manually_load_plugin() function:
function _manually_load_plugin() {
require dirname( __FILE__ ) . ‘/../../gravityforms/gravityforms.php’;
require dirname( __FILE__ ) . ‘/../pdf.php’;
}
add a private variable to the test class of $plugins_dir and then use this to get the base of the plugins directory…
“`
$dir = dirname( __FILE__ );
$last_dir = null;
while ( ‘plugins’ !== $last_dir ) {
$dir = dirname( $dir );
$dirs = explode( DIRECTORY_SEPARATOR $dir );
$last_dir = array_pop( $dirs );
}
$this->plugins_dir = $dir;
“`
Lot of great info thanks I look forward to your future posts.
you’re doing it wrong
Thanks so much for this — I’ve installed the WordPress core tests about half a dozen times at this point and only through your tutorial realised that I don’t need to do any of that, and instead of just run the bash script in plugindirectory/bin/. Nobody writes tutorials with WP-CLI in mind, which is silly because it’s like the best way to do everything ever.
That’s exactly why I wanted to start this series: I found myself struggling through how to set it up numerous times, then I found out just how simple it is via WP CLI.
I’m reading through this to get into Unit Testing.
Some hurdles I got over already:
* You need to install the WP Development suite (in a seperate directory on your system?) and add a export (to your .bash_profile?)
(this comment: https://pippinsplugins.com/unit-tests-wordpress-plugins-setting-up-testing-suite/#div-comment-383236)
* You need to make sure the terminal (and WP-CLI) uses the correct PHP version if you use MAMP (http://wp-cli.org/#mamp)
wp scaffold now creates these files: http://monosnap.com/image/cujc4AvWT1gLO4lxdkQv0GYf436ZOa
It doesn’t create the bin folder. Any idea on where to start looking for this?
Hi,
I am following your tutorial to add tests to an existing plugin.
However I keep getting ‘session_start(): Cannot send session cache limiter – headers already sent’ .
There was a function added to ‘init’ with add_action that sets up the session, so I know where the problem lies in the code.
Is there a way to circumvent this by configuring the tests?
It’s legacy code that I don’t want to break simply to add unit tests.
Thanks for the excellent tutorial, they are a rare breed these WP plugin unit testing tutorials 🙂
Unit tests and session data is tricky. I’d suggest disabling your session start during the setup process of the unit tests. You can do this in the bootstrap.php file.
What if I want to test a theme? There is only plugin-test scaffold
Unit testing themes is nearly identical if not exactly identical.
I am getting error:
install-wp-tests.sh: line 73: mysqladmin: command not found
Upon running the install script..
That means MySQL is not installed (or not running) on your machine. You’ll need to set that up.
If you are on OS X, the easiest way is by using MAMP or MAMP Pro.
Well, I have it installed. For some reason it now works. I run:
sudo bash bin/install-wp-tests.sh wordpress_test root root localhost latest
But I receive the error message:
+ EXTRA=’ –host=localhost –protocol=tcp’
+ mysqladmin create wordpress_test –user=root –password=root –host=localhost –protocol=tcp
mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to MySQL server on ‘localhost’ (61)’
Check that mysqld is running on localhost and that the port is 3306.
You can check this by doing ‘telnet localhost 3306’
But I can connect through Sequel Pro: https://www.dropbox.com/s/bygsx9agt5x9h6u/Screenshot%202015-01-02%2022.32.24.png?dl=0
Are you using Mamp?
No, I have MAMP running and Sequel Pro.
The issue before was that I didn’t add mamp to my path. Adding it solved the initial issue.
Just to be clear, I still receive the error message:
+ EXTRA=’ –host=localhost –protocol=tcp’
+ mysqladmin create wordpress_test –user=root –password=root –host=localhost –protocol=tcp
mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to MySQL server on ‘localhost’ (61)’
Check that mysqld is running on localhost and that the port is 3306.
You can check this by doing ‘telnet localhost 3306′
One thing I notice is that in Sequel Pro I connect to my localhost using socket. If I enter “localhost” in the “Standard” login method (using host, username, password), I get error message:
“To MySQL, ‘localhost’ is a special host and means that a socket connection should be used.
Did you mean to use a socket connection, or to connect to the local machine via a port? If you meant to connect via a port, ‘127.0.0.1’ should be used instead of ‘localhost’.”
I choose “socket” and I can connect. Could this have anything to do with it?
Hmm, I’ll be honest that I’m not familiar enough with MAMP to say for sure.
Have you seen the guide that WP CLI has for troubleshooting MySQL connections with MAMP?
We have been using wp plugin check plugin to test our plugins. But the info you shared here is 10 steps ahead. We hope to use this technique when ever we got stuck in debugging our next plugin.
I have this setup and it’s working, but the basic tests are failing. It might be because I have this in a multisite setup. Is there something special I have to do for multisite?
Hi Jason
Yes, you need to add a constant or a separate xml file for that. You can change your phpunit.xml declaring a constant like this example:
./tests/
Whoops, the site removed the xml tags in my previous comment. Let’s try again:
Hi Jason
Yes, you need to add a constant or a separate xml file for that. You can change your phpunit.xml declaring a constant like this example:
https://gist.github.com/igmoweb/bfaab7e99833a3758843
I did figure that one out eventually, but I’m just having so many problems with wp-cli.
Like, it doesn’t create the uploads folder for the wp test suite, not to mention the suite gets deleted every time I restart then I have to reinstall it again, and the code in the install-wp-test.sh file keeps getting removed.
I seems like there are just some major bugs right now.
You can select your own installation and suite in bootstrap.php. The .sh installs everything in /tmp, that means that it will be deleted every time you run Vagrant. Instead of that you can modify the .sh and select another dir to install, it should be easy.
However, as you can see I’m having some difficulties when rolling back the database so I may end up using another method.
Now that I’m around 🙂 I have a question.
When I execute the tests the database is not rolledback to the clean status, not sure why. The transaction query is done by the tests suite and the rollback too but the data that my plugin inserts in its own tables persist. Anyone has experienced the same?
Thanks.
Hmm, it’s definitely supposed to be.
Did you do anything outside of the standard WP CLI install / setup?
Nothing but execute it in Vagrant. If I found something I’ll post it here, I haven’t had time today.
Thanks.
Well, this is killing me. I got absolutely nothing after many hours. All I can do is to call an uninstallation function right after tearDown is executed (if I do it right before, a few errors appear telling that TEMPORARY TABLE does not exist) in tests but I still don’t understand why the transaction is not affecting my tables, they keep the data between tests.
I’ve even checked your EDD tests to see possible differences but is difficult to see them. My activation function just creates the table and I call that function right after the bootstrap file is loaded using activate_plugin WP function.
For the moment I have a solution, but I don’t really like it.
Thanks for sharing. I will do for my plugins also.
On my Ubuntu server, most of the WordPress core tests are failing with errors from MySQL: “WordPress database error Lock wait timeout exceeded”. My database allows 30,000 connections and has 16GB RAM available, though there is actually no significant load while the tests are running. Are you by chance familiar with this issue?
Hmm, that’s odd. I have not seen that before.
Do your own plugin tests work or do they fail too?
It turned out to be a bug in the WordPress unit tests, something to do with closing the database connections at the end of each test in the suite. They fixed it right away, so all the tests are working now.
Hi Pippin, looks like there are all kinds of formatting errors in the code – “d” appended to closing “>”, some of the php code has “>” instead of “>”:
Fixed!
Thank you for this very useful tutorial. It works great on command line.
Now, do you know how to configure Netbeans to run the WP unit tests from the Netbeans interface?
I do not know how to do that.
Netbeans comes with an inbuild terminal. You can use this for executing any command lines or you can run unit tests directly from the netbeans GUI. May the following tutorial is helpful: https://netbeans.org/kb/docs/php/phpunit.html
Me also fails to test because the assert that two which i am trying to give equal value to each non equal strings, but got it now.
Can you show me the assertion you’re making and the error message shown?
When I run ‘phpunit’ I get this error:
PHP Warning: require_once(/tmp/wordpress-tests-lib/includes/functions.php): failed to open stream: No such file or directory in /var/www/html/wordpress/wp-content/plugins/[plugin]/tests/bootstrap.php on line 8
PHP Fatal error: require_once(): Failed opening required ‘/tmp/wordpress-tests-lib/includes/functions.php’ (include_path=’.:/usr/share/php:/usr/share/pear’) in /var/www/html/wordpress/wp-content/plugins/[plugin]/tests/bootstrap.php on line 8
Sorry for not seeing your comment earlier! I had some issues with Akismet automatically trashing a bunch of comments.
Did you manage to get past the issue?
If you’re using the Git mirror, which uses an src/ directory, you’ll need to modify the path(s) in bootstrap.php else you’ll get errors when running phpunit.
Thanks for this helpful series of articles on unit testing WordPress plugins. I just watched a Lynda.com video series about using PHPUnit and they did a good job of explaining the testing process using mocks and stubs, but nothing about WordPress of course. Your posts really bring it all together for me.
By the way, I was able to get WP-CLI to install and work on Windows. I used composer to install it and then added its location to my Windows Path variable (and then restarted the command prompt). The wp scaffold command seems like magic! Reminds me of Ruby on Rails a bit (interesting how concepts cross over between platforms).
To follow up to my own comment, I found that although I was able to get WP-CLI installed on Windows, I couldn’t run the bash command, which should have been fairly obvious if I had read closer. The solution seems to be to use Linux or install a virtual development environment on Windows or Mac, for example by using Vagrant.
Glad to hear it!
Just get started with Unit test and follow this article. However, I meet the same problem as Linnea where I couldn’t run the bash script on Windows. WP-CLI still runs well. Hope WP team can fix this issue soon because Windows users are a lot.
I was able to get PHPUnit working on Windows 10 after combining a few different tools. In order to run the bash command I installed Cygwin (https://www.cygwin.com) which allows you to run Linux commands in Windows. Don’t forget to install the wget, curl and subversion packages during the setup as well since you’ll need those to make it work. I hope that’s helpful for someone.
And Pippin, thanks for the great introduction.
Couple of hurdles I found:
1. Using MAMP, if you get error like this:
`mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to MySQL server on ‘localhost’ (61)’
Check that mysqld is running on localhost and that the port is 3300.
You can check this by doing ‘telnet localhost 3300’`, you can go into your MAMP preferences and under Ports, change your MySQL port to `3300`.
2. If you make the wrong command for `bash bin/install-wp-tests.sh` you may end up with wordpress installations at `/private/tmp/` with incorrect credentials (`/tmp` is a symlink to `private/tmp`). So you can either manually update them or delete them (`sudo rm -r /private/tmp/wordpress*`), delete the database you just made via the MAMP phpMyAdmin page and run the command again correctly. Note that there are TWO wordpress directories that get created:
wordpress
wordpress-tests-lib
`wordpress-tests-lib/wp-tests-config.php` needs to have working credentials.
Also you can reference the `install-tests` script without any arguments for a reminder of what arguments are needed:
$ bash bin/install-wp-tests.sh
usage: bin/install-wp-tests.sh [db-host] [wp-version]
Am I understanding correctly that(unless bootstrap.php points elsewhere) phpunit is using these temporary wordpress installations to test the plugin?
Another question I’m wondering is if since by using the private/tmp location the WP install needs to be recreated each time, do you then also have to manually delete the database before running `bin/install-wp-tests.sh` each time you want to test?
That would be the reason for moving the WP installs to a “permanent” location, the path to which would be referenced when you export `’WP_TESTS_DIR’` location in your `.bash_profile` as referenced above, correct? Then you’d just need to keep the WP installation clean and updated, right?
This is a lengthy comment so hopefully not too SPAMmy.
Sorry for not seeing your comment earlier! I had some issues with Akismet automatically trashing a bunch of comments.
Did you manage to get past the hurdles? If not, I’ll be more than happy to help out still.
Hey Pipin,
Thanks for this tutorial.
I am able to install WP CLI and Phpunit test successfully.
I also ran bash bin/install-wp-tests.sh wordpress_test root ” localhost latest command but when I run phpunit at that time nothing is displayed on terminal screen.
Am i missing something? Do I need to setup config parameter in wp-config.php file which was created in /tmp/wordpress/wp-config.php
Your help would greatly be appreciated.
Thanks!
:Malay
Sorry for not seeing your comment earlier! I had some issues with Akismet automatically trashing a bunch of comments.
Were you able to get the issue resolved?
I just want to thank you for this writeup. I’m in my final year of software engineering and have to test a web app I’m creating in WordPress. I’ve spent the last 2 hours trying to set everything up and ran into 2 problems. I am using MAMP for Apache, MySQL.
The first:
“wp scaffold plugin-tests restrict-content-pro” gave me an error of “Error establishing a database connection”. It turns out that my PHP versions weren’t the same across my applications and system. I followed this simple tutorial to get it working: http://laurenpittenger.com/wpcli-error-establishing-database-connection-mamp/
The second:
“Can’t connect to MySQL server on ‘localhost’ (61)” when entering “bash bin/install-wp-tests.sh wordpress_test root ” localhost latest”. Someone posted a fix in an earlier post, and I didn’t see it until it was too late. But going into MAMP and changing the port from the default 8889 to 3306 will solve this. You have you change the port, and then restart MAMP for it to take effect!
Onto the next part of the tutorial. Thanks again!
Thank you for posting your solutions!
Hello.
Whenever i try “wp scaffold plugin-tests my-plugin” i receive this error messag:
Invalid plugin slug specified.
I’m using windows.
WP-CLI 1.1.0
PHPUNIT 4.8.0
PHP 5.6
I don’t know what to do anymore!
I’ve seen that happen on Windows. Unfortunately I don’t know the answer for how to resolve it.
I can create a plugin using scaffold but not the “plugin-tests”
It’s driving me nuts. If i can solve this issue onde day i’ll post it here.
Thanks Pippin anyway.
Hi Pablo,
I had the same issue and I think the issue is with the vendor\wp-cli\wp-cli\php\commands\scaffold.php file. When using windows, I was receiving the same error. On further examination, it looks like the check_target_directory function fails when comparing the WP_PLUGIN_DIR with the $parent_dir.
A quick fix to get your command working is to change the check_target_directory function to validate the $parent_dir against the WP_PLUGIN_DIR realpath (see below)
if ( “theme” === $type ) {
if ( WP_CONTENT_DIR . ‘/themes’ === $parent_dir ) {
return true;
}
} elseif ( “plugin” === $type ) {
if ( WP_PLUGIN_DIR === $parent_dir ) {
return true;
}
elseif ( realpath(WP_PLUGIN_DIR) === $parent_dir ) {
return true;
}
}
I will look to either raise a bug or perform a pull request over the next few days, but hopefully this will provide a temporary fix for you.
Hi Carl,
Thanks. I’m going to take a look and tell you if it worked
Firstly, thanks for the article. As a WP newbie, I found it extremely useful and informative.
However, I am having trouble installing the install-wp-tests.sh on Windows 10. The database is being created, but the tmp directory and associated files are not. I have exhausted all options and I can’t figure it out.
Has anyone else come across this issue and managed to resolve the problem?
Thanks in advance,
Carl.
Hello again Carl,
Unfortunately the problem persists… As you were saying I’m on Windows 10 too.
I think i’m going to use Vagrant and VirtualBox to simulate other OS
I’m liking Docker as opposed to Vagrant: https://medium.com/@tatemz/local-wordpress-development-with-docker-3-easy-steps-a7c375366b9#.7yqy4aae7
Easy WordPress/php with Docker I have just discovered: https://github.com/chriszarate/docker-wordpress-vip
even simpler: https://github.com/chriszarate/docker-compose-wordpress