WP Toolkit - General Discussion

[custer]

@Peter Debik,

We have released WPT 3.6.3 a couple of hours ago, it includes the fixes for your cloning issue and maintenance mode issue. Let us know if you find anything else!

 

[Bobbbb]

Hello,

Please don't add "WP_AUTO_UPDATE_CORE', false" to wp-config.php in Wordpress installations.

If a customer has configured their Wordpress installation to update using Wordpress's built-in mechanism, that should NOT be disabled. I see no reason why the Wordpress built-in update has to be disabled in order for Wordpress Toolkit to be also be used. If there is a reason, please explain.

 

[custer]

Hi everyone,

We have released WPT v4.0.0, which introduces a Beta version of Remote Management functionality. Read the release notes below, try it out let us know what you think!

• [+] Beta version of Remote Management functionality is now available. Go to the Servers tab and add any Linux-based remote server with WordPress sites to manage them from a single place. This functionality will stay free for a limited time during the Beta stage. A notification will be shown in advance regarding the switch from the free Beta stage to the Release stage that will require a separate license. Your feedback and input regarding this feature would be highly appreciated.
• [+] Smart Update procedure became more transparent, displaying specific steps and their progress. Now at least you'll know which steps are taking so long!
• [+] Database server info was added to the Database tab of the WordPress site card.
• (*)Various links created by WordPress Toolkit on Websites & Domains screen are now directing users to the new UI.
• (*)Users can see the physical path of WordPress sites when cloning them or copying data from one site to another.
• (*)WordPress Toolkit is now much better prepared both physically and mentally for handling users who try to clone their WordPress site to a destination where another WordPress site already exists.
• [-] Removing a subdomain in Plesk will not remove WordPress installation anymore if this subdomain's docroot was pointing to another domain with WordPress installed. This also covers the use of wildcard subdomains. (EXTWPTOOLK-2580)
• [-] WordPress Toolkit now properly notifies users why Smart Update could not be performed in certain cases. (EXTWPTOOLK-2573)
• [-] The description of Turn off pingbacks security measure now explains what will happen if pingbacks are turned off (spoiler: they stop working). (EXTWPTOOLK-2563)
• [-] The em dash punctuation mark is now correctly displayed in plugin and theme names. (EXTWPTOOLK-1990)

 

[trialotto]

Hi everyone,

We have released WPT v4.0.0, which introduces a Beta version of Remote Management functionality. Read the release notes below, try it out let us know what you think!
......

• [-] The description of Turn off pingbacks security measure now explains what will happen if pingbacks are turned off (spoiler: they stop working). (EXTWPTOOLK-2563)

.......

@custer,

Ok, I wanted to complement you with the new release....... but first I had to laugh outloud as result of your "spoiler".

Anyway, the Servers (beta) tab proves to be very handy and valuabe and reliable, even in managing older WPT versions on remote servers.

By the way, it should be stated that it would be convenient that the remote server updates the database after applying a remote WPT update - at this moment, this is not the case and that can be somewhat confusing (read: the job is done on the remote server, but there is no indication in the WPT of the remote server).

A small patch to this excellent release? Yes please!

Kind regards..........

 

[quasel]

Is it only my 2 Servers or is clone/copy data broken with 4.0 it doesn't update/change any URL's anymore… it's just a 1:1 DB clone…

 

[Phil Clayton]

Hello,

I'm wondering if it's possible to expand upon building our own "custom set" install. Presently I have all the plugins and themes installed on custom install set but is it possible to go beyond plugins and themes?

Eg a full working site install?

Screenshot

Something upon the lines of once a custom set is selected as in the screenshot above an upload file field pops up to install the custom db and then another upload zip file field for the complete website?

Effectively an automated way of copying a complete site from A to B without uploading a zip into file manager, extracting, matching db and changing url links.

What do others think? Is there a better-automated way? Better suggestions?

Many thanks

 

[zanuda]

Is it only my 2 Servers or is clone/copy data broken with 4.0 it doesn't update/change any URL's anymore… it's just a 1:1 DB clone…

Hello, I'm unable to reproduce such behaviour when URLs are not changed after the Clone operation.
Could you please describe your issue in more details?
Are you using different databases for source and destination instances? Or both WP instances are using one database?
URLs were not changed in some part of database (wp_posts table for example) or any URL wasn't changed, even in wp_options table?
We need an example of URL exactly as it is stored in your WP database.
Please also let me know the complete scenario (example: clone WP instance to a new subdomain of the same subscription)
Which version of Plesk do you use?
You may send all this information in private message.

 

[custer]

Hi everyone!

We have released WordPress Toolkit v4.1. It includes the fix for the site health check issue introduced with the release of WP 5.2. Read the full release notes here: WordPress Toolkit - Plesk Extensions

 

[grumbi84]

Hello,

am I the only one who gets this message since the last update?

First I got it only for one domain. After deactivating this domain I start getting it for other domains, too.
wp-config.php is clean, we run updates every month, several anti-virus and online scanner show nothing suspicious, everything clean.
Google shows clean SERPs.

Interesting thing is, that the installations are not getting quarantined. Some look quarantined in Wordpress Toolkit, but are accessible through the web.

I don't even know where to follow up on this issue.

--

The following WordPress installations are quarantined:

Website "xxx" (https://xxx.tld): WP-CLI command has not finished working in 60 seconds, so it was terminated. Usually this means that there are problems with WordPress installation itself, for example it could be infected with malware. Check the wp-config.php file of the installation for potential malware code.

 

[Pieter van Kampen]

@grumbi84 I am getting the same message about the WP-CLI command has not finished, using WPT 4.1 when trying to clone a domain. The site is not quarantined.
I have no idea how to fix this

 

[grumbi84]

@grumbi84 I am getting the same message about the WP-CLI command has not finished, using WPT 4.1 when trying to clone a domain. The site is not quarantined.
I have no idea how to fix this

Today I hadn't got the message. What I did yesterday:
- Fixed debian update issue and update the debian packages
- Implemented serverwide solution from here: Website shows 500 internal server error on Plesk: mod_fcgid: read data timeout

Try it out.

 

[custer]

Hey guys,

We're aware of the wp-cli timeout issues and we're planning to release a fix soon. Stay tuned!

 

[custer]

We have released a small WPT 4.1.1 update which should fix the wp-cli timeout issues. Let me know if the problem still persists. Thanks!

 

[Prod Juan]

Feature modification request (currently running extension version 4.1.1-2009)
(If this is the wrong place to submit mod requests, please advise so I can post accordingly. Thanks!)

In the "Plugins" tab (shown between Installations and Themes tabs), any plugin with an update available presents the following indication (for example):
--
[ ] Akismet Anti-Spam
( ! ) A new version is available. [Update to version #.#.# (link)] [View Details]
--
For plugins, the View Details link points to a URL off the wordpress.org site that ends with /changelog/.
That URL resolves to the "Details" tab of the plugin page, not the Development Tab.
My request is to modify the URL of the View Details link to end in /developers/ since that's where the change log details actually live on each plugin page.
In this case, the new link would be Akismet Anti-Spam
I suggest that the more useful information pertaining to a plugin with an update is what was changed within that update.
Thank you for considering this request.

 

[custer]

Hi @Prod Juan,

This makes total sense. We are planning to redesign both Plugins and Themes tabs later this year, so I'll be sure to include this change as well. Let me know if you're interested in getting a sneak peak at the new design, I'd appreciate your feedback.

 

[Prod Juan]

Yes, I'm interested in the sneak peak you offered. Thank you for the prospective implementation estimate.

Hi @Prod Juan,

This makes total sense. We are planning to redesign both Plugins and Themes tabs later this year, so I'll be sure to include this change as well. Let me know if you're interested in getting a sneak peak at the new design, I'd appreciate your feedback.

 

[Prod Juan]

Issue report (running version 4.1.1-2009 of the Plesk Extension)

The error message appears with the text "The task with ID 3235 was not found." within the updates slide-out panel.

Steps to reproduce this behavior:

1. click the "Updates" button in the buttons strip above the installations between "Scan" and "Security" buttons.
2. the updates slide-out panel will emerge from the left side of the page and proceed to report any available updates.
3. after the search process concludes (the check updates button stops animating), a message appears in a pink background box, just below the heading "Available Updates For WordPress Website", containing the message "The task with ID 3235 was not found.". (This message is consistent and always shows the same number.)

My question: Is this something that can be addressed in a minor update without waiting for the next major release of the toolkit extension?

 

[IgorG]

"The task with ID 3235 was not found."

As workaround try to use following steps:

1. Create backup of the WordPress extension SQLite database:
   # cp -a /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3{,.bak}
   
   
2. Log into SQLite database:
   # sqlite3 /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3
   
   
3. Resolve inconsistency by running the query like below:
   sqlite> delete from InstanceProperties where name like '3235';

I hope it will help.

 

[custer]

Hi everyone, we have released WordPress Toolkit 4.2. You can see the full list of changes here: WordPress Toolkit - Plesk Extensions

Let us know if you have any questions!

 

[Prod Juan]

I suspect someone with content revision privileges to the wordpress.org site has updated the plugin detail page template (since I posted the report earlier) to include this bit of code:

<script type="text/javascript">if ( '#changelog' == window.location.hash ) { window.location.hash = '#developers'; }</script>

The result of this is: after following the link and the page loads, now I can just reload the page one time and the developer tab contents are presented because this script modifies the URL to simulate the nav pad being chosen.
While I applaud the effort, I would suggest that this block be wrapped in a deferred logic structure ( e.g., window.onload() ) so it runs after the page is loaded (or moved lower in the page code stream).
This code snippet is located ABOVE the elements which it references, thus negating its affect until page reload.

Please advise whether this feedback is better suited on the wordpress.org support forum rather than here. Thanks!

Hi @Prod Juan,

This makes total sense. We are planning to redesign both Plugins and Themes tabs later this year, so I'll be sure to include this change as well. Let me know if you're interested in getting a sneak peak at the new design, I'd appreciate your feedback.