Utiliser Composer avec WordPress

WordPress est en train d'être modernisé. L'inclusion récente de Gutenberg basé sur JavaScript dans le noyau a ajouté des capacités modernes pour les sites de construction sur le front-end, et le bosse prochaine de la version minimale de PHP du 5.2.4 au 5.6 en avril 2019 et 7.0 en décembre 2019, mettra à disposition une multitude de nouvelles fonctionnalités pour construire des sites puissants.

Dans mon précédent article sur Smashing, dans lequel j’identifiais les fonctionnalités PHP nouvellement disponibles pour WordPress je soutenais que Le temps est venu de faire des composants l'unité de base pour la création de fonctionnalités dans WordPress. D'un côté, Gutenberg fait déjà du bloc (qui est un composant de haut niveau) l'unité de base pour construire la page Web sur le front-end; de l'autre côté, en augmentant la version minimale requise de PHP, le moteur WordPress a accès à l'ensemble des fonctionnalités de programmation orientée objet de PHP (telles que les classes et les objets, les interfaces, les traits et les espaces de noms), qui font toutes partie de les outils pour penser / coder dans les composants.

Alors, pourquoi les composants? En quoi sont-ils si intéressants? Un «composant» n’est pas une implémentation (comme un composant React), mais un concept: c’est le fait d’encapsuler des propriétés dans des objets et de regrouper des objets dans un package qui résout un problème spécifique. Les composants peuvent être implémentés à la fois pour le frontend (comme ceux codés via des bibliothèques JavaScript telles que React ou Vue ou les bibliothèques de composants CSS comme Bootstrap) et le backend.

Nous pouvons utiliser les composants déjà créés et les personnaliser pour nos projets, nous allons donc augmenter notre productivité en évitant de réinventer la roue à chaque fois et en raison de leur volonté de résoudre un problème spécifique et d'être naturellement découplés de l'application, ils peuvent être testés et corrigés très facilement ce qui rend l’application plus facile à maintenir à long terme.

Le concept de composants pouvant être utilisé pour différentes utilisations, nous devons donc nous assurer que nous parlons du même cas d’utilisation. Dans un article précédent, j'ai décrit comment créer un site Web ; le but était de transformer la page Web en une série de composants, en s’enroulant les uns à partir des autres jusqu’aux composants les plus élémentaires (pour rendre la mise en page). Dans ce cas, le cas d'utilisation du composant concerne le rendu – similaire à un composant React mais codé dans le backend. Dans cet article, toutefois, le cas d'utilisation des composants est l'importation et la gestion des fonctionnalités dans l'application.

Introduction à Composer And Packagist

Pour importer et gérer des composants propres et des composants tiers dans nos projets PHP, nous pouvons nous fier au gestionnaire de dépendance à PHP. Compositeur qui récupère par défaut les paquets du référentiel de paquets PHP Packagist (où un paquet est essentiellement un répertoire contenant du code PHP). Grâce à leur simplicité d'utilisation et à leurs fonctionnalités exceptionnelles, Composer + Packagist sont devenus des outils essentiels pour établir les bases des applications basées sur PHP.

Composer permet de déclarer les bibliothèques dont dépend le projet et de les gérer (les installer / les mettre à jour). Cela fonctionne de manière récursive : les bibliothèques dépendantes de dépendances seront importées dans le projet et gérées aussi. Composer dispose d'un mécanisme pour résoudre les conflits: si deux bibliothèques différentes dépendent d'une version différente d'une même bibliothèque, Composer essaiera de trouver une version compatible avec les deux exigences ou émettra une erreur si cela n'est pas possible.

Pour utiliser Composer , le projet nécessite simplement un fichier composer.json dans son dossier racine. Ce fichier définit les dépendances du projet (chacun pour une contrainte de version spécifique basée sur versioning sémantique ) et peut également contenir d'autres métadonnées. Par exemple, le fichier composer.json suivant oblige un projet à nesbot / carbon une bibliothèque fournissant une extension pour DateTime, pour le dernier correctif de sa version 2.12:

 {
    "nécessite": {
        "nesbot / carbon": "2.12. *"
    }
}

Nous pouvons modifier ce fichier manuellement ou le créer / le mettre à jour à l'aide de commandes. Dans le cas ci-dessus, nous ouvrons simplement une fenêtre de terminal, nous dirigeons vers le répertoire racine du projet, et nous tapons:

 composer besoin de "nesbot / carbon"

Cette commande recherchera la bibliothèque requise dans Packagist (qui se trouve ici ici ) et ajoutera sa dernière version en tant que dépendance du fichier composer.json existant. (Si ce fichier n'existe pas encore, il le créera d'abord.) Ensuite, nous pouvons importer les dépendances dans le projet, qui sont ajoutées par défaut dans le dossier vendor / en exécutant simplement: 19659018] compositeur installer

Chaque fois qu'une dépendance est mise à jour, par exemple, nesbot / carbon est disponible en version 2.12.1 et la version actuellement installée est la version 2.12.0. Ensuite, Composer se chargera d'importer la bibliothèque correspondante en exécutant: [19659018] mise à jour du compositeur

Si nous utilisons Git, il suffit de spécifier le dossier vendor / du fichier .gitignore pour ne pas valider les dépendances du projet sous contrôle de version, ce qui en fait un jeu d'enfant conservez le code de notre projet bien découplé des bibliothèques externes.

Composer offre de nombreuses fonctionnalités supplémentaires, qui sont décrites de manière adéquate dans la documentation . Cependant, déjà dans son utilisation la plus élémentaire, Composer donne aux développeurs un pouvoir illimité pour gérer les dépendances du projet.

Introduction à WPackagist

Semblable à Packagist, WPackagist est un référentiel de paquets PHP. Cependant, il a une particularité: il contient tous les thèmes et les plugins hébergés sur les répertoires de plugins WordPress et theme ce qui les rend disponibles pour une gestion via Composer.

Pour utiliser WPackagist, notre fichier composer.json doit contenir les informations suivantes:

 {
    "référentiels": [
        {
            "type":"composer",
            "url":"https://wpackagist.org"
        }
    ]
}

Ensuite, n'importe quel thème ou plugin peut être importé dans le projet en utilisant respectivement "wpackagist-theme" et "wpackagist-plugin" ainsi que le slug de le thème ou le plugin dans le répertoire WordPress (tel que "akismet" dans https://wordpress.org/plugins/akismet/ ) en tant que nom de package. Les thèmes n’ayant pas de version principale, il est recommandé d’utiliser la contrainte de version «*»:

 {
    "nécessite": {
        "wpackagist-plugin / akismet": "^ 4.1",
        "wpackagist-plugin / bbpress": "> = 2.5.12",
        "wpackagist-theme / twentynineteen": "*"
    }
}

Les paquets disponibles dans WPackagist ont reçu le type "wordpress-plugin" ou "wordpress-theme". En conséquence, après avoir exécuté composer update au lieu d'installer les thèmes et plug-ins correspondants sous le dossier par défaut vendor / ceux-ci seront installés à l'emplacement où WordPress les attend: sous les dossiers wp-content / themes / et wp-content / plugins / respectivement.

Possibilités et limites d'utilisation de WordPress et du compositeur ensemble

Jusqu'ici, tout va bien: le compositeur en fait un jeu d'enfant gérer les dépendances d'un projet PHP. Toutefois, le noyau de WordPress ne l'a pas adopté comme outil de choix pour la gestion de la dépendance, principalement parce que WordPress est une application héritée qui n'a jamais été conçue pour être utilisée avec Composer et la communauté ne peut pas accepter si WordPress doit être considéré comme le site ou la dépendance d'un site et l'intégration de ces approches nécessite des bidouilles.

Dans cette perspective, WordPress est surperformé par de nouveaux frameworks qui pourraient intégrer Composer dans leur architecture. Par exemple, Laravel a subi une réécriture majeure en 2013 pour établir Composer en tant que gestionnaire de packages au niveau de l'application . Par conséquent, le noyau de WordPress n'inclut toujours pas le fichier composer.json nécessaire pour gérer WordPress en tant que dépendance du compositeur.

Sachant que WordPress ne peut pas être géré de manière native par Composer, explorons les différentes manières. un tel support peut être ajouté et quels obstacles nous rencontrons à chaque fois.

Il existe trois manières fondamentales dont WordPress et Composer peuvent travailler ensemble :

1. Gérer les dépendances lorsque développement d'un thème ou d'un plugin;
2. Gérer les thèmes et les plugins sur un site;
3. Gérer le site complètement (y compris ses thèmes, ses plugins et le noyau de WordPress).

Il existe deux situations de base concernant les destinataires suivants: accès au logiciel (un thème ou un plugin, ou le site):

1. Le développeur peut avoir un contrôle absolu sur la façon dont le logiciel sera mis à jour, p.ex. en gérant le site pour le client ou en fournissant une formation sur la façon de le faire;
2. Le développeur n’a pas le contrôle absolu de l’expérience de l’administrateur, par exemple. en libérant des thèmes ou des plugins via le répertoire WordPress, qui seront utilisés par une partie inconnue.

À partir de la combinaison de ces variables, nous aurons plus ou moins de liberté quant à la profondeur à laquelle nous pourrons intégrer WordPress et Composer.

Du point de vue philosophique concernant l’objectif et le groupe cible de chaque outil, alors que Composer responsabilise les développeurs, WordPress se concentre d’abord sur les besoins des utilisateurs finaux, puis seulement sur ceux des développeurs. Cette situation n'est pas contradictoire: par exemple, un développeur peut créer et lancer le site Web à l'aide de Composer, puis transférer le site à l'utilisateur final qui (à partir de ce moment) utilisera les procédures standard d'installation de thèmes. et plugins – contournant Composer. Cependant, le site et son fichier composer.json ne sont plus synchronisés et le projet ne peut plus être géré de manière fiable par Composer: Suppression manuelle de tous les plugins du wp-content / plugins / Le dossier et l'exécution de la mise à jour du compositeur ne téléchargeront pas à nouveau les plugins ajoutés par l'utilisateur final.

L'alternative de garder le projet synchronisé serait de demander à l'utilisateur d'installer des thèmes et des plugins. par le compositeur. Cependant, cette approche va à l'encontre de la philosophie de WordPress : demander à l'utilisateur final d'exécuter une commande telle que composer install pour installer les dépendances d'un thème ou d'un plug-in ajoute des frictions, et WordPress ne peut pas s'attendre à ce que tous les utilisateurs puissent exécuter cette tâche aussi simple que cela puisse être. Donc, cette approche ne peut pas être la solution par défaut; Au lieu de cela, il ne peut être utilisé que si nous possédons un contrôle absolu sur l'expérience utilisateur sous comme lors de la création d'un site pour notre propre client et de la formation à la mise à jour de ce site. [19659005] L’approche par défaut, qui gère le cas où la partie utilisant le logiciel est inconnue, consiste à publier des thèmes et des plug-ins avec toutes leurs dépendances intégrées. Cela implique que les dépendances doivent également être téléchargées vers le plugin de WordPress . ] and theme référentiels de subversion, annulant le but du compositeur. En suivant cette approche, les développeurs peuvent toujours utiliser Composer pour le développement, mais pas pour la publication du logiciel.

Cette approche n’est pas non plus sans faille: si deux plug-ins différents regroupent des versions différentes d’une même bibliothèque incompatibles, et que ces deux plugins sont installés sur le même site, cela pourrait causer un dysfonctionnement du site . Une solution à ce problème consiste à modifier l’espace de noms des dépendances en un espace de noms personnalisé, ce qui garantit que différentes versions de la même bibliothèque, en ayant différents espaces de noms, sont traitées comme des bibliothèques différentes. Ceci peut être réalisé par un script personnalisé ou par Mozart une bibliothèque qui compose toutes les dépendances sous forme de package dans un plugin WordPress.

Pour gérer entièrement le site, Composer doit installer WordPress dans un sous-répertoire afin de pouvoir installer et mettre à jour le noyau de WordPress sans affecter les autres bibliothèques, l’installation doit donc considérer WordPress comme une dépendance du site et non du site lui-même. (Le compositeur ne prend pas position: cette décision a pour but pratique de permettre l'utilisation de l'outil. D'un point de vue théorique, nous pouvons toujours considérer WordPress comme étant le site.) WordPress pouvant être installé dans un sous-répertoire cela ne représente pas un problème technique. Cependant, WordPress est installé par défaut sur le dossier racine et son installation dans un sous-répertoire implique une décision consciente de la part de l'utilisateur.

Pour faciliter la gestion complète de WordPress avec Composer, plusieurs projets ont opté pour l'installation de WordPress. dans un sous-dossier et fournissant un fichier avisé composer.json avec une configuration qui fonctionne bien: contributeur principal John P. Bloch fournit un miroir du noyau de WordPress et Roots fournit un passe-partout WordPress appelé Bedrock . Je vais décrire comment utiliser chacun de ces deux projets dans les sections suivantes.

Gestion de l’ensemble du site WordPress à travers le miroir du noyau de WordPress de John P. Bloch

J’ai suivi la recette de Andrey “Rarst” Savchenko pour créer l'ensemble du compositeur du site qui utilise le miroir du noyau de WordPress de John P. Bloch. Ensuite, je vais reproduire sa méthode en ajoutant des informations supplémentaires et en mentionnant les pièges que j'ai trouvés en cours de route.

Créez d'abord un fichier composer.json avec le contenu suivant dans le dossier racine de votre projet :

 {
    "type": "projet",
    "config": {
        "vendor-dir": "content / vendor"
    },
    "supplémentaire": {
        "wordpress-install-dir": "wp"
    },
    "nécessite": {
        "johnpbloch / wordpress": "> = 5.1"
    }
}

Grâce à cette configuration, Composer installera WordPress 5.1 dans le dossier "wp" et des dépendances seront installées dans le dossier "contenu / fournisseur" . Puis dirigez-vous vers le dossier racine du projet dans terminal et exécutez la commande suivante pour que Composer fasse son travail et installe toutes les dépendances, y compris WordPress:

 composer install --prefer-dist

Ajoutons ensuite quelques plugins et le thème pour lequel nous devons également ajouter WPackagist en tant que référentiel, et configurons-les pour qu'ils soient installés sous [contenu] "plugins" et "contenu / themes " respectivement. Comme ce ne sont pas les emplacements par défaut attendus par WordPress, nous devrons plus tard indiquer à WordPress où les trouver par constante WP_CONTENT_DIR .

Note : Le noyau de WordPress inclut par défaut quelques thèmes et plugins dans les dossiers "wp / wp-content / themes" et "wp / wp-contenu / plugins" mais ne sont pas accessibles.

Ajouter le contenu suivant à composer.json en plus du précédent:

 {
    "référentiels": [
        {
            "type": "composer",
            "url" : "https://wpackagist.org"
        }
    ],
    "nécessite": {
        "plug-in wpackagist / wp-super-cache": "1.6. *",
        "wpackagist-plugin / bbpress": "2.5. *",
        "wpackagist-theme / twentynineteen": "*"
    },
    "supplémentaire": {
        "chemins d'installation": {
            "content / plugins / {$ name} /": ["type:wordpress-plugin"],
            "content / themes / {$ name} /": ["type:wordpress-theme"]
        }
    }
}

Et exécutez ensuite dans le terminal:

 composer la mise à jour --prefer-dist

Hallelujah! Le thème et les plugins ont été installés! Puisque toutes les dépendances sont réparties dans des dossiers wp contenu / fournisseurs contenu / plugins et contenu / thèmes nous pouvons facilement les ignorer lors de la validation de notre projet sous contrôle de version via Git. Pour cela, créez un fichier .gitignore avec ce contenu:

 wp /
contenu / fournisseur /
contenu / thèmes /
contenu / plugins /

Note : Nous pourrions aussi ignorer directement le dossier content / qui ignorera déjà tous les fichiers multimédias sous contenu / uploads / et les fichiers générés. par des plugins, qui ne doivent probablement pas passer sous contrôle de version.

Il reste encore quelques choses à faire avant de pouvoir accéder au site. Commencez par dupliquer le fichier wp / wp-config-sample.php dans wp-config.php (et ajoutez une ligne avec wp-config.php à le fichier .gitignore pour éviter de le commettre, car ce fichier contient des informations sur l’environnement), et éditez-le avec les informations habituelles requises par WordPress (informations de base de données, clés secrètes et sels). Ajoutez ensuite les lignes suivantes en haut de wp-config.php qui chargeront l'autochargeur de Composer et définiront une constante WP_CONTENT_DIR dans le dossier content / : [19659074] // Chargement de l'autoloader par Load Composer
require_once (__DIR __. '/ content / vendor / autoload.php');

// Déplacer l'emplacement du répertoire de contenu
define ('WP_CONTENT_DIR', nom de répertoire (__ FILE __). '/ content');

Par défaut, WordPress définit la constante WP_CONSTANT_URL avec la valeur get_option ('siteurl'). '/ Wp-content' . Étant donné que nous avons modifié le répertoire de contenu par défaut "wp-content" en "contenu" nous devons également définir la nouvelle valeur pour WP_CONSTANT_URL . Pour ce faire, nous ne pouvons pas faire référence à la fonction get_option car elle n’a pas encore été définie. Nous devons donc coder le domaine en code ou, mieux, nous pouvons le récupérer à partir de $ _ SERVER comme ceci:

 $ s = empty ($ _ SERVER ["HTTPS"])? '': ($ _SERVER ["HTTPS"] == "on")? "s": "";
$ sp = strtolower ($ _ SERVER ["SERVER_PROTOCOL"]);
$ protocole = substr ($ sp, 0, strpos ($ sp, "/")). $ s;
$ port = ($ _SERVER ["SERVER_PORT"] == "80")? "": (":". $ _ SERVER ["SERVER_PORT"]);
define ('WP_CONTENT_URL', $ protocol. ": //". $ _ SERVER [’SERVER_NAME']. $ port. '/ content');

Nous pouvons maintenant accéder au site sur le navigateur sous domain.com/wp/ et procéder à l'installation de WordPress. Une fois l'installation terminée, nous nous connectons au tableau de bord et activons le thème et les plugins.

Enfin, WordPress ayant été installé dans le sous-répertoire wp l'URL contiendra le chemin “ / wp . ] ”Lors de l'accès au site. Supprimons cela (pas pour le côté administrateur cependant, qui, en étant accédé sous / wp / wp-admin / ajoute un niveau de sécurité supplémentaire au site).

La documentation propose deux méthodes pour le faire. ceci: avec ou sans changement d'URL. J'ai suivi les deux et j'ai trouvé le changement d'URL sans un peu insatisfaisant car il fallait spécifier le domaine dans le fichier .htaccess mélangeant ainsi le code de l'application et les informations de configuration. Je vais donc décrire la méthode avec changement d’URL.

Tout d’abord, allez dans «Paramètres généraux», que vous trouverez sous domain.com/wp/wp/admin/options-general.php . et enlevez le bit “ / wp ” de la valeur “Adresse du site (URL)” et sauvegardez-le. Cela fait, le site sera momentanément endommagé: la navigation sur la page d'accueil répertorie le contenu du répertoire et la consultation d'un article de blog renvoie un 404. Toutefois, ne paniquez pas, le problème sera résolu à l'étape suivante. [19659005] Ensuite, nous copions le fichier index.php dans le dossier racine et éditons ce nouveau fichier en ajoutant « wp / » au chemin du fichier requis, comme suit: [19659074] / ** Charge l'environnement et le modèle WordPress * /
require (nomdirect (__FILE__). '/wp/wp-blog-header.php');

Nous avons terminé! Nous pouvons maintenant accéder à notre site dans le navigateur sous domain.com :

Même s'il a téléchargé l'intégralité du noyau de code WordPress et plusieurs bibliothèques, notre projet lui-même ne comprend que six fichiers dont seuls cinq doivent être associés à Git:

1. .gitignore
2. composer.json
3. composer.lock
   Ce fichier est généré automatiquement par Composer et contient les versions de toutes les dépendances installées.
4. index. php
   Ce fichier est créé manuellement.
5. .htaccess
   Ce fichier est créé automatiquement par WordPress, aussi nous pourrions éviter de le commettre, cependant, nous pourrons le personnaliser rapidement pour l'application, auquel cas

Le sixième fichier restant est le wp-config.php qui ne doit pas être commis car il contient des informations relatives à l'environnement.

Pas mal!

The Le processus s’est déroulé sans heurts, mais il pourrait être amélioré si les problèmes suivants

1. Certains codes d’application ne sont pas validés sous contrôle de version.
   Puisqu'il contient des informations sur l’environnement, le fichier wp-config.php ne doit pas être attribué à Git. nécessitant de conserver une version différente de ce fichier pour chaque environnement. Cependant, nous avons également ajouté une ligne de code pour charger l'autoloader de Composer dans ce fichier, qui devra être répliqué pour toutes les versions de ce fichier dans tous les environnements.
2. Le processus d'installation n'est pas entièrement automatisé.
   Après avoir installé les dépendances via Composer, vous devez toujours installer WordPress via sa procédure standard, vous connecter au tableau de bord et modifier l'URL du site pour ne plus contenir « wp / ». Par conséquent, le processus d'installation est légèrement fragmenté, impliquant à la fois un script et un opérateur humain.

Voyons maintenant comment se comporte Bedrock pour la même tâche.

Gestion de l'ensemble du site WordPress au travers du substratum

Bedrock est un passe-partout WordPress avec une structure de dossier améliorée, qui ressemble à ceci:

 ├── composer.json
├── config
├── ├── application.php
└── └── environnements
├── development.php
├── staging.php
└── production.php
├── vendeur
└── web
    ├── app
    ├── ├── mu-plugins
    ├── plugins
    ├── thèmes
    └── uploads
    ├── wp-config.php
    ├── index.php
    └── wp

Les personnes à l'origine de Roots ont choisi cette structure de dossiers pour faire en sorte que WordPress souscrive à l'application Twelve Factor . Ils expliquent comment cela est accompli grâce à une série de billets de blog . Cette structure de dossiers peut être considérée comme une amélioration par rapport à celle standard de WordPress pour les comptes suivants:

• Elle ajoute la prise en charge de Composer en déplaçant le coeur de WordPress du dossier racine vers le dossier web / wp ; [19659038] Il améliore la sécurité, car les fichiers de configuration contenant les informations de la base de données ne sont pas stockés dans le dossier web qui est défini comme racine du document du serveur Web (la menace pour la sécurité est que, si le serveur Web tombe en panne, aucune protection ne bloquerait l'accès aux fichiers de configuration );
• Le dossier wp-content a été renommé en « app », qui est un nom plus standard puisqu'il est utilisé par d'autres frameworks tels que Symfony et Rails, et pour mieux refléter le contenu de ce dossier.

Bedrock introduit également différents fichiers de configuration pour différents environnements (développement, staging, production), et ce, proprement. découples informations de figuration du code à travers la bibliothèque PHP dotenv qui charge les variables d'environnement à partir d'un fichier .env qui ressemble à ceci:

 DB_NAME = nom_bdd
DB_USER = utilisateur_base_de_données
DB_PASSWORD = mot_de_passe_base_de_données

# Vous pouvez éventuellement utiliser un nom de source de données (DSN)
# Lorsque vous utilisez un DSN, vous pouvez supprimer les variables DB_NAME, DB_USER, DB_PASSWORD et DB_HOST.
# DATABASE_URL = mysql: // utilisateur_base_de_données: mot_de_passe_base_données @ hôte_base_de_données: port_base_de_données / nom_base_de_données

# Variables optionnelles
# DB_HOST = localhost
# DB_PREFIX = wp_

WP_ENV = développement
WP_HOME = http: //example.com
WP_SITEURL = $ {WP_HOME} / wp

# Générez vos clés ici: https://roots.io/salts.html
AUTH_KEY = 'generateme'
SECURE_AUTH_KEY = 'generateme'
LOGGED_IN_KEY = 'generateme'
NONCE_KEY = 'generateme'
AUTH_SALT = 'generateme'
SECURE_AUTH_SALT = 'generateme'
LOGGED_IN_SALT = 'generateme'
NONCE_SALT = 'generateme'

Continuons à installer Bedrock, après leurs instructions . Commencez par créer un projet comme celui-ci:

 le compositeur crée le projet "roots / bedrock"

Cette commande amorce le projet Bedrock dans un nouveau dossier “bedrock”, en définissant la structure du dossier, en installant toutes les dépendances initiales et en créant un fichier .env dans le dossier racine qui doit contenir le fichier. configuration du site. Nous devons ensuite éditer le fichier .env pour ajouter la configuration de la base de données ainsi que les clés secrètes et les sels, comme il est normalement requis dans le fichier wp-config.php ainsi que pour indiquer le type l'environnement (développement, mise en scène, production) et le domaine du site.

Ensuite, nous pouvons déjà ajouter des thèmes et des plugins. Bedrock est livré avec des thèmes de vingt à vingt-dix ans fournis par défaut sous le dossier web / wp / wp-content / themes mais lorsque vous ajoutez d'autres thèmes via Composer, ils sont installés sous web / app / themes . . Ce n'est pas un problème, car WordPress peut enregistrer plusieurs répertoires pour stocker des thèmes via la fonction register_theme_directory .

Bedrock inclut les informations WPackagist dans le fichier composer.json . peut déjà installer des thèmes et des plugins à partir de ce référentiel. Pour ce faire, il suffit de marcher sur le dossier racine du projet et d'exécuter la commande composer require pour chaque thème et le plug-in à installer (cette commande installe déjà la dépendance, il n'est donc pas nécessaire d'exécuter mise à jour du compositeur ):

 cd bedroot
le compositeur a besoin de "wpackagist-theme / zakra"
composer nécessite "wpackagist-plugin / akismet": "^ 4.1"
composer nécessite "wpackagist-plugin / bbpress": "> = 2.5.12"

La ​​dernière étape consiste à configurer le serveur Web, en définissant la racine du document sur le chemin complet du dossier web . Après cela, en vous dirigeant vers domain.com dans le navigateur, nous sommes accueillis avec joie par l'écran d'installation de WordPress. Une fois l'installation terminée, vous pouvez accéder à l'administrateur WordPress sous domain.com/wp/wp-admin et activer le thème et les plug-ins installés. Le site est accessible sous domain.com . Succès!

L'installation de Bedrock s'est faite en douceur. En outre, Bedrock fait mieux de ne pas mélanger le code de l'application avec les informations d'environnement dans le même fichier, de sorte que le problème concernant le code de l'application qui n'a pas été validé sous le contrôle de version que nous avions obtenu avec la méthode précédente ne se produit pas ici.

Conclusion

Avec le lancement de Gutenberg et le remplacement imminent de la version minimale requise de PHP, WordPress est entré dans une ère de modernisation qui offre une merveilleuse opportunité de repenser la manière dont nous construisons des sites WordPress pour tirer le meilleur parti des nouveaux outils et technologies. Composer, Packagist et WPackagist sont de tels outils qui peuvent nous aider à produire un meilleur code WordPress, en mettant l’accent sur les composants réutilisables pour créer des applications modulaires faciles à tester et à corriger.

Initialement publié en 2012, Composer n’est pas précisément ce que nous Cela s'appellerait un "nouveau" logiciel, cependant, il n'a pas été intégré au noyau de WordPress en raison de quelques incompatibilités entre l'architecture de WordPress et les exigences de Composer. Ce problème a été une source constante de frustration pour de nombreux membres de la communauté de développement WordPress, qui affirment que l'intégration de Composer dans WordPress améliorera la création et la publication de logiciels pour WordPress. Heureusement, il n'est pas nécessaire d'attendre que ce problème soit résolu car plusieurs acteurs se sont chargés de résoudre le problème.

Dans cet article, nous avons examiné deux projets intégrant manuellement WordPress et Composer: manuellement. en plaçant notre fichier composer.json en fonction du miroir du noyau de WordPress de John P. Bloch et de Bedrock de Roots. Nous avons vu comment ces deux alternatives, qui offrent une marge de manœuvre différente pour façonner la structure de dossiers du projet et qui sont plus ou moins lisses au cours du processus d’installation, peuvent répondre à notre exigence de gestion complète d’un site WordPress, y compris l’installation de le noyau, les thèmes et les plugins.

Si vous avez déjà utilisé WordPress et Composer ensemble, que ce soit par le biais de l'un des deux projets décrits ou d'un autre, j'aimerais connaître votre opinion dans les commentaires ci-dessous.

Je voudrais remercier Andrey “Rarst” Savchenko, qui a révisé cet article et lui a fourni de précieux commentaires.

Pour en savoir plus sur SmashingMag:

(rb, ra, il) [19659131]

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)

Articles similaires