vp restore-site error from freshly cloned repo

[tatemz]

Copied from issue #1046 inadvertently posted on plugin repo.

The Error:

Fatal error: Call to a member function resolve() on null in /var/www/html/content/plugins/versionpress/src/Cli/vp-internal.php on line 52

Some Notes:

• I am trying to restore a site using the 2nd scenario suggested method here
• I am using WP inside the subdirectory wp
• I am using a modified version of the official wordpress Docker container (with added mysql-client, wp-cli, and some install fixes to aid in the wp subdirectory)

Running a failed restore, then activating the plugin, then re-running the restore ended up giving me the proper results.

If the vp restore-site command is supposed to initialize the WordPress database, then it should be able to work without the plugin activated.

My issue above was solved (hackily) only because I ran these commands in this order:

1. wp vp restore-site (with necessary --require option) - This command failed with the aforementioned error
2. wp plugin activate versionpress (this only worked because the previous command did a half-installation)
3. wp vp restore-site (with necessary --require option) - This command is identical to the first, but succeeded this time.

I am using this Docker container based on the official WordPress image. See the Dockerfile for how I have customized it to run versionpress commands from inside the container.

[borekb]

Hi, thanks for the report. The restore-site command should certainly work on the first try, which version of VersionPress are you using? Is this the latest 3.0?

[tatemz]

This error was on the latest official 3.0 release. Additionally, the problem persists on the latest 3.0-beta release.

[borekb]

3.0-beta is older than 3.0 so you've encountered it on the latest release. @pavelevap, have you ever observed this behavior?

[pavelevap]

I will try to reproduce it, but I would like to know some details from @tatemz:

• Path in error message /var/www/html/content/plugins/versionpress/src/Cli/vp-internal.php suggests that wp-content is renamed to content and there is no mention of wp subdirectory in the path?
• How do you handle wp subdirectory? Where is your .git repo located? Inside wp subdiretory or in parent folder with index.php? Do you use VP_PROJECT_ROOT constant (see docs)?

Thank you!

I am having the same issue so maybe I can help answer your questions.

I was using the official 3.0 release of VersonPress.

The wp-content folder in my case is located in the default location and the site worked fine before running the clone command.

I used Vagrant with VVV and used VV to create the initial site. I then imported my database and files into the location of the site. I used wp-cli's search-replace command to change the domain. At this point the site works fine and I installed and activated VersionPress fine. The site still works fine.

Then I ran the vp clone command with the output shown below.

wp vp clone --name=dev --dbname=my.site.dev --dbuser=wp --siteurl=my.site.live/dev
Success: Site files cloned
Success: Clone added as a remote
Success: Enabled pushing to the original repository
Success: Enabled pushing to the clone
Success: wp-config.php updated
Success: Copied VersionPress
Success: Database tables created
PHP Fatal error:  Uncaught Error: Call to a member function resolve() on null in /srv/www/my.site.live/dev/wp-content/plugins/versionpress/src/Cli/vp-internal.php:52
Stack trace:
#0 [internal function]: VersionPress\Cli\VPInternalCommand->finishInitClone(Array, Array)
#1 /srv/www/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(67): call_user_func(Array, Array, Array)
#2 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#3 /srv/www/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(363): call_user_func(Object(Closure), Array, Array)
#4 /srv/www/wp-cli/php/WP_CLI/Runner.php(323): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#5 /srv/www/wp-cli/php/WP_CLI/Runner.php(330): WP_CLI\Runner->run_command(Array, Array)
#6 /srv/www/wp-cli/php/WP_CLI/Runner.php(808): WP_CLI\Runner->_run_command()
#7 /srv/www/wp-cli/php/wp-cli.php(21): WP_CLI\Runner->start()
#8 /srv/www/wp-cli/php/boot-fs.php(17): include('/srv/www/wp-cli...')
#9 {main}
  thrown in /srv/www/my.site.live/dev/wp-content/plugins/versionpress/src/Cli/vp-internal.php on line 52
Fatal error: Uncaught Error: Call to a member function resolve() on null in /srv/www/my.site.live/dev/wp-content/plugins/versionpress/src/Cli/vp-internal.php:52
Stack trace:
#0 [internal function]: VersionPress\Cli\VPInternalCommand->finishInitClone(Array, Array)
#1 /srv/www/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(67): call_user_func(Array, Array, Array)
#2 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#3 /srv/www/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(363): call_user_func(Object(Closure), Array, Array)
#4 /srv/www/wp-cli/php/WP_CLI/Runner.php(323): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#5 /srv/www/wp-cli/php/WP_CLI/Runner.php(330): WP_CLI\Runner->run_command(Array, Array)
#6 /srv/www/wp-cli/php/WP_CLI/Runner.php(808): WP_CLI\Runner->_run_command()
#7 /srv/www/wp-cli/php/wp-cli.php(21): WP_CLI\Runner->start()
#8 /srv/www/wp-cli/php/boot-fs.php(17): include('/srv/www/wp-cli...')
#9 {main}
  thrown in /srv/www/my.site.live/dev/wp-content/plugins/versionpress/src/Cli/vp-internal.php on line 52

Error: Could not finish site restore

The site no longer works at this point and I'm not seeing any errors, though I haven't had a chance to investigate this all that much yet.

The .git repo is inside the WP root folder which is at /srv/www/my.site.live/htdocs/

I did not use VP_PROJECT_ROOT but I will try that and see if there is any difference.

There are 23 unsupported plugins in this case but it doesn't copy those tables so I'm not sure if this is the issue but I suspect not as the line it references is related to VersionPressServices::DATABASE being null for some reason.

I also tried without setting the database with the exact same result.

It does actually successfully put the database tables into the database from what I can see.

I did notice that it doesn't create the dev site in the subfolder but the sibling server and doesn't update the wp-config to point to the new database when I indicated the database the first time.

Ideally I would rather be able to simply have another site at /srv/www/my.site.dev/htdocs/ which I could clone to but that doesn't seem to work with the way the vp clone command works. I think if I want to move everything I would have to modify the git config remote location and if not then I have to move my /srv/www/my.site.live/dev to /srv/www/my.site.live/htdocs/dev and update the /srv/www/my.site.live/htdocs/.gitignore to add /dev to it or VersionPress recognizes it as a new uncommited change. If I don't move it into the htdocs folder I probably have to modify nginx to recognize the dev folder as a separate site and set the --siteurl param for the vp clone command to be the new URL of that site. I'm not sure which of those scenarios are the ideal scenario or which one is the expected scenario from VP.

Once I get the dev site working I am intending to import a new database and files and try to merge them together with VP since there were some changes to posts and things in the database which I want to see if it can merge but I'm not sure how well this is going to work and I can't even seem to get that far.

VersionPress is some really promising and awesome looking software though! Thank you for working on it!!!

(updated to fix some stuff)

I'd like to add something I noticed which may be the cause of the issue. At one point after running the initial clone command wp vp clone --name=dev --dbname=my.site.dev --dbuser=wp --siteurl=my.site.live/dev (probably where it says wp-config.php updated) the live site's wp-config.php file is overwritten with the one intended for the newly cloned dev site. The dev site's database, prefix and VP_ENVIRONMENT are now in this file. The wp-config.php located in the newly created dev site contains the values for the live site still at the point where the error is.

If I switch them around the live site now works again but the dev site not so much.

I tried to place the dev folder inside the htdocs folder and update the .git/config remote and add /dev to .gitignore and run wp vp restore-site --siteurl='my.site.live/dev' --require=wp-content/plugins/versionpress/src/Cli/vp.php but this results in the following errors/warnings:

wp vp restore-site --siteurl='my.site.live/dev' --require=wp-content/plugins/versionpress/src/Cli/vp.php
Success: PHP 5.6+
Success: 'mbstring' extension
Success: Execute external commands
Success: Git 1.9+ installed
Success: Write access on the filesystem
Warning: Access rules can be installed
  VersionPress automatically tries to secure certain locations, like `wp-content/vpdb`. You either don't have a supported web server or rules cannot be enforced. [Learn more](http://docs.versionpress.net/en/getting-started/installation-uninstallation#supported-web-servers).

There are some warnings. Continue? [y/n] y
It looks like the site is OK. Do you really want to run the 'restore-site' command? [y/n] y
Success: Database tables created
Success: VersionPress tables created
Success: Git merge driver added
PHP Warning:  syntax error, unexpected '"' in Unknown on line 9
 in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/Serialization/IniSerializer.php on line 165
Warning: syntax error, unexpected '"' in Unknown on line 9
 in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/Serialization/IniSerializer.php on line 165
PHP Warning:  Invalid argument supplied for foreach() in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/Serialization/IniSerializer.php on line 399
Warning: Invalid argument supplied for foreach() in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/Serialization/IniSerializer.php on line 399
PHP Warning:  array_combine(): Both parameters should have an equal number of elements in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/DirectoryStorage.php on line 184
Warning: array_combine(): Both parameters should have an equal number of elements in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Storages/DirectoryStorage.php on line 184
PHP Warning:  Invalid argument supplied for foreach() in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Synchronizers/OptionsSynchronizer.php on line 70
Warning: Invalid argument supplied for foreach() in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Synchronizers/OptionsSynchronizer.php on line 70
WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ON DUPLICATE KEY UPDATE option_value = VALUES(option_value), autoload = VALUES(a' at line 1 for query INSERT INTO wp_dev_options (option_name, option_value, autoload) VALUES  ON DUPLICATE KEY UPDATE option_value = VALUES(option_value), autoload = VALUES(autoload); made by include('/srv/www/wp-cli/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, VersionPress\Cli\VPInternalCommand->finishInitClone, VersionPress\Synchronizers\SynchronizationProcess->synchronizeAll, VersionPress\Synchronizers\SynchronizationProcess->runSynchronizationTasks, VersionPress\Synchronizers\OptionsSynchronizer->synchronize, VersionPress\Database\Database->query
PHP Warning:  array_column() expects parameter 1 to be array, boolean given in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Utils/ArrayUtils.php on line 130
Warning: array_column() expects parameter 1 to be array, boolean given in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Utils/ArrayUtils.php on line 130
PHP Warning:  join(): Invalid arguments passed in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Synchronizers/OptionsSynchronizer.php on line 101
Warning: join(): Invalid arguments passed in /srv/www/my.site.live/htdocs/dev/wp-content/plugins/versionpress/src/Synchronizers/OptionsSynchronizer.php on line 101
Success: Database synchronized

I'm not sure if that step is even necessary but I ignore this error and import the dev site db and files careful not to delete the VersionPress files (dev/.git* and dev/wp-content/plugins/versionpress and dev/wp-content/vpdb) and change the dev/wp-config.php database prefix to just wp_ again since that's what my db uses. The dev site now works as I want it. Now time to figure out how to merge it back to the live site if even possible.

[tatemz]

@borekb & @pavelevap - Maybe it'd be best if I spin up a sample repo that you can clone and get started with a docker-compose up command. Check back by EOD for an update.

UPDATE: More like "end of week"... lol

Here is a starter repo that contains my workflow.

[tatemz]

@pavelevap - To answer your specific questions:

• I have set VP_PROJECT_ROOT to the root of my project
• I have set WP_CONTENT_DIR to ./content respectively (not literally, but by using php dirname)
• The installation of Versionpress added the proper config for WP_CONTENT_URL to 'http://' . $_SERVER['HTTP_HOST'] . '/content'
• My project is setup near-identically to wp-skeleton
• My wp-cli.yml config is setting path to the subdirectory ./wp (see wp-skeleton link)
• The site is installed with the custom subdirectory ./wp

[tatemz]

@borekb & @pavelevap

If you follow the link to the starter repo I posted in my update, you should be able to:

1. Install a fresh wordpress site & activate versionpress
2. Change a theme to test if versionpress commits it
3. Destroy & recreate the docker containers & restore the site with versionpress

This should give you the error this ticket is based on.

[borekb]

@tatemz Just as a quick update, we currently think this is related to some misconfiguration related to the customized project structure. What are the exact steps to reproduce the issue, from cloning your Docker repo to seeing the error?

BTW thanks for your awesome reporting, it's the first time we're getting a Docker container to reproduce an issue :) It's really great of you!

[tatemz]

@borekb - Well, the steps are in the repo README, but I can try to detail out more here if you need more steps.

[borekb]

@tatemz: @JanVoracek tried to reproduce it today, there were some permission issues but he'll be able to provide more details.

[tatemz]

@borekb & @JanVoracek - Awesome - I have noticed some quirks with the git submodule, but I think that is just an issue with my git config!

There is now a test-data branch inside that repo that you can use to test a restore without installing wordpress.

After a clone and a submodule init, you should be able to start the containers and run the vp restore-site command.

git clone git@github.com:tatemz/versionpress-skeleton.git ./wordpress --recursive
cd ./wordpress
git checkout test-data
docker-compose up -d
docker-compose run --rm mywp wp vp restore-site --siteurl="localhost:8080/wp" --require="content/plugins/versionpress/src/Cli/vp.php" --yes

[JanVoracek]

@tatemz: Great! I will try it. As @borekb said, I have a permission isssue on Mac – files and directories created from PHP on the mounted volume are not writable.

[JanVoracek]

I finally reproduced the error and found the cause. We didn't test WP as a submodule yet and unfortunately VersionPress doesn't support it.

VersionPress needs to modify the wp-includes/wp-db.php file in order to track all DB changes. When you use WP as a submodule, it's not replaced after checkout. There are also another related problems. It should be possible to use WP as a submodule after versionpress/versionpress#657.