The WordPress Toolkit and Smart Updates shall register custom/premium assets like themes and plugins which aren't available on WordPress.org. Basically, if the Dashboard in the WordPress backend shows updates, the toolkit and Smart Updates should be able to recognize them and and include them into the update and test.

Implement the ability to disable the backups of Wordpress toolkit, or limit the amount of backups that a domain user can do within this extension.

For example, the customer has a WordPress set with the required plugins.

And this WordPress set is defined in ServicePlans > ServicePlanName > Additional Services > WordPress Toolkit

However, after creating the subscription example.com in Domains > example.com > WordPress > Plugins can be found that plugins like Hello Dolly or Akismet Anti-Spam are also installed however they were not pre-selected.

Please add the CLI method to prevent the installation of such unnecessary for customer plugins.

For example when we add the required theme into the WordPress set, after the installation the "Twenty Twenty" theme will be set as default.

Please add the possibility to define which theme will be set by default after the WordPress installation as via the CLI method as via Plesk GUI.

The CLI method is important here because some customers use only this method for a WordPress installation.

We'd like to auto-deploy some wordpress instances on our Plesk server. I've tested the Wordpress Toolkit, and it works great, but I have one problem : The Wordpress admin password isn't sent to the customer.

I know that we can read the password from the Plesk Interface, but I'd like our users to get their wordpress password without having them to log on into Plesk.

Please implement any solution to send the Wordpress password to the customer, e.g to get it trough the API call or to be able to sent the email notification directly from Plesk.

To implement the button Scan from user interface, through CLI so that the Plesk Admin (or root) can search newly installed Wordpress on the server.

When the miniOrange 2 Factor Authentication (MFA) plugin is enabled Wordpress Toolkit provides a failed login attempt error and sends a notification before letting to insert MFA. It would be better if when logging in to WP Dashboard from Plesk UI there will be no failed login attempts when any mfa is enabled

When "Disable wp-cron.php option" is enabled, it is possible to customize only task's execution time, or it will be re-created with the default settings (details: https://docs.plesk.com/en-US/obsidian/administrator-guide/73391/#setting-up-a-regular-run-of-wp-cron-php).

Add an option to customize other wp-cron.php task's properties (description, send notifications or not, etc).

The WordPress settings has an option for the WordPress URL and the Site URL to be different - i.e. the WordPress site files are in a sub-directory. But sites in this configuration do not work properly in the WordPress Toolkit.

Given this is a core feature of WordPress and one used by a lot of sites, I think support for it in the WordPress Toolkit should be a priority.
Details from WordPress about this option:
https://wordpress.org/support/article/giving-wordpress-its-own-directory/

When being logged in as a customer in Plesk, it is possible to see the Wordpress Administrator's credentials.
It is required to hide the administrator's password for security reasons and let the customers login to WP Dashboard anly via the additional user account, added via the WP Dashboard itself.

Scenario:
For example the specific time zone is set in Plesk > Tools & Settings > System Tine > You time zone (GMT+03:00) Europe/Sofia

However, after creating a new WordPress instance timezone will be set as UTC +0 in WordPress admin dashboard > Settings > General.

Request:
Add the ability in WordPress Toolkit use the same timezone which is set in Plesk > Tools & Settings > System Tine > You time zone or ability to set the default time zone for all newly created WordPress instances.

For now the database server assigned to the domain via service plan is used to host WordPress database. Would be nice to add ability to choose other database servers if exist as they might be more suitable for customer needs.

Please add option to delete a wordpress site via CLI. currently i can only detach.

Like the wp-cron feature released recently it would be useful to have other functionality like
- Warn if not using InnoDB
- Clear out and limit post revisions
- Disable revisions
- Cleanup autoload options
- Cleanup sessions
- Image crushing

Current version ov WP-CLI with the command plesk ext wp-toolkit --wp-cli is 1.4
the latest release is 2.4.1. please update that 3+ years old version!

thanks

Currently, WP Toolkit offers possibility to add a subdomain prefix for staging.

So, considering the main domain is "domain.tld", WP toolkit offers "staging.domain.tld" as an option.

We use a slightly different scheme, and it our setup our staging will looks like "domain.review" (note "review" instead of tld).

It will be nice to specify default staging tld (as it currently implemented for "staging" subdomain) and have possibility to use such scheme of the staging (instead of selecting the domain from the list manually)

Service plan, that deploys WordPress on another VPS
Or another mechanism, that will let you allocate not a separate space for the customer on the same server, but a separate VPS with a WordPress install with a 1 click.

Or at least give a header to click so to sort them up

For now, all the existing at "WordPress > Sets" sets are available for customers when they install WordPress.
The idea is to limit available sets in service plan, like available applications in "Applications" tab.

Add post-update hooks in WordPress Toolkit, which can be used to automate the process of committing to Git (e.g. WordPress core and plugin updates that are automatically installed by WordPress Toolkit).

Use case:

Be able to respond to the event and write a program to do things like: a) commit the changes to the local git repository and push them to origin, b) trigger an alert in the monitoring system