Apex Digital Toolbox

2.6.1

• Premium theme updates are now visible from the command line as well. wp theme list, wp theme update and wp theme status now wake the same premium updaters that wp plugin list already does. Jupiter X only loads its theme updater inside wp-admin, so until now wp theme list reported it as up to date while wp-admin showed an update, and wp theme update jupiterx on a copy answered “already updated”. The must-use plugin that does the waking is rewritten automatically on this update; every other WP-CLI command is left exactly as it was

2.6.0

• Outbound firewall: a development or staging copy can now deactivate an Essential Addons (WPDeveloper) licence, which is the step that has to happen before a licence key can be entered on the copy. Until now the deactivate was blocked, the copy kept showing the live site’s licence as active, and there was no way to enter a key. Only a deactivate that names the copy’s own web address is allowed: the firewall checks the address in the request against the copy’s own, so a copy can release its own registration but never the live site’s. Deactivating a copy that had been activated frees that seat
• Outbound firewall: rules can now require that part of a request names the copy’s own web address, which is what makes the deactivate above safe to allow. It is checked by the firewall itself, not taken on trust from the plugin making the request
• Outbound firewall: rules for Jupiter X (Artbees). A copy can now see and install updates for the theme and for its companion plugin, and browse the recommended plugins list. Registering or revoking the Jupiter X API key stays blocked on every Artbees address, because the key is tied to a single web address and registering a copy would move it away from the live site
• Outbound firewall: a rule for RealHomes (Inspiry Themes). A copy can now see and install updates for the theme and for Easy Real Estate, the RealHomes Elementor Addon and Real Estate CRM. Nothing on that address can register or release anything
• Outbound firewall: allowing a licence activation or deactivation on a copy is deliberate and the cost is yours to weigh – it uses or frees one of the licence’s seats. Any shipped rule can be removed on a site with the apex_toolbox_http_default_rules filter

2.5.0

• Packages: a private plugin that is already installed from somewhere else – an old manual upload, a GitHub download or the vendor’s own zip – can now be taken over from the Packages screen. Until now the screen offered Install, WordPress refused because the plugin’s folder already existed, and the only way through was to delete the working plugin first, which meant downtime on a live site
• Take over installs the registry’s build over the existing copy. The new package is downloaded and checked against the registry’s fingerprint before anything is changed. An active plugin stays active throughout, and if it cannot be switched back on afterwards the screen says so. From then on the plugin updates from the registry like any other package
• A confirmation screen comes first. It shows the installed plugin’s name and version, the version that will replace it, and that the files will be overwritten in place, so any changes made to them on the site are lost. A copy only has to be in the right folder to be offered, so the screen warns prominently when the installed plugin has a different name, and it says when the copy currently gets its updates from somewhere else
• A copy newer than the registry’s version is never taken over, because that would be a downgrade. The same version is allowed: that is the usual case, swapping in the registry’s build of what the site already runs
• A package whose zip would unpack into a different folder is refused before anything is touched, instead of being installed beside the old copy as a second plugin

2.4.0

• Premium plugin updates are now visible from the command line. Crocoblock’s Jet plugins, Essential Addons Pro and other plugins that use EDD Software Licensing only check for updates inside wp-admin or WP-Cron, so wp plugin list reported them as up to date when wp-admin showed an update. A small must-use plugin, installed and removed by the Toolbox, now lets them check when wp plugin list, wp plugin update or wp plugin status runs. Other WP-CLI commands are left exactly as they were. To turn it off on a site, add define(‘APEX_TOOLBOX_WAKE_UPDATERS’, false) to wp-config.php
• New wp apex updates list command: every installed plugin and theme – must-use plugins and drop-ins included, as wp plugin list shows them – with the update each one’s updater offers, as JSON. It always reports at least everything wp plugin list does, because it runs the same update check. It also says whether WordPress has any update information for each package (checked), so a plugin nobody checked no longer looks the same as one that is up to date. If one vendor’s update check fails, that package is reported as unchecked with a warning, and the rest of the list still comes back
• New wp apex changelog get <plugin> command: a plugin’s changelog as HTML. It uses Crocoblock’s published changelog for Jet plugins, then plugin information from wordpress.org or the vendor, then the plugin’s own readme.txt
• Outbound firewall: development and staging copies may now read Crocoblock’s published changelog files, and nothing else on crocoblock.com

2.3.2

• WP Defender: the option that skips audit logging during an import now actually recognises one. It only matched a request whose action was “process” or “processing”, which missed nearly every real import – WP All Import’s scheduled runs use “trigger” and “pipe” as well, and some carry no action at all – so the option could be switched on and change nothing at all. On one site importing every half hour this had let the audit log reach 86 million rows and 22 GB, 97% of the whole database, almost all of it one row per imported image
• A request is now treated as an import whatever action it carries, so long as it is genuinely one. A WP All Import cron request must carry that site’s real cron key, checked the same way WP All Import checks it before running the import, and the admin import screen counts only for someone allowed to run imports. Matching on the parameter alone would have let anyone append it to any request and go unlogged, which is not a trade worth making for an audit log
• A site whose importer endpoint carries neither the cron key nor the WP All Import page – a theme with its own import trigger, say – can declare a request an import through the new apex_toolbox_is_import_request filter, instead of needing a change to this plugin
• The option stays off by default and is still turned on per site from the Hooks page. Its name and description now describe the symptom it cures, an audit log grown to gigabytes, so it can be found by someone looking at a bloated database rather than only by someone who already knows it exists
• Ordinary site activity is still audited. Only requests identified as an import are skipped, and WP Defender already ignores its own audit listeners under WP-Cron and WP-CLI

2.3.1

• Outbound firewall: a development or staging copy can now log in to the WPMU DEV Dashboard, and so install and update WPMU DEV plugins. Connecting is what was blocked before – the Dashboard clears its stored key when it cannot reach WPMU DEV, so a copy would log itself out. Connecting a copy adds it to your Hub as its own site, because the address it registers is the copy’s own and the live site’s Hub entry is left alone. Unlike the other plugins that allow this, the Dashboard also re-connects twice a day on its own rather than only when someone presses a button. If your membership has a limited number of sites, remove this rule with the apex_toolbox_http_default_rules filter
• A development or staging copy now tells the WPMU DEV Hub its own address rather than the live site’s, so connecting a copy adds that copy to the Hub and the live site’s entry is never written to. This matters because a copy reports the live address when WordPress is used from the command line on a common local setup, and the Hub identifies sites by that address. It does nothing on the live site, or where the site already sets WPMUDEV_HUB_SITE_URL itself
• Disconnecting a site from the Hub stays blocked, as do granting and removing WPMU DEV support access and turning the Hub’s analytics on or off
• The plugin changelog and the translation list the current Dashboard needs are allowed too, so its screens stop reporting connection errors. Downloads – plugins, themes and translation files – still have no rule and are only reachable while WordPress is actually installing them