WordPress har eksistert siden 2003 og har blitt standardverktøyet for de fleste som ønsker å starte et nettsted. Selv om den har kommet langt fra sine røtter som bloggmotor, har ikke den underliggende teknologien gjort de samme sprangene som brukeropplevelsen har.
WordPress-utvikling dreier seg fortsatt om mange av standardene som var til stede i 2003. Selv om dette kan gjøre det mer tilgjengelig for folk på grunn av den lavere tekniske forståelsen som kreves, betyr det også at mange nye utviklingsressurser ikke er kompatible med WordPress ut av esken.
I dag skal vi ta en titt på et av de nyere verktøyene som heter Komponist. La oss se hvordan det kan passe inn i WordPress-arbeidsflyten din og diskutere hvorfor du kanskje vil prøve det.
Hva er komponist?
Hver bit av kode du skriver har avhengigheter. Hvis du skriver en WordPress-plugin, er din største avhengighet WordPress selv. Uten kjernefunksjonene som WordPress tilbyr, er det sannsynlig at plugin-en din ikke er nyttig i det hele tatt. Utenfor WordPress selv, kan du trenge en moderne SOAP-klient som nusoap til grensesnitt med SOAP-baserte APIer.
Tidligere ville de fleste ganske enkelt kopiere depotet for nusoap til en katalog i plugin-en deres og deretter inkludere filene som trengs for å bruke biblioteket. Det er her Composer kan gå inn og forenkle noe av administrasjonen av dine avhengigheter.
Composer er en avhengighetsansvarlig. Den er spesielt utviklet for å gjøre det enkelt å installere og administrere avhengigheter. Dette kan bli spesielt viktig hvis du jobber i et team og ønsker å forsikre deg om at hvert medlem av teamet bruker de samme bibliotekene som de gjør utviklingsarbeidet sitt.
I utgangspunktet er Composer en JSON-fil som beskriver avhengighetene du har installert og hvilke versjoner av avhengighetene du vil bruke. Du kan se et grunnleggende eksempel nedenfor som inkluderer nusoap-avhengigheten.
{
“require”: {
«econea/nusoap»: «^0.9.10»
}
}
Når jeg kjører composer require econea/nusoap i plugin-en min, vil den installere nusoap for meg og låse den til den angitte versjonen. I dette tilfellet bruker jeg 0.9.10 og vil fortsette å bruke det med mindre jeg ber Composer om å oppgradere avhengigheten.
Dette har fordelen fremfor å bare laste ned og inkludere nusoap fordi jeg kan bruke komponistoppdatering til å oppdatere alle avhengighetene mine uten å måtte se om det er oppdateringer og manuelt laste dem ned til prosjektet mitt. Composer overtar forvaltningen av ressurser på dette nivået.
Komme i gang med Composer
Å installere komponist er ganske enkelt.
På Windows
Hvis du bruker Windows, er det en installatør levert for å forenkle prosessen. Den vil installere den nyeste versjonen av Composer og gjøre den tilgjengelig globalt for prosjektene dine.
Linux/Unix/macOS
På noen av disse plattformene har du noen flere trinn for å få Composer-oppsett. For å starte, kjør kommandoene som trengs for å laste ned Composer og få den satt opp.
php -r “copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);”
php -r “if (hash_file(‘sha384’, ‘composer-setup.php’) === ‘756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e0936d37fdafedafed 181c7d3’) { echo ‘Installer verifisert’; } else { echo ‘Installer korrupt’; unlink(‘composer-setup.php’); } echo PHP_EOL;”
php composer-setup.php
php -r “unlink(‘composer-setup.php’);”
Deretter vil du kjøre Composer globalt for lokal utvikling, så vi må justere standardinstallasjonen for å sikre at den er tilgjengelig hver gang vi ønsker å bruke Composer. Du kan flytte Composer til å være globalt tilgjengelig med følgende kommando utført fra samme katalog som du nettopp lastet ned Composer fra.
mv composer.phar /usr/local/bin/composer
Oppgraderer Composer
På Windows og macOS er alt du trenger å gjøre for å oppgradere til den nyeste versjonen av Composer å kjøre selvoppdatering av komponist. Hvis du bruker Linux/Unix, må du kjøre sudo apt update && upgrade slik at systemet ser etter de nyeste versjonene, så kan du kjøre selvoppdatering av komponisten for å få den nyeste versjonen.
Nå som du er konfigurert, la oss ta en titt på å bruke Composer til å installere WordPress.
Installer WordPress med Composer
Hva om du vil administrere et helt nettsted med Composer? Først må du bestemme om WordPress er avhengigheten til prosjektet eller kjernen i prosjektet? Ja, litt hjernevridning.
WordPress kan betraktes som en avhengighet av prosjektet fordi sluttmålet for kundene dine ikke er å ha WordPress installert. De vil ha en butikk eller en blogg, og det avhenger av at du installerer WordPress. Dette er holdningen et prosjekt liker Røtter tar med sitt komponistbaserte Bedrock WordPress-oppsett kalt Bedrock.
Å bruke Bedrock betyr at du ikke trenger å fortelle Composer om WPackagist fordi det allerede er satt opp. Det er her jeg anbefaler at du starter hvis du ønsker å administrere et helt nettsted med Composer.
For å installere Bedrock kjør følgende kommando.
komponist skape-prosjekt røtter/grunnfjell
Dette vil gi deg følgende filstruktur.
├── composer.json
├── .env
├── konfig
│ ├── application.php
│ └── miljøer
│ ├── utvikling.php
│ ├── iscenesettelse.php
│ └── produksjon.php
├── leverandør
└── nett
├── app
│ ├── mu-plugins
│ ├── plugins
│ ├── temaer
│ └── opplastinger
├── wp-config.php
├── index.php
└── wp
Dette er veldig annerledes enn standard WordPress-oppsett. For å starte har du filen composer.json i roten av installasjonen. Det er her du vil se Composer-konfigurasjonen.
Env-filen din er der du kan lagre de forskjellige databasekonfigurasjonene. Dette er nødvendig fordi din lokale side og din live side vil ha forskjellige databasepassord og brukernavn. Standard wp-config.php-filen vil forstå variablene du legger inn i .env-filen din fordi Bedrock bruker disse variablene i stedet for hardkoding i databasetilkoblingsinformasjonen.
Din .env-fil bør ignoreres i ditt Git-lager. Når du konfigurerer et nytt nettsted, legger du til en ny .env-fil med nødvendig databasekonfigurasjonsinformasjon.
Det er noen få andre variabler du må sette opp her for å komme i gang med Bedrock, som alle er detaljert i deres dokumentasjon.
Under konfigurasjonsmappen er det forskjellige standardkonfigurasjoner for miljøene du skal bruke. Under utvikling slår dette på feilrapportering, og i produksjonsmiljøene dine sørger det for at feillogging ikke forstyrrer den jevne driften av nettstedet ditt.
Med Bedrock som base kan du nå bruke Composer til å installere WordPress-pluginene dine via WPackagist.
WPackagist er et speil av WordPress-temaet og plugin-depotet. Dette er nødvendig fordi de fleste plugins og temaer som standard ikke er tilgjengelige for Composer å installere. Speilet legger til de nødvendige filene for hver plugin slik at Composer kan brukes til å administrere pluginene.
Hvis du ønsker å installere WooCommerce i din Bedrock-baserte WordPress-installasjon, må du først kreve WooCommerce, komponist krever wpackagist-plugin/woocommerce, så må du fortelle Composer å installere avhengighetene, komponistinstallasjon.
Nå kan du gå til administrasjonsområdet for WordPress-installasjonen din og aktivere WooCommerce og bygge ut nettstedet ditt. For å oppdatere WooCommerce når en ny versjon kommer ut, eller for å oppdatere WordPress, må du kjøre komponistoppdatering.
Det er her et komponistbasert prosjekt kan havne i litt problemer. Hvis du kjører oppdateringene dine gjennom WordPress-administratoren, vil du ha et misforhold mellom det Composer forventer og det WordPress har installert. Hvis du skal gå med Composer, så hold deg til å bruke det som oppdateringsverktøy og ikke arbeid via WordPress-administratoren.
Når Bør du bruke komponist?
Jeg er sikker på at mange av dere spør hvorfor Composer er et så flott verktøy for WordPress-utvikling. WordPress ble ikke bygget med Composer i tankene, så for å jobbe med det må du hoppe gjennom noen bøyler for å få det til å fungere bra.
For plugin- og temautviklere er det en klar sak om at Composer kan gjøre det lettere å håndtere avhengigheter du trenger å hente inn fra det bredere PHP-økosystemet. For WordPress-utviklere er argumentet mindre klart. Noen liker å bruke Composer til å administrere hele nettstedet sitt, slik Roots gjør. Dette kan la deg ha færre filer administrert av Git, men det har aldri virket som en overbevisende sak for meg.
Saken jeg liker er at Composer kan gjøre det enkelt å ha ulike avhengigheter for ulike miljøer. Du kan deretter bruke distribusjonsprosessen til å distribuere disse avhengighetene i miljøene dine og ikke trenger å administrere dem manuelt.
Som utvikler må du også ta hensyn til kundens behov. Hvis de ikke har et utviklingsteam rundt for å administrere nettstedet på lang sikt, kan de få problemer med en ikke-standard WordPress-installasjon. I noen tilfeller kan vertene deres fortelle dem at støtte ikke er tilgjengelig fordi de ikke bruker den vanlige måten å installere og bruke WordPress på. Når du betjener kunder må du alltid balansere den kule teknologien du bruker med det kunden kan håndtere på lang sikt.
Bare av denne grunn bruker jeg ikke Composer i prosjektene mine på hele nettstedet. Mine klienter kommer til å administrere dem fra dag til dag i årevis, og jeg ønsker ikke å sette opp noen ekstra barrierer. Vi ønsker begge at sidene deres skal fungere problemfritt i årene som kommer.
Hvis du ønsker å oppgradere PHP-ferdighetene dine med moderne teknologier, bør du absolutt ta en titt på hvordan Composer kan passe inn i WordPress-arbeidsflytene dine.
