[NSFW] plesk ext wp-toolkit –clear-cache -instance-id 13 -format json

<strong style=”font-size: inherit;”>Plugin:<span style=”font-size: inherit;”> Woody Code Snippets (insert-php), version 2.7.6</span>

WordPress: 7.0.3
PHP: 8.3
Environment: Plesk Obsidian with WP Toolkit (which activates/deactivates plugins via WP-CLI)

Summary:
Activating the plugin through WP-CLI (<code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>wp plugin activate insert-php) triggers a fatal PHP error. Activating the same plugin through the WordPress admin dashboard works without any error. Because Plesk WP Toolkit uses WP-CLI to manage plugins during its scans and after updates, this fatal error corrupts the output WP Toolkit expects, causing its data collection to fail with “An error has occurred when decoding JSON: Syntax error”, and the site to be marked as Broken.

Error:

<code style="background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Fatal error: Uncaught Error: Call to a member function add_capabilities() on null
in .../wp-content/plugins/insert-php/includes/class.plugin.php:168
Stack trace:
#0 .../insert-php/insert_php.php(277): WINP_Plugin->activation_hook()
...

Root cause (from the code):
In <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>class.plugin.php, the <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>activation_hook() method calls:

<code class="language-php" style="background: transparent; font-family: var(--font-mono);"><span style="color: rgb(179, 74, 0);">$</span><span style="color: rgb(129, 0, 194);">this</span>->snippets_type-><span style="color: rgb(0, 81, 194);">add_capabilities</span><span style="color: rgb(43, 48, 59);">();</span>

At the moment the activation hook runs under WP-CLI, <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>$this->snippets_type is <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>null, so the call fails fatally. Under the dashboard activation flow, <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>snippets_type is apparently initialized in time; under WP-CLI it is not.

Steps to reproduce:

1. Have the plugin installed but deactivated.


2. Run <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>wp plugin activate insert-php (or let Plesk WP Toolkit activate it).


3. Observe the fatal error <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>add_capabilities() on null at class.plugin.php line 168.


4. By contrast, activating via wp-admin → Plugins → Activate works cleanly.

Impact:
Any environment that activates plugins via WP-CLI (Plesk WP Toolkit, automation, deployment scripts) hits this fatal error. In our case it made Plesk WP Toolkit unable to refresh the instance, producing daily errors and marking the site as Broken.

Suggested fix:
Ensure <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>$this->snippets_type is initialized before <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>activation_hook() runs, or add a null check / lazy initialization before calling <code class=”bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]”>add_capabilities(), so activation works consistently in both the dashboard and WP-CLI contexts.