wp-browser
wp-browser copied to clipboard
[BUG] Can't access WP built-in functions even when using WPLoader
This is probably a config error on my part, but I'm stuck trying to work out what I'm doing wrong...
Environment OS: Linux PHP version: 8.0.30 Installed Codeception version: 5.0.12 Installed wp-browser version: 4.0.10 WordPress version: 6.3 Local development environment: PHP built-in server WordPress structure and management: default
Can you perform the test manually? N/A
Codeception configuration file
namespace: Tests
support_namespace: Support
paths:
tests: tests
output: tests/_output
data: tests/Support/Data
support: tests/Support
envs: tests/_envs
actor_suffix: Tester
params:
- tests/.env
extensions:
enabled:
- Codeception\Extension\RunFailed
config: { }
commands:
- lucatume\WPBrowser\Command\RunOriginal
- lucatume\WPBrowser\Command\RunAll
- lucatume\WPBrowser\Command\GenerateWPUnit
- lucatume\WPBrowser\Command\DbExport
- lucatume\WPBrowser\Command\DbImport
Suite configuration file
# EndToEnd suite configuration
#
# Run end-to-end tests.
actor: EndToEndTester
bootstrap: _bootstrap.php
modules:
enabled:
- lucatume\WPBrowser\Module\WPBrowser
- lucatume\WPBrowser\Module\WPDb
- lucatume\WPBrowser\Module\WPFilesystem
- lucatume\WPBrowser\Module\WPLoader
- Tests\Support\Helper\MyCustomTestHelper
config:
lucatume\WPBrowser\Module\WPBrowser:
url: '%WORDPRESS_URL%'
adminUsername: '%WORDPRESS_ADMIN_USER%'
adminPassword: '%WORDPRESS_ADMIN_PASSWORD%'
adminPath: '/wp-admin'
headers:
X_WPBROWSER_REQUEST: 1
X_TEST_REQUEST: 1
X_APM_REQUEST: 1
lucatume\WPBrowser\Module\WPDb:
dbUrl: '%WORDPRESS_DB_URL%'
dump: 'tests/Support/Data/dump.sql'
populate: true
cleanup: true
reconnect: false
url: '%WORDPRESS_URL%'
urlReplacement: false
tablePrefix: '%WORDPRESS_TABLE_PREFIX%'
lucatume\WPBrowser\Module\WPFilesystem:
wpRootFolder: '%WORDPRESS_ROOT_DIR%'
lucatume\WPBrowser\Module\WPLoader:
loadOnly: true
wpRootFolder: '%WORDPRESS_ROOT_DIR%'
dbUrl: '%WORDPRESS_DB_URL%'
domain: '%WORDPRESS_DOMAIN%'
Describe the bug
In v3 of the software, I was able to call wp functions (like sanitize_title()
) in my tests and also my helpers - but the config seemed to be a little different in v3.
Now that I have upgraded, these functions are not recognised. I am using WPLoader
which is supposed to support exactly this case, so presumably my config is wrong - but I cannot see what...
Output Here is the top of one of my Cest files:
<?php
namespace MyNameSpace;
use Tests\Support\EndToEndTester;
class BlogArchiveCest
{
public function _before(EndToEndTester $I)
{
$bob = \sanitize_title('dslkfjdslfsdjlfs');
die;
{
public function itShowsTheCorrectBlogArchivePage(EndToEndTester $I, \Codeception\Example $example)
{
$url = $example[0];
$I->amOnPage($url);
$I->seeCurrentUrlEquals($example[1]);
$I->dontSeeElement('.error-404.not-found');
$I->dontSeeElement('.no-results.not-found');
}
}
and this is the (slightly redacted) error (note that I never get to the die;
command):
$ codecept run tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php --fail-fast
Tests.EndToEnd_wpbrowser Tests (22) -----------------------------------------------------------------------
E BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"(0.00s)
------------------------------------------------------------------------------------------------------------
Time: 00:09.634, Memory: 19.12 MB
There was 1 error:
1) BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
Test tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:itShowsTheCorrectBlogArchivePage
[Error] Call to undefined function sanitize_title()
#1 /Documents/Current/Charles/Clients/client/code/client/tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:51
#2 Client\BlogArchiveCest->_before
#3 /Documents/Current/Charles/Clients/client/code/client/vendor/symfony/console/Command/Command.php:291
#4 /Documents/Current/Charles/Clients/client/code/client/vendor/bin/codecept:120
ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
To Reproduce As above I suppose
Expected behavior
Codecept/wpbrowser should recognise and call the worpdress sanitize_title()
function.
Additional context
I am using WPDb to load the database, and when I run codecept in -vv
mode, I can see that database is connected to OK. I tried switching WPLoader to loadOnly: false
but (as expected) it didn't like this because WPDb was loading the database.
@charlesdeb I've reproduced your configuration and setup locally and could run the tests without issues.
Could you run the tests with the --debug
flag and let me know what you see in the setup phase? There may be something that is preventing WordPress from loading correctly that I'm not seeing locally.
Thanks for your help here.
codecept run tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php --fail-fast --debug
Codeception PHP Testing Framework v5.0.12 https://stand-with-ukraine.pp.ua
[Connecting To Db] {"config":{"tablePrefix":"test1_","populate":true,"cleanup":true,"reconnect":false,"dump":["tests/Support/Data/dump.sql"],"populator":"","urlReplacement":false,"originalUrl":"","waitlock":10,"createIfNotExists":false,"dbUrl":"mysql://client-test:4DcBi&0F6axAR2w*@localhost:3306/client-test-1","url":"http://client.wpe.local","dsn":"mysql:host=localhost;port=3306;dbname=client-test-1","user":"client-test","password":"xxxxxxxx"},"options":[]}
[Db] Connected to default client-db
The WordPress installation will be loaded after all other modules have been initialized.
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["admin_email_lifespan",2533080438,"yes"]
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["_transient_doing_cron",1698158902,"yes"]
Tests.EndToEnd_wpbrowser Tests (22) ----------------------------------------------------------------------------------------------------------------------------------------------------------
Modules: \lucatume\WPBrowser\Module\WPBrowser, \lucatume\WPBrowser\Module\WPDb, \lucatume\WPBrowser\Module\WPFilesystem, \lucatume\WPBrowser\Module\WPLoader
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
Signature: Client\BlogArchiveCest:itShowsTheCorrectBlogArchivePage
Test: tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:itShowsTheCorrectBlogArchivePage
Scenario --
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["admin_email_lifespan",2533080438,"yes"]
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["_transient_doing_cron",1698158904,"yes"]
ERROR
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Time: 00:03.917, Memory: 19.12 MB
There was 1 error:
1) BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
Test tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:itShowsTheCorrectBlogArchivePage
[Error] Call to undefined function sanitize_title()
#1 /media/edrive/Documents/Current/Charles/Clients/client/code/client.wpe/tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:51
#2 Tbnuk\BlogArchiveCest->_before
#3 /media/edrive/Documents/Current/Charles/Clients/client/code/client.wpe/vendor/symfony/console/Command/Command.php:291
#4 /media/edrive/Documents/Current/Charles/Clients/client/code/client.wpe/vendor/bin/codecept:120
ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
[Db] Disconnected from default
When I run this test without a call to sanitize_title
and let the test fail naturally (because I actually need the santize_title
function in order for the test to work), I get an expected error a bit like:
codecept run tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php --fail-fast --debug
Codeception PHP Testing Framework v5.0.12 https://stand-with-ukraine.pp.ua
[Connecting To Db] {"config":{"tablePrefix":"test1_","populate":true,"cleanup":true,"reconnect":false,"dump":["tests/Support/Data/dump.sql"],"populator":"","urlReplacement":false,"originalUrl":"","waitlock":10,"createIfNotExists":false,"dbUrl":"mysql://client-test:4DcBi&0F6axAR2w*@localhost:3306/client-test-1","url":"http://client.wpe.local","dsn":"mysql:host=localhost;port=3306;dbname=client-test-1","user":"client-test","password":"xxxxxx"},"options":[]}
[Db] Connected to default client-db
The WordPress installation will be loaded after all other modules have been initialized.
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["admin_email_lifespan",2533080438,"yes"]
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["_transient_doing_cron",1698159285,"yes"]
Tests.EndToEnd_wpbrowser Tests (22) ----------------------------------------------------------------------------------------------------------------------------------------------------------
Modules: \lucatume\WPBrowser\Module\WPBrowser, \lucatume\WPBrowser\Module\WPDb, \lucatume\WPBrowser\Module\WPFilesystem, \lucatume\WPBrowser\Module\WPLoader
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
Signature: client\BlogArchiveCest:itShowsTheCorrectBlogArchivePage
Test: tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:itShowsTheCorrectBlogArchivePage
Scenario --
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["admin_email_lifespan",2533080438,"yes"]
[Query] INSERT INTO `test1_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["_transient_doing_cron",1698159287,"yes"]
I am on page "/blog/"
[Request Headers] {"X_WPBROWSER_REQUEST":1,"X_TEST_REQUEST":1,"X_APM_REQUEST":1}
[Page] /blog/
[Response] 200
[Request Cookies] []
[Response Headers] {"Date":["Tue, 24 Oct 2023 14:45:47 GMT"],"Server":["Apache/2.4.57 (Ubuntu)"],"Link":["<http://client.wpe.local/wp-json/>; rel="https://api.w.org/""],"X-TEC-API-VERSION":["v1"],"X-TEC-API-ROOT":["http://client.wpe.local/wp-json/tribe/events/v1/"],"X-TEC-API-ORIGIN":["http://client.wpe.local"],"Vary":["Accept-Encoding"],"Transfer-Encoding":["chunked"],"Content-Type":["text/html; charset=UTF-8"]}
I see current url equals "/blog/"
I don't see element ".error-404.not-found"
I don't see element ".no-results.not-found"
FAIL
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Time: 00:10.428, Memory: 19.12 MB
There was 1 failure:
1) BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
Test tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:itShowsTheCorrectBlogArchivePage
Step Don't see element ".no-results.not-found"
Fail Element '.no-results.not-found' was found
Scenario Steps:
4. $I->dontSeeElement(".no-results.not-found") at tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:143
3. $I->dontSeeElement(".error-404.not-found") at tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:142
2. $I->seeCurrentUrlEquals("/blog/") at tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:141
1. $I->amOnPage("/blog/") at tests/EndToEnd_wpbrowser/themes/client/public/BlogArchiveCest.php:139
Artifacts:
Html: /media/edrive/Documents/Current/Charles/Clients/client/code/client.wpe/tests/_output/client.BlogArchiveCest.itShowsTheCorrectBlogArchivePage.2c5ac16.fail.html
Response: /media/edrive/Documents/Current/Charles/Clients/client/code/client.wpe/tests/_output/client.BlogArchiveCest.itShowsTheCorrectBlogArchivePage.2c5ac16.fail.html
FAILURES!
Tests: 1, Assertions: 3, Failures: 1.
[Db] Disconnected from default
And when I look at the artifact html file from the fail, then I can see that the correct website has been loaded and wpbrowser has visited the correct page - so wpbrowser is definitely heading on the right track. My test code just doesn't seem to be getting access to WP's built in functions - and in v3 this stuff all worked with no issues.
It must be something simple!
Thanks @charlesdeb for providing the output of the debug run.
Something is missing from the output, though.
When I run the same test on my machine with the --debug
option, I get more things:
cr Issue --debug
Codeception PHP Testing Framework v5.0.12 https://stand-with-ukraine.pp.ua
Suite name: Issue
Starting PHP built-in server on port 2389 to serve var/wordpress ... ok
Starting ChromeDriver on port 2390 ... ok
Starting compose stack ......... ok
[Connecting To Db] {"config":{"tablePrefix":"wp_","populate":true,"cleanup":true,"reconnect":false,"dump":["tests/_data/dump.sql"],"populator":"","urlReplacement":true,"originalUrl":"","waitlock":10,"createIfNotExists":false,"dsn":"mysql:host=127.0.0.1;port=2391;dbname=wordpress","user":"root","password":"password","url":"http://localhost:2389"},"options":[]}
[Db] Connected to default wordpress
The WordPress installation will be loaded after all other modules have been initialized.
Rebuilding IssueTester...
Dump file URL [wordpress] replaced with [localhost]
[Query] INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["admin_email_lifespan",2533080438,"yes"]
[Query] INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES (?, ?, ?)
[Parameters] ["_transient_doing_cron",1698302872,"yes"]
Issue Tests (1) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Modules: \lucatume\WPBrowser\Module\WPBrowser, \lucatume\WPBrowser\Module\WPDb, \lucatume\WPBrowser\Module\WPFilesystem, \lucatume\WPBrowser\Module\WPLoader
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
WordPress status: {
"rootDir": "/Users/lucatume/oss/wp-browser/var/wordpress/",
"version": {
"wpVersion": "6.3.1",
"wpDbVersion": "55853",
"tinymceVersion": "49110-20201110",
"requiredPhpVersion": "7.0.0",
"requiredMySqlVersion": "5.0"
},
"constants": {
"DB_NAME": "wordpress",
"DB_USER": "root",
"DB_PASSWORD": "password",
"DB_HOST": "127.0.0.1:2391",
"DB_CHARSET": "utf8",
"DB_COLLATE": "",
"AUTH_KEY": "de|{fkazXWX5$Kyy.,\")cAU[j<H(hX8iY3DYPgJaK&m+JNeoT,:4s.6|kmx\"/Jmk",
"SECURE_AUTH_KEY": "[M5h9P%db[L@l]+UgYV(lH_nw.\"*^I^16PR9#c.xnelgcWyL;6jwS(bT8D3!|t[z",
"LOGGED_IN_KEY": "k*t|Uk$!qbMi.2OZ0Y[vbGZg,^G:]Z@|.@|Z$*~s$p0z>[?5]VCLyJ~/Mj_<t,`p",
"NONCE_KEY": "PT(<MLN<rKf]F5uW_z^)z=IEM.\"I_fW&hGmM!I]:v,=nKRt1#(T=Yak2X}p1fWN{",
"AUTH_SALT": "B+Fp2bq9B{%f{7R&iD5n)t6.:z~#p9\")Y>ffPE`vyv*y3Dp1NY)K=%3-ab[@0;kO",
"SECURE_AUTH_SALT": "LgE!fbrD0|i;I;k.X:O^;LaCdd^ss^@mG/W?-F-%=LK[01-w}EUS<c[uw(7dR<l]",
"LOGGED_IN_SALT": "sVE8Qq#]SXE~&i-qgZ{7-KerffBv<O0p#$bv~W}=H1CCjkiR1tYnU1+,zvk8F,f^",
"NONCE_SALT": "bwb~CmESexui,|jX3&2s?*`g/\"MJrkHbQuu>;AXPBDvt/@zJ#s^..1+vt\"jBw*Fk",
"WP_DEBUG": false,
"WP_ALLOW_MULTISITE": true,
"MULTISITE": true,
"SUBDOMAIN_INSTALL": false,
"DOMAIN_CURRENT_SITE": "example.com",
"PATH_CURRENT_SITE": "/",
"SITE_ID_CURRENT_SITE": 1,
"BLOG_ID_CURRENT_SITE": 1,
"WP_DEBUG_LOG": true,
"WP_DEBUG_DISPLAY": false,
"DISABLE_CRON": true,
"WP_HTTP_BLOCK_EXTERNAL": "true",
"ABSPATH": "/Users/lucatume/oss/wp-browser/var/wordpress/"
},
"globals": {
"table_prefix": "wp_"
}
}
BlogArchiveCest: It shows the correct blog archive page | "/blog/","/blog/"
...
When running a suite that contains the WPLoader
module in --debug
mode, the WPLoader
module will output a WordPress status
listing of information about the WordPress installation; I do not see that in your output.
That leads me to believe the WPLoader
module is silently failing to load for some reason.
The fact the WPLoader
module is not loading correctly is confirmed by the fact the sanitize_title
function is undefined.
- Do you see something in the PHP error log?
- Can you share how you've set up the WordPress installation that produced the db fixture?
- What plugins did you use?
- What theme did you use?
I am using WP Migrate Pro by delicious brains to create a dump file for all the tables that I need in the test (and then I rename the tables of course so they match the db prefix in the test database). There seems to be a difference between v3 and v4 in that I needed to update my DB export to include a few extra tables that weren't needed before (wp_terms, wp_relationships, a couple of yoast tables). I spotted this problem before logging this issue with you - so I don't think it is relevant. That wordpress status debug stuff isn't being shown when I run codeecept, nothing is going to the normal wp-content.debug.log
file, and nothing is going into the regular apache2 error.log
file either - which sometimes happens if WP bombs early on.
Good idea to check the plugins. I had not actually added them to my suite config. I have been trying to get wpbrowser running without any plugins loading. However even when I added them, I am still not getting that WP status debug info you mention. So, I don't think it's a plugin clash.
The theme is a totally custom theme. But it worked OK with v3...
You say in the set-up instructions that the wpRootFolder
parameter used in the config for WPLoader (and also WPFileSystem) needs to point to the folder where wp-load.php
is. Well, I have done that - and when I misconfigure it on purpose, I get an error message from the WPFileSystem module telling me that it is not configured and it can't find the wp-load.php
file. So that's good.
However, wp-load.php
is not actually run until WPBrowser tries to load a web page. I can tell this by putting intentional syntax errors or error logging in the file. I would have thought that WPLoader would try and run that file when codecept starts up. But it doesn't. Does that give you any clues?
To reiterate, I created my wpbrowser set up by renaming my old tests
folder, and running vendor/bin/codecept init wpbrowser
. I then chose the custom configuration option because there is already a db.php
file in my project (from the query-monitor
plugin). I am also testing the entire site, and your docs indicate that site testing usually requires a custom config. So, the contents of the current tests
folder (and tests/.env
) are completely new and were generated by wpbrowser v4. I have been adding in real tests from my tests.old
folder one by one - until I hit this (I assume) WPLoader error.
I rolled back to my old version of codecept since I need to keep working on development and this seems to be taking quite a while to fix - although I definitely appreciate your help and responsiveness so far!
In the process I noticed that when using wpbrowser v3 with a dump file that includes a yoast table that I had to add for v4 (as above) is that it threw an error about that Yoast table already existing. I can see in the error that when Yoast is activated, it creates the tables/columns it needs - but they were already in my dump file. wpbrowser v4 was not loading or activating the yoast plugin (presumably because WPLoader was not working properly) and therefore, I didn't hit this Yoast activation error. Before I had added these table to my dump file I had been different receiving errors later in the piece when Yoast was not finding tables it needed. All this to say is that the change in dump requirements is just symptom of WPLoader not working.
Thanks for the additional feedback, the Yoast plugin hint adds something to look into.
I will post updates in this issue when I have news.
@charlesdeb I'm trying to reproduce and debug the issue; I cannot make it happen with Yoast SEO. You've already provided your configuration files, thank you for that, would you be able to provide the error you get when you try to run the tests? A PHP error log from my previous question?
I will get round to this in due course. I had to move onto some other work and have been using the old versions in the meantime, but we need to upgrade eventually...
I have got back to this again. I thought that I'd start entirely from the beginning as much as possible to see if it was something in my old config and set-up that was causing things to break for an unknown reason. However, it seems to have not made any difference that I can see. In short I have managed to get WpLoader working for loadOnly: false
, but when I switch it to loadOnly:true
, then I am getting errors that indicate that WpLoader
is not actually loading WordPress.
Here is my test:
<?php
namespace Tests\AcceptanceWpBrowser;
use Tests\Support\AcceptanceTester;
/**
* Ensure that basic config is correct
*/
class CanaryCest
{
public function _before(AcceptanceTester $I)
{
}
// tests
public function wpLoaderWorks(AcceptanceTester $I)
{
$sanitised = sanitize_title('the rain in spain');
$I->assertEquals($sanitised, 'the-rain-in-spain');
}
}
Here is an AcceptanceWpBrowser.suite.yml
file that works:
aactor: AcceptanceTester
# suite_namespace: Tests\Acceptance
modules:
enabled:
- lucatume\WPBrowser\Module\WPLoader:
# loadOnly: true
wpRootFolder: '%WORDPRESS_ROOT_DIR%'
dbUrl: '%WORDPRESS_DB_URL%'
wpDebug: true
tablePrefix: '%TEST_TABLE_PREFIX%'
domain: '%WORDPRESS_DOMAIN%'
adminEmail: 'admin@%WORDPRESS_DOMAIN%'
theme: 'tbnuk'
- Asserts
Note that loadOnly: true
is commented out.
Ultimately, I want to add WpDb
, WpBrowser
and some other modules to it, activate a theme and some plugins. This config is just stripped down to the bare bones so we can eliminate other things as potential causes.
This is the output of running the test:
$codecept run tests/AcceptanceWpBrowser/CanaryCest.php:wpLoaderWorks -d -f
[Core bootstrap] Installing...
[Core bootstrap] Running as single site... To run multisite, use -c tests/phpunit/multisite.xml
Activating plugins:
WordPress status: {
"rootDir": "/path/Clients/xxx/code/xxx/",
"version": {
"wpVersion": "6.4.1",
"wpDbVersion": "56657",
"tinymceVersion": "49110-20201110",
"requiredPhpVersion": "7.0.0",
"requiredMySqlVersion": "5.0"
},
"constants": {
"DB_NAME": "xxx-uk-wpe-dev",
"DB_USER": "xxx-development",
"DB_PASSWORD": "xxx",
"DB_HOST": "127.0.0.1",
"DB_CHARSET": "utf8mb4",
"DB_COLLATE": "",
"AUTH_KEY": "xxx",
"SECURE_AUTH_KEY": "xxx",
"LOGGED_IN_KEY": "xxx",
"NONCE_KEY": "xxx",
"AUTH_SALT": "xxx",
"SECURE_AUTH_SALT": "xxx",
"LOGGED_IN_SALT": "xxx",
"NONCE_SALT": "xxx",
"WP_DEBUG": true,
"WP_DEBUG_LOG": true,
"ABSPATH": "/path/Clients/xxx/code/xxx/"
},
"globals": {
"table_prefix": "xZ4_"
}
}
Rebuilding AcceptanceTester...
Tests.AcceptanceWpBrowser Tests (1) ----------------------------------------------------------------------------------------------------------------------------------------------------------
Modules: \lucatume\WPBrowser\Module\WPLoader, Asserts
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CanaryCest: Wp loader works
Signature: Tests\AcceptanceWpBrowser\CanaryCest:wpLoaderWorks
Test: tests/AcceptanceWpBrowser/CanaryCest.php:wpLoaderWorks
Scenario --
I assert equals "the-rain-in-spain","the-rain-in-spain"
PASSED
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Time: 00:01.895, Memory: 46.50 MB
OK (1 test, 1 assertion)
This all looks good and is working as expected - although the reported table_prefix
above is not coming from the test set-up. Rather, it is coming directly from wp-config.php
. That may not be relevant.
However, when I uncomment the loadOnly: true
line leaving the AcceptanceWpBrowser.suite.yml
file like this:
actor: AcceptanceTester
suite_namespace: Tests\Acceptance
modules:
enabled:
- lucatume\WPBrowser\Module\WPLoader:
loadOnly: true # this is the only difference to the previous run
wpRootFolder: '%WORDPRESS_ROOT_DIR%'
dbUrl: '%WORDPRESS_DB_URL%'
wpDebug: true
tablePrefix: '%TEST_TABLE_PREFIX%'
domain: '%WORDPRESS_DOMAIN%'
adminEmail: 'admin@%WORDPRESS_DOMAIN%'
title: 'Acceptance WpBrowser Tests'
- Asserts
and run things again, we get:
$codecept run tests/AcceptanceWpBrowser/CanaryCest.php:wpLoaderWorks -d -f
The WordPress installation will be loaded after all other modules have been initialized.
Rebuilding AcceptanceTester...
Tests.AcceptanceWpBrowser Tests (1) ----------------------------------------------------------------------------------------------------------------------------------------------------------
Modules: \lucatume\WPBrowser\Module\WPLoader, Asserts
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CanaryCest: Wp loader works
Signature: Tests\AcceptanceWpBrowser\CanaryCest:wpLoaderWorks
Test: tests/AcceptanceWpBrowser/CanaryCest.php:wpLoaderWorks
Scenario --
ERROR
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Time: 00:00.120, Memory: 10.00 MB
There was 1 error:
1) CanaryCest: Wp loader works
Test tests/AcceptanceWpBrowser/CanaryCest.php:wpLoaderWorks
[Error] Call to undefined function Tests\AcceptanceWpBrowser\sanitize_title()
#1 /path/Clients/xxx/code/xxx/tests/AcceptanceWpBrowser/CanaryCest.php:18
#2 Tests\AcceptanceWpBrowser\CanaryCest->wpLoaderWorks
#3 /path/Clients/xxx/code/xxx/vendor/symfony/console/Command/Command.php:291
#4 /path/Clients/xxx/code/xxx/vendor/bin/codecept:120
ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
It doesn't look like any of the modules are being initialised here since I am not seeing the Wp Constants that I saw before. I have also tried referring to the sanitize_title()
as \sanitize_title()
- and it simply complains:
[Error] Call to undefined function sanitize_title()
If you need any extra debugging, I'm happy to provide it.
Have the same problem when trying to load WP_Query:
[Error] Class "WP_Query" not found
@charlesdeb, thanks for coming back to this and taking the time to debug. In your most recent exploration, you've stripped too many modules:
Modules: \lucatume\WPBrowser\Module\WPLoader, Asserts
This means the WPLoader
module is being instructed not to handle the database state, but there is no WPDb
module to handle it.
To exclude a wp-browser issue, I would run a test with the suite configured to use the WPDb
and WPLoader
modules in loadOnly: true
mode.
In the WPDb
configuration file, start by loading an empty installation (no plugins activated, no theme activated, no content in the database) with the dump
file.
If that does not work, then there is likely an issue in wp-browser; else, start incrementally adding to the dump file, e.g., by first activating the target theme and trying again, then a plugin and trying again, and so on.
Since this has been an issue for you for some time, feel free to email me (see profile) to arrange a call and review this together.
This issue is marked stale because it has been open 20 days with no activity. Remove stale label or comment or this will be closed in 5 days.
I do intend to email about this. It's just a matter of priorities for me at the moment
Closing due to inactivity.