• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved What to do if WP Toolkit does not re-scan a "broken" instance

Bitpalast

Plesk addicted!
Plesk Guru
Onyx 17.5, CentOS 7.3, latest WP Toolkit

On the first scan a WP installation was detected, but WP Toolkit says:
"PHP Parse error: syntax error, unexpected '?' in /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1047) : eval()'d code on line 1"

The only thing that I found to be abnormal was a byte order instruction at the beginning of wp-config.php like this:
Code:
<U+FEFF><?php
/** The base configuration for WordPress
...
Same issue as described here: Wordpress installation is not synced: PHP Parse error: syntax error, unexpected '?' in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(996) : eval()'d code on line 1

I have removed the byte order character(s), then clicked "Scan" in WP Toolkit again. But it is not changing anything about the status of the broken instance. I tried turning PSA debugging on, hit scan again, and it revealed that the error was actually not logged again. Nothing was logged again. It is behaving as if the scan is neglecting the instance completely, but the "broken" instance stays in the WP Toolkit overview list.

How can WP Toolkit be forced to re-read an instance or to check whether the initially found error is still present?

Edit: I found that moving the document root directory to a new name and then scanning again is a possible workaround. The broken instance still is no deleted from the table, but at least the fixed instance is now listed.
 
Last edited:
Hi Peter Debik,

pls. try to de-link the corresponding wordpress - instance with issues/errors/problems and link it again afterwards. Your described issues should be resolved now ( if the misconfigurations at the "wp-config.php" have been corrected ).

To delete a broken wordpress instance, you should consider as well to de-link it over the Plesk Control Panel and another scan afterwards, should be able to find it again.

Another option to synchronize the scanned, linked wordpress - instance is to use the "update" - button at your setting - page of the choosen wordpress instance.


Pls. consider as well to add a feature suggestion to improve the scan / link / de-link option with the option to repair a linked wordpress instance with a clean/new wordpress - configuration file from the installation source, where only the previous login - credentials should be copied from the old wordpress - configuration file. :)
 
The problem is that I cannot delink it, because Plesk does not show the regular panel where the Wordpress installation can be contrlled. It is not possible to "update" either, because the selector box is read-only.

It's probably a bug or indeed a missing feature, something like "reset" is missing. The broken instances remain in the panel even if neither database nor files/directories exist. Scanning again does not remove them either.
 
Hello @Peter Debik,

I tried to reproduce your issue but i couldn't do it.

What i've done?
1 I Installed WordPress manually, setup it and add <U+FEFF> to the wp-config.php
2 Pressed scan
Scan executed with warning:
Scanning for WordPress installations was performed with errors:
Subscription "<hostname>": Failed to parse wp-config.php: syntax error, unexpected '<' on line 1

So instance was broken.

4 I removed <U+FEFF> at wp-config.php and i went to detail page of the broken instance and pressed "Refresh".
Instance was fixed, all data was syncronized.

Also i think that @UFHH01 talked about "Detach" feature. This button is presented at the detail page of broken instance (this button designed to hide broken instances mostly).
 
It is not that easy unfortunately. The <U+FEFF> is not a character sequence that you can enter into the file by using an editor. It is an "invisible" byte order code that some editors add as the first character. The <U+FEFF> is indeed a single character only in the first byte slot of a file. It was probably brought in by our customer when he edited the wp-config.php file by downloading it, using an editor in MS Windows and uploading the saved result to his web space again.

I attach a file (with invalidated password data) where you can see what I mean. It has the <U+FEFF> character in the first position. So far so good, it is the issue described in Wordpress installation is not synced: PHP Parse error: syntax error, unexpected '?' in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(996) : eval()'d code on line 1 , not really a problem once you know that this issue exists.

To see the byte order character, upload the file to any Linux machine, then
# less <filename>
In a normal editor the byte is hidden and cannot be removed by any command.

For the UFHH01 hint: It is not possible to open the detail page of these broken installations, because there is no detail page for it. The checkbox before the installations is read-only, and clicking on the links only leads to either the file manager or the control panel.

So at this point for example (second screenshot) there are three broken WP instances in the customer account that cannot be removed.
 

Attachments

  • wp-config_byteordercode_example.txt
    3.1 KB · Views: 13
  • screenshot_wp.jpg
    screenshot_wp.jpg
    21.1 KB · Views: 15
@Peter Debik, you've attached screenshot where a number of links are shown. These links (/httpdocs, /httpdocs2) leads to a detail pages of instances (It is not a "file manager" links). When the instance is broken (it is when we can't get an info about wordpress instance) we don't have a siteurl or name. So the path inside subscription is the only unique data about WordPress instance what we've got. Please, check it.

The "invisibility" of <U+FEFF> doesn't matter for us. You can put something to the first row of wp-config.php and wp-cli call will fall because of that. So the instance will be broken in toolkit. The reason of the falling wp-cli call does n't matter for toolkit: the consequences are always the same
 
OK, got it. Thank you!

I did not realize that the second hyperlink (the one pointing to the /httpdocs2, /httpdocs3 and so on) is different from the first. I would like to suggest to add a button or link to directly "detach" broken instances in this list. I remember another forum thread where another user did not see that possibility either, so probably there is more people who don't realize how to do this in case of broken instances.
 
@Peter Debik, this is the one of solutions. We also can add button "Refresh" and remove unnecessary (in this case) link to detail page. Seems like a good decision and we could add it to one of the our next releases. Thank you for idea!
 
Back
Top