Updates of Themes and Plugins via WP-Toolkit / WP CLI

[Cryptoom]

I have integrated the plugin updater and it works fine when I go to the admin panel and click on "Updates", then the updates are displayed immediately.

If I try to trigger the whole thing via WP-Toolkit CLi or search for updates via Plesk, nothing is displayed.

I have integrated it into the theme as an example.

// Updater Class
require get_stylesheet_directory() . '/plugin-update-checker/plugin-update-checker.php';
$themeDirectory = get_stylesheet_directory(); // Or get_stylesheet_directory() for child themes
use YahnisElsts\PluginUpdateChecker\v5\PucFactory;

// Theme updater
$mylandingpageUpdater = PucFactory::buildUpdateChecker(
    'https://api.mydemoupdater.ai/updater/landingpageai-theme.json',
    $themeDirectory, // Use the path to the root of the theme
    'landingpageai-child'
);

I have already tried an update script via PHP which I trigger via CLI.

<?php
// request-update.php

// Authentication
require_once(dirname(__FILE__) . '/sync_key-521A1-245-4.php'); // Loads the file that defines the key
if (!defined('SYNC_KEY') || !isset($_GET['key']) || $_GET['key'] !== SYNC_KEY) {
    http_response_code(403);
    the('Access denied');
}

// Determine the path to wp-load.php
$wp_load_path = dirname(__FILE__, 5) . '/wp-load.php';
if (!file_exists($wp_load_path)) {
    http_response_code(500);
    the('wp-load.php not found');
}

require($wp_load_path);


// Perform updates
function perform_updates() {
    wp_update_themes();
    wp_update_plugins();
    wp_version_check(array(), true);
    wp_maybe_auto_update();
}

wp_clean_update_cache();

// Perform updates
perform_updates();
?>

[YahnisElsts]

I'm not familiar with how WP-Toolkit works internally, and I'm not sure if it's even compatible with PUC in principle. However, a couple of general ideas to consider:

• Is the theme active? This is particularly important in Multisite where, if I remember correctly, only the theme that's active on the main site will be loaded when handling updates.
• Will the code that initializes the update checker run when WordPress is loaded from a CLI script? For example, if it's inside a conditionally included file, make sure that those conditions are actually satisfied when that happens.

[Cryptoom]

First of all, a big thank you for your brilliant work and support and the quick response!

• I am using your script in a single install, not a multisite. Yes the theme is active and the code is in it.
• The script code is directly in the functions.php but I have also customized it in plugins.

[YahnisElsts]

Since you already have a script you can run via CLI, maybe you could modify it to get more information about the state of the update checker? For example, depending on how your code is set up, you could either access $mylandingpageUpdater in the script or define some unique constant in the script and then check if that constant is defined in the code that sets up $mylandingpageUpdater, then use $mylandingpageUpdater there.

One thing to check is if the update checker can load the cached update from the database. Call $mylandingpageUpdater->getUpdate() to get the cached update. If there's no update, it will return null. If you can see an update in "Dashboard -> Updates", this method should return the same update.

If that correctly returns the update, the second thing I would check is if PUC is adding it to the list of updates maintained by WP core. Get the list of all theme updates via get_site_transient('update_themes') and see if it contains your update.

[Cryptoom]

Thank you very much for your answer. Unfortunately I have to admit that I didn't really understand any of it (my mistake!).

I have used the updater as described, created a json with the information for the update, uploaded the json and this is also accessible.

If I go to /wp-admin/update-core.php in the backend, the update is displayed immediately, but not if I check via cli theme update or via external updater management tool.

I have only included this code in the theme in the functions.php (and yes its a child theme), is there anything else missing?
The URL is changed because shouldnt be public :)

// Updater Class
require get_stylesheet_directory() . '/plugin-update-checker/plugin-update-checker.php';
$themeDirectory = get_stylesheet_directory(); // Or get_stylesheet_directory() for child themes
use YahnisElsts\PluginUpdateChecker\v5\PucFactory;

// Theme updater
$mylandingpageUpdater = PucFactory::buildUpdateChecker(
    'https://api.mydemoupdater.ai/updater/landingpageai-theme.json',
    $themeDirectory, // Use the path to the root of the theme
    'landingpageai-child'
);

Here the Content of the json:

{
    "name": "myLandingpageAi Child",
    "version": "2.4.4.7",
    "details_url": "https://api.mydemoupdater.ai/",
    "download_url": "https://api.mydemoupdater.ai/updater/themes/landingpageai-child.zip",
    "homepage": "https://mylandingpage.ai/",
    "author": "api.mydemoupdater.ai",
    "author_homepage": "https://api.mydemoupdater.ai",
    "requires": "6.3",
    "tested": "8.5",
    "requires_php": "8.0",
    "last_updated": "2024-07-24 15:10:10",
    "upgrade_notice": "Dieses große Update ist ein weiterführendes Update. Damit werden die ersten Funktionen integriert.",
    "sections": {
        "description": "mylandingpage.ai revolutioniert die Art und Weise, wie du Landingpages erstellst. Mit unserem visuellen Editor-System, unterstützt durch sputzenperformance in der Ladezeit, ermöglichen wir es dir, innerhalb weniger Minuten beeindruckende Landingpages für Verkauf, Workshops und Newsletter zu kreieren – ganz ohne Programmierkenntnisse.",
        "installation": "Installatieren und das war es.",
        "changelog": "Changelog. <p>Erste Updatephase</p>"
    },
    "icons" : {
        "1x" : "https://api.mydemoupdater.ai/updater/themes/landingpageai-child-assets/assets/icon-128x128.png",
        "2x" : "https://api.mydemoupdater.ai/updater/themes/landingpageai-child-assets/assets/icon-256x256.png"
    },

    "banners": {
        "low": "https://api.mydemoupdater.ai/updater/themes/landingpageai-child-assets/assets/banner_low.jpg",
        "high": "https://api.mydemoupdater.ai/updater/themes/landingpageai-child-assets/assets/banner_high.jpg"
    }
 }

[YahnisElsts]

I don't think there's anything else you would need to do, but, as I said, I'm not familiar with how WP-Toolkit works internally. Maybe compatibility with that tool in particular does require something more.

You posted an update script earlier, so I was just saying you could add some debug output to the script to see the state of the update checker. For example:

var_dump($mylandingpageUpdater->getUpdate());
var_dump(get_site_transient('update_themes'));

I don't know if the $mylandingpageUpdater variable the theme creates is accessible in the scope of this script, hence the comments about constants and so on.

[CornyC-lab]

Sorry, but I have the same problem, only with a plugin. Plesk WP-Toolkit does nothing other than call up the WP CLI. If I call the WP CLI manually, it also says "Plugin already updated".

In the backend it is no problem that the update is displayed and carried out correctly.

[YahnisElsts]

I'm afraid I don't have anything new to add. Just to make sure that PUC still actually works WP-CLI, I tested it with WP-CLI 2.11.0 (currently the latest stable release):

PS C:\xampp\htdocs\[redacted]> wp plugin list --status=active --name=external-update-example
+-------------------------+--------+-----------+---------+----------------+-------------+
| name                    | status | update    | version | update_version | auto_update |
+-------------------------+--------+-----------+---------+----------------+-------------+
| external-update-example | active | available | 1.1     | 2.0            | off         |
+-------------------------+--------+-----------+---------+----------------+-------------+

In this case, external-update-example is a basic example plugin that uses PUC to check for updates. WP-CLI correctly shows that an update is available, and the update_version matches the update shown in the WP dashboard.

[CornyC-lab]

Thanks for your feedback, the latest Plesk version of the WPToolkit is currently running WP-CLI 2.9.0

plesk ext wp-toolkit --wp-cli -instance-id XX -- plugin list --status=active --name=external-update-example

name    status  update  version
external-update-example active  none    0.1

In my test, it only recognises the new version in the WP Dashboard. I will try the configuration on another server.

OK, I have checked it with another server. There the test plugin works via WP-CLI:

wp plugin list --status=active --name=external-update-example
+-------------------------+--------+-----------+---------+----------------+-------------+
| name                    | status | update    | version | update_version | auto_update |
+-------------------------+--------+-----------+---------+----------------+-------------+
| external-update-example | active | available | 0.1.0   | 1.0            | off         |
+-------------------------+--------+-----------+---------+----------------+-------------+

Could it be due to the WP-CLI version?

[marcorocca]

Hello, I have a very similar problem related to the update via WP-CLI that does not see the updates immediately.

I think the cause is to be found in the transient that is checked at the update, if you perform these steps the updates are seen without problems:

wp option delete external_updates-my-plugin
wp cron event run puc_cron_check_updates-my-plugin
wp plugin update my-plugin

I thought it was solved by the fix implemented regarding the issue #558, but probably the status, list and update commands do not force the update, as it is done instead by the Dashboard > Updates section of WordPress: it can be useful that update, status and list commands of WP CLI can bypass the transient and force the update check to give back an updated situation.

[R2116]

I have another similar issue with WP-CLI: I can see the available updates in the WordPress dashboard, and I can see it via WP-CLI with wp plugin list. But my (managing) host uses wp plugin list --skip-plugins to check for updates and update them nightly with auto-rollback function, to not load the plugins just for an update check.
I'm not too deep into WP CLI - did #558 have the intention to provide updates even if plugins not loaded? Is it doable from a PUC-perspective to provide the update, even if the plugin is not loaded in that moment (via providing the update info earlier to transient / option)?

Let me know if I can provide some info/ logging! Or open a new issue if that's more appropriate

[YahnisElsts]

I'm not too deep into WP CLI - did #558 have the intention to provide updates even if plugins not loaded? Is it doable from a PUC-perspective to provide the update, even if the plugin is not loaded in that moment (via providing the update info earlier to transient / option)?

No, the changes discussed in #558 only work when plugins are loaded. In the current implementation, it's not possible to insert a custom update when the code that runs PUC isn't loaded. As a design choice, PUC doesn't modify the underlying WP transient; it relies on filters to add the update on the fly. This helps avoid potential issues like stale updates, but it only works while the plugin or theme that creates the PUC instance is active/loaded.

In principle, you could rewrite PUC to make it directly update the update_plugins transient instead. However, I'm not currently planning to do that.