WordPressin oma plugin-päivitysjärjestelmä toimii erinomaisesti WordPress.org-repositorion kanssa, mutta monissa projekteissa tarvitaan oma ratkaisu. Tämä on yleistä esimerkiksi premium-plugineissa, asiakasprojekteissa, suljetuissa yritysjärjestelmissä ja SaaS-tuotteissa, joissa pluginia ei haluta julkaista julkisesti.
WordPress tarkistaa säännöllisesti pluginien versionumerot ja vertailee niitä päivityspalvelimelta saatavaan dataan....
Pluginin päätiedostossa versionumero määritellään headerissa:...
Yksinkertaisin ratkaisu on JSON-endpoint....
Hookataan transient:...
WordPress odottaa ZIP-pakettia, jossa pluginin kansiorakenne on oikein....
Useimmat kaupalliset pluginet käyttävät lisenssiavaimia....
ZIP-paketin lataus kannattaa suojata....
Kevyt vaihtoehto on käyttää GitHub Releasesia....
Voit sallia automaattiset päivitykset:...
Korkeamman turvallisuuden järjestelmissä plugin-paketit voidaan allekirjoittaa....
Päivitys-API:a ei pidä kutsua jokaisella sivulatauksella....
Tyypillisiä ongelmia:...
Suurissa ympäristöissä käytetään usein:...
Hyvä päivitysjärjestelmä tukee rollbackia....
Oman päivitysjärjestelmän rakentaminen WordPress-pluginille perustuu WordPressin sisäisen update API:n hyödyntämiseen. Kun plugin tarkistaa version ulkoiselta palvelimelta ja tarjoaa ZIP-paketin oikeassa muodossa, WordPress käsittelee sen samalla...
Oman päivitysjärjestelmän idea on yksinkertainen: WordPress tarkistaa ulkoiselta palvelimelta, onko pluginista saatavilla uusi versio, ja näyttää päivityksen samalla tavalla kuin virallisille plugineille.
Miten WordPressin plugin-päivitykset toimivat
WordPress tarkistaa säännöllisesti pluginien versionumerot ja vertailee niitä päivityspalvelimelta saatavaan dataan.
Päivitysjärjestelmä perustuu:
- pluginin versionumeroon
- update transientiin
- remote API -vastaukseen
- package download URL:iin
Keskeinen hook:
site_transient_update_plugins
Tämän avulla voidaan injektoida oma päivitysinformaatio WordPressiin.
Pluginin version määrittely
Pluginin päätiedostossa versionumero määritellään headerissa:
/*
Plugin Name: My Plugin
Version: 1.0.0
*/
Versionumeroa verrataan myöhemmin päivityspalvelimen dataan.
Päivityspalvelimen rakenne
Yksinkertaisin ratkaisu on JSON-endpoint.
Esimerkki:
{
"version": "1.1.0",
"download_url": "https://example.com/plugin.zip",
"requires": "6.5",
"tested": "6.8"
}
Tämä voidaan hostata:
- omalla API-palvelimella
- WordPressissä
- Laravel-backendissä
- GitHub Releasesissä
- CDN:ssä
Päivityksen tarkistus WordPressissä
Hookataan transient:
add_filter('site_transient_update_plugins', 'my_plugin_check_update');
Esimerkki:
function my_plugin_check_update($transient) {
if (empty($transient->checked)) {
return $transient;
}
$response = wp_remote_get('https://example.com/update.json');
if (is_wp_error($response)) {
return $transient;
}
$data = json_decode(wp_remote_retrieve_body($response));
$plugin_slug = plugin_basename(__FILE__);
if (version_compare('1.0.0', $data->version, '<')) {
$transient->response[$plugin_slug] = (object)[
'slug' => 'my-plugin',
'plugin' => $plugin_slug,
'new_version' => $data->version,
'package' => $data->download_url,
'tested' => $data->tested,
'requires' => $data->requires,
];
}
return $transient;
}
Tämän jälkeen WordPress näyttää päivityksen normaalisti adminissa.
Pluginin ZIP-paketointi
WordPress odottaa ZIP-pakettia, jossa pluginin kansiorakenne on oikein.
Oikea rakenne:
my-plugin/
my-plugin.php
includes/
assets/
Väärä rakenne aiheuttaa asennusvirheitä.
Premium-pluginien lisenssijärjestelmä
Useimmat kaupalliset pluginet käyttävät lisenssiavaimia.
Tyypillinen logiikka:
- käyttäjä syöttää lisenssin
- plugin lähettää avaimen API:lle
- API validoi lisenssin
- päivitys sallitaan vain aktiivisille lisensseille
Esimerkki:
$response = wp_remote_post('https://example.com/license-check', [
'body' => [
'license' => $license_key,
'domain' => home_url()
]
]);
Turvallinen latauslinkki
ZIP-paketin lataus kannattaa suojata.
Vaihtoehtoja:
- signed URLs
- token-pohjainen autentikointi
- expiring URLs
- API-auth
Älä koskaan jätä premium-pluginin ZIP-linkkiä täysin julkiseksi.
GitHub-pohjainen päivitysjärjestelmä
Kevyt vaihtoehto on käyttää GitHub Releasesia.
Tällöin:
- release toimii versionhallintana
- ZIP generoidaan automaattisesti
- update.json voidaan rakentaa GitHub API:n päälle
Monet kehittäjät käyttävät tätä pienemmissä projekteissa.
Automaattiset päivitykset
Voit sallia automaattiset päivitykset:
add_filter('auto_update_plugin', '__return_true');
Tai rajata ne omaan pluginisi:
add_filter('auto_update_plugin', function($update, $item) {
if ($item->slug === 'my-plugin') {
return true;
}
return $update;
}, 10, 2);
Digitaaliset allekirjoitukset
Korkeamman turvallisuuden järjestelmissä plugin-paketit voidaan allekirjoittaa.
Hyödyt:
- estää supply chain -hyökkäykset
- varmistaa paketin aitous
- estää manipuloinnin
Tämä on yleistä enterprise-ratkaisuissa.
API caching
Päivitys-API:a ei pidä kutsua jokaisella sivulatauksella.
Käytä transient-cachea:
set_transient('my_plugin_update_data', $data, 12 * HOUR_IN_SECONDS);
Tämä vähentää API-kuormaa merkittävästi.
Yleisimmät virheet
Tyypillisiä ongelmia:
- väärä ZIP-rakenne
- version_compare-logiikka virheellinen
- transient-cache puuttuu
- package URL vanhenee liian nopeasti
- API timeoutit
- plugin slug ei täsmää
Enterprise-tason ratkaisut
Suurissa ympäristöissä käytetään usein:
- oma update API
- CDN-jakelua
- signed packages
- rollback-versioita
- vaiheistettuja päivityksiä
- telemetryä
Näin voidaan hallita tuhansia asiakasasennuksia turvallisesti.
Rollback-järjestelmä
Hyvä päivitysjärjestelmä tukee rollbackia.
Esimerkiksi:
- säilytä vanhat ZIP-versiot
- mahdollista downgrade
- tallenna changelogit
Tämä helpottaa ongelmatilanteita huomattavasti.
Yhteenveto
Oman päivitysjärjestelmän rakentaminen WordPress-pluginille perustuu WordPressin sisäisen update API:n hyödyntämiseen. Kun plugin tarkistaa version ulkoiselta palvelimelta ja tarjoaa ZIP-paketin oikeassa muodossa, WordPress käsittelee sen samalla tavalla kuin viralliset päivitykset.
Laadukas ratkaisu sisältää lisäksi lisenssien hallinnan, turvallisen paketoinnin, cachingin ja rollback-mahdollisuudet. Näin voidaan rakentaa ammattimainen premium-plugin-ekosysteemi ilman riippuvuutta WordPress.org-repositoriosta.