J'aimerais savoir s'il existe un moyen de se connecter au processus de mise à jour de WordPress et d'envoyer la variable $_POST
au serveur de mise à jour?
Je fournis des mises à jour de plugins/thèmes depuis un serveur privé et je m'accroche à ceci:
add_filter('pre_set_site_transient_update_themes', 'check_for_update');
qui fonctionne très bien. Une version plus récente de theme/plugin apparaît sous Tableau de bord> Mises à jour et je peux effectuer la mise à jour. Mais le problème est le suivant: je veux que les utilisateurs ne puissent télécharger/mettre à jour que s'ils ont fourni un nom d'utilisateur/mot de passe correct (d'abord via add_option()
). Idéalement, le lien direct ne devrait jamais fonctionner à moins que le client n'envoie $_POST
avec login/mot de passe à update.php (les fichiers sur le serveur de mise à jour qui enverront plugin.Zip en retour).
Je cherche quelque chose comme ça:
add_filter('updating', 'my_func');
function my_func($request){
$request['login'] = get_option('login');
$request['pass'] = get_option('pass');
return $request;
}
Et WordPress, lors de la mise à jour du thème/plugin, devrait envoyer $_POST['login']
et $_POST['pass']
à http://example.com/update.php et update.php ne devrait permettre le téléchargement/la mise à jour que si la connexion correspond à celle définie ici ( php est le fichier sur le serveur de mise à jour qui envoie le paquet Zip avec le plugin le plus récent à WordPress).
J'espère que c'est clair :)
Une version légèrement modifiée de ma réponse à cette question , mais aussi comme un plugin qui montre comment il pourrait fonctionne.
Remarque: Le code n'est pas testé - je ne connais pas la configuration de votre serveur, etc. - et vient d'écrire de ma tête. Vous devrez le tester, trouver la bonne position pour la fusion des arguments et définir votre URL, etc.
Le test initial (n ° 1) pourrait être amélioré si le référentiel distant personnalisé renvoie des en-têtes utilisables (ce qui n'est pas souvent le cas). Donc, si c'est le cas, vous feriez mieux d'utiliser wp_remote_head()
car cela rend la requête HTTP plus légère.
<?php
defined( 'ABSPATH' ) OR exit;
/**
* Plugin Name: (#78267) Custom Theme Update Args
* Description: Adds custom arguments to the HTTP request for a theme or plugin update from a custom location.
* Version: 2013-04-02.2139
* Author: Franz Josef Kaiser <[email protected]>
* Author URI: http://unserkaiser.com
* License: The MIT License (MIT)
* LicenseURI: http://www.opensource.org/licenses/mit-license.php
*/
add_filter( 'http_request_args', 'custom_upgrade_process', 9, 2 );
/**
* Callback for a HTTP request used to switch the
* SSL verification in case of a WP error response
* and routing to a custom Theme or Plugin repository.
* @param array $r Request arguments
* @param string $url Request URL
* @return array $r
*/
function custom_upgrade_process( $r, $url )
{
// Alter the following settings according to your
// update procedure and admin pages that deliver it.
# A) The admin URL
$custom_repo = 'https://example.com?foo=bar';
if (
0 !== strpos( $url, 'http://api.wordpress.org/plugins/update-check' )
XOR 0 !== strpos( $url, 'http://api.wordpress.org/themes/update-check' )
)
return $r;
# 1) Do an initial test to check if things are working as expected
$response = wp_remote_get(
$custom_repo,
array(
'timeout' => 120,
'httpversion' => '1.1',
)
);
# 2) Turn off SSL verification in case the HTTP request didn't work out
if (
is_wp_error( $response )
AND strstr( $response->get_error_message(), 'SSL: certificate subject name' )
)
add_filter( 'https_ssl_verify', '__return_false' );
# 3) Add your custom request arguments
$r = array_merge( $r, array(
'login' => get_option( 'login' ),
'pass' => get_option( 'pass' ),
) );
return $r;
}
Bonne chance. :)