web-dev-qa-db-fra.com

Utilisation de wp_filesystem dans Plugins pour stocker les paramètres de personnalisation

J'essaie de corriger mon plugin avec les réponses que j'ai eues ici: Utilisation de wp_filesystem dans Plugins Background J'ai écrit un thème ( https://github.com/bassjobsen/jamedo-bootstrap-start-theme ) et un plugin ( https://github.com/bassjobsen/wp-less-to-css ) maintenant je veux intégrer le plugin dans le thème. Le plugin a écrit un fichier CSS dans un dossier. Écrire des fichiers avec la fonction native PHP n'est pas sécurisé comme décrit ici: http://ottopress.com/2011/tutorial-using-the-wp_filesystem/ . La réponse précédente m'aide à résoudre ce problème pour le plugin.

La solution fournie par les relais @otto sur request_filesystem_credentials semble nécessiter une URL. Cette URL me donnera quelques soucis lors de l'intégration du plugin avec le thème.

Mon objectif est d'utiliser les paramètres du personnaliseur après l'enregistrement pour créer un nouveau fichier CSS.

Maintenant, j'ai dans functions.php:

add_action( 'customize_save_after', 'lesscustomize' );

function lesscustomize($setting)
{
//$setting is no used here
$updatecss = WP_LESS_to_CSS::$instance;
add_filter( 'add_extra_less_code', 'add_extra_less_now_live');

function add_extra_less_now_live($parser)
{
    return 'h1{color:'.get_theme_mod( 'heading_color').'}';          
}
$updatecss->wpless2csssavecss();
}

wpless2csssavecss() enregistre maintenant le fichier avec file_put_contents. Le file_put_contents devrait être remplacé par un $wp_filesystem->put_contents();. La cause $wp_filesystem sera utilisée de manière globale. Je pense qu’il devrait être possible d’obtenir les informations d’identification du système de fichiers dans ma fonction lesscustomize(). À côté, je ne sais pas comment faire cela sans une URL. Il y aura une URL mais elle est appelée par Ajax et n'est pas visible pour l'utilisateur.

L'idée d'utiliser 'personnaliser_save_after' est venue de https://stackoverflow.com/questions/14802251/hook-into-the-wordpress-theme-customizer-save-action/16679837

Ma première question sera-t-il possible d'obtenir des informations d'identification du système de fichiers dans mon lesscustomize()? Sinon, y aura-t-il une alternative pour accrocher l'action de sauvegarde des paramètres du personnaliseur et obtenir les informations d'identification du système de fichiers pour enregistrer mes paramètres?

updateDans cette mise à jour de la question, je vais réagir à la réponse utile de Mark Kaplun. Je pense que cela aidera à comprendre ma question initiale.

Ce que vous essayez de faire est faux si c'est pour un usage général et si> il n'est pas adapté aux besoins d'un client spécifique. Modifier dynamiquement le code de votre thème, et css est un code semblable à JS, est généralement une mauvaise idée, mais n'entraîne que des problèmes de maintenance.

Dans mon thème, j'utilise MOINS au lieu de CSS (bien que vous puissiez aussi écrire du CSS). Je pense que cela sera utile et répond aux besoins des utilisateurs du thème. En premier lieu, LESS maintient les choses en ordre et en second lieu, mon thème est construit avec le logiciel Bootstrap de Twitter. LESS sera le moyen le plus direct de modifier le code HTML/CSS basé sur Bootstrap. Je ne modifie pas mon code de thème, je veux seulement enregistrer mon CSS dans un fichier, où CSS sera compilé à partir de LESS. Stratégie de maintenance du code que j'ai décrit ici: http://bassjobsen.weblogs.fm/integrate-less-jbst-wordpress-theme/

Outre les raisons théoriques, il existe des attentes des utilisateurs relatives à la personnalisation du thème UX, qui ne nécessitent pas l'écriture de fichiers sur le serveur.

Je ne comprends pas ce que les fichiers d'écriture ont à faire avec UX. Les personnes utilisant mon thème choisissent un thème utilisant Bootstrap et donc MOINS. Je pense qu'ils devraient comprendre qu'il devrait y avoir des fichiers écrits quelque part. Je suis d'accord qu'une étape supplémentaire pour remplir vos informations d'identification donnera un mauvais UX.

Si vous avez vraiment besoin de sauvegarder des fichiers sur le serveur, le meilleur emplacement est> le répertoire/wp-content/uploads.

Oui, c'est ce que je fais maintenant. http://ottopress.com/2011/tutorial-using-the-wp_filesystem/ me dit que c'est une mauvaise idée. Depuis WP3.8, les tests de thème sur wordpress.org ne seront également pas validés: "AVERTISSEMENT: fichier_put_contents a été trouvé dans le fichier wp-less-to-css.php. Opérations sur les fichiers possibles."

La meilleure façon de le faire est d’avoir un minimum de fichiers LESS qui ne concernent que les options contrôlées par l’utilisateur. une fois que les options ont été modifiées, vous compilez le LESS, vous stockez le CSS généré dans une option et vous l'exportez dans le cadre de chaque page HTML, comme le font la plupart des thèmes avec leurs options personnalisables.

Je suis d'accord que cela pourrait être une option. L'écriture de CSS en ligne n'est pas toujours la meilleure solution, voir aussi: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery . Tous les paramètres de personnalisation ne doivent pas nécessairement être critiques ou faire partie du code CSS au-dessus du pli. De plus, dans certains cas, certains paramètres recompileront également les CSS de Bootstrap (par exemple, en modifiant le point de rupture de la grille @ grid), je ne peux pas insérer ce code en ligne.

2
Bass Jobsen

update

L'option de session décrite ci-dessous semble très précaire! Une enquête plus approfondie indique que le tableau renvoyé par request_filesystem_credentials contient vos informations d'identification en texte brut. Donc, stocker cela dans une session semble une mauvaise idée.

Remarque: l'envoi des informations d'identification via une connexion non sécurisée (http) lors de la publication du formulaire semble également une mauvaise idée. Les dernières peuvent être résolues en ajoutant vos informations d'identification à wp_config.php. Ce faisant, assurez-vous de vérifier 600 votre fichier wp_config.php (voir: http://codex.wordpress.org/Changing_File_Permissions ).

Définir les informations d'identification dans wp-config.php par exemple:

define('FS_METHOD', 'ftpext');
define('FTP_Host', 'localhost');
define('FTP_USER', 'ftpuser');
define('FTP_PASS', 'ftpuser');
define('FTP_BASE', '/home/username/http_docs/');

Cela fait, nous pouvons les enregistrer (temporairement) dans la base de données pour les utiliser par le personnalisateur. Cela semble économiser, car les paramètres de wp-config.php sont également enregistrés dans la base de données. L'enregistrement dans la base de données se fera avec set_theme_mod inspiré par: https://stackoverflow.com/questions/14802251/hook-into-the-wordpress-theme-customizer-save-action/16679837

Après avoir fait tout cela, le code final qui me permet de stocker le paramètre de personnalisation dans un fichier en utilisant wp_filesystem:

function lesscustomize($setting)
{
$updatecss = WP_LESS_to_CSS::$instance;
$updatecss->wpless2csssavecss(unserialize(get_theme_mod('customizercredits')));
}

add_action( 'customize_save_after', 'lesscustomize' );

function storecedits( $wp_customize ) {

            $in = true;
            $url = 'customize.php';
            if (false === ($creds = request_filesystem_credentials($url, '', false, false,null) ) ) {
                $in = false;
                exit;
            }

            if ($in && ! WP_Filesystem($creds) ) {
                // our credentials were no good, ask the user for them again
                request_filesystem_credentials($url, '', true, false,null);
                $in = false;
                exit;
            }

            set_theme_mod('customizercredits', serialize($creds));

}
add_action('customize_controls_init', 'storecedits', 1);  

----------------- fin de mise à jour ----------------------

J'ai trouvé que je peux résoudre le problème théorique en utilisant des sessions. Malheureusement, cela introduit de nouvelles questions sur la sécurité. D'abord permettra d'activer les sessions (trouvé ici https://stackoverflow.com/a/4769449/1596547 ) causer d'autres problèmes? et si non quels sont les risques de stocker mes identifiants de fichier dans une session?

function kana_init_session()
{
  session_start();
}

add_action('init', 'kana_init_session', 1);

function updatefiles( $wp_customize ) {
WP_Filesystem($_SESSION['creds']);

            global $wp_filesystem;
            $contentdir = trailingslashit( $wp_filesystem->wp_content_dir() ); 
            echo $contentdir;
            $wp_filesystem->mkdir( $contentdir. 'cbe' );
            if ( ! $wp_filesystem->put_contents(  $contentdir . 'cbe/test.txt', 'Test file contents', FS_CHMOD_FILE) ) 
            {
                echo "error saving file!";
            }



}

add_action('customize_save', 'updatefiles', 1);

function storecredentials( $wp_customize ) 
{

            $in = true;
            $url = 'customize.php';
            if (false === ($creds = request_filesystem_credentials($url, '', false, false,null) ) ) {
                $in = false;
                exit;
            }
            if ($in && ! WP_Filesystem($creds) ) {
                // our credentials were no good, ask the user for them again
                request_filesystem_credentials($url, '', true, false,null);
                $in = false;
                exit;
            }
            $_SESSION['creds'] = $creds;

}
add_action('customize_controls_init', 'storecredentials', 1);</strike>
1
Bass Jobsen

Ce que vous essayez de faire est faux si c'est pour un usage général et s'il n'est pas adapté aux besoins d'un client spécifique. Modifier dynamiquement le code de votre thème, et css est un code semblable à JS, est généralement une mauvaise idée qui n'apporte que des problèmes de maintenance - validez-vous toutes les valeurs pour pouvoir les compiler? Comment allez-vous gérer les mises à niveau? Comment allez-vous gérer les installations réseau lorsque les utilisateurs ne connaissent pas les informations d'identification FTP?

Outre les raisons théoriques, il existe des attentes des utilisateurs relatives à la personnalisation du thème UX, qui ne nécessitent pas l'écriture de fichiers sur le serveur.

Si vous avez vraiment besoin de sauvegarder des fichiers sur le serveur, le répertoire/wp-content/uploads convient parfaitement.

La meilleure façon de le faire est d’avoir un minimum de fichiers LESS qui ne concernent que les options contrôlées par l’utilisateur. une fois que les options ont été modifiées, vous compilez le LESS, vous stockez le CSS généré dans une option et vous l'exportez dans le cadre de chaque page HTML, comme le font la plupart des thèmes avec leurs options personnalisables.

1
Mark Kaplun