search

lucatume / wp-browser

The easy and reliable way to test WordPress with Codeception. 10 years of proven success.
https://wpbrowser.wptestkit.dev/
MIT License
602 stars 88 forks source link

[BUG] Can't access WP built-in functions even when using WPLoader #669

Closed charlesdeb closed 5 months ago

charlesdeb commented 11 months ago

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.

lucatume commented 11 months ago

@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.

charlesdeb commented 11 months ago

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!

lucatume commented 10 months ago

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.

  1. Do you see something in the PHP error log?
  2. Can you share how you've set up the WordPress installation that produced the db fixture?
  3. What plugins did you use?
  4. What theme did you use?
charlesdeb commented 10 months ago

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.

charlesdeb commented 10 months ago

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.

lucatume commented 10 months ago

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.

lucatume commented 9 months ago

@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?

charlesdeb commented 9 months ago

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...

charlesdeb commented 8 months ago

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.

mwei0210 commented 8 months ago

Have the same problem when trying to load WP_Query:

[Error] Class "WP_Query" not found

lucatume commented 8 months ago

@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.

github-actions[bot] commented 7 months ago

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.

charlesdeb commented 7 months ago

I do intend to email about this. It's just a matter of priorities for me at the moment

lucatume commented 5 months ago

Closing due to inactivity.