Hur man använder PSR-4 Autoloading WordPress Plugins

Last updated 13. November 2022

Inhalt

Säg att du jobbar på ett projekt för någon och du har avgränsat det, uppgifter är delegerade, du har alla bibliotek och verktyg du behöver för att komma igång, och du har separerat vad som kommer att vara temat eller presentationen, och vad kommer att vara funktionalitet eller plugins.

Men i stället för att ha en handfull individuella plugins, tänk om det fanns ett paket med mindre funktionella plugins eller mikro-plugins eller vad du nu vill kalla dem som fungerar för att driva paketet?

Dessutom, alla dessa är byggda på samma grund men som också delar kod med varandra och för att göra saker mer intressanta väljer du att använda en PSR-4 autoloader via Composer för att ta hand om allt detta?

PSR-4 Autoloading WordPress Plugins

För det första, sättet att tänka på vad jag försöker säga (för vem vet om jag är tydlig 🙃) är att du har ditt arbete i wp-content/pluginskatalogen. Och din plugin finns i, säg, acme-pluginsoch har underkataloger för dina mikro-plugins.

Vi kommer att hålla detta enkelt för det här exemplet och säga att det finns huvudplugin och sedan bara en mikroplugin. Katalogen skulle se ut ungefär så här;

Nu finns det filerna du förväntar dig att se i ett plugin:

LÄS MIG,
LICENS,
CHANGELOG,
composer.json
kompositör.lås
Säljare
plugin-bootstrap-filen,
etc.

Nu är det här: Om du använder PSR-2 och du ska använda en PSR-4 autoloader, så finns det två saker du behöver veta:

Namnområdena bör matcha katalogorganisationen. Jag pratade lite om detta under min WordCamp Atlanta 2017-presentation (särskilt under virtuell och logisk organisation).
Hur man arbetar med composer.jsonför att definiera dina autoloaders. Du kan läsa mycket om detta här, men jag ska ge klippanteckningarna i resten av det här inlägget.

Så problemet är att vendorkatalogen ligger på en nivå över där några av källfilerna finns. Således kommer standardsättet att ställa in en anpassad autoloader i Composer inte att fungera.

Det är till exempel väldigt typiskt att se detta :


{
  "name": "pressware/acme-plugins",
  "description": "A demo plugin",
  "autoload": {
    "psr-4": {
      "Acme": "src/",
    }
  },
  // ...
}

Men för att kompensera för vårt arbete måste vi göra detta :


{
  "name": "pressware/acme-plugins",
  "description": "A demo plugin",
  "autoload": {
    "psr-4": {
      "Acme": "",
      "AcmeMicroPlugin": "MicroPlugin/src/"
    }
  },
  // ...
}

Det är en enkel förändring, men det är ett enkelt exempel, eller hur? Så vad är fördelen med detta?

Observera att vi har uppdaterat några ändringar i den automatiska laddningsplatsen. Specifikt, det här är vad som händer:

Det första objektet är namnutrymmet på toppnivå som alla plugins som kommer att tillhöra Acme Plugin kommer att tillhöra.
Den andra posten hänvisar till MicroPlugin som du ser i katalogen ovan. Detta representerar namnutrymmet för just detta plugin, och det säger till Composer att leta efter källfiler som ska laddas automatiskt med hjälp av egenskapskatalogen

Härifrån kommer du att lägga till en ny post för autoloadern som motsvarar varje mikroplugin som kommer att tillhöra toppnivåpluginen.

Organisera framtida mikroplugins

Det finns några sätt som du kan hantera att organisera din kod så att du kan använda en standard autoloader.

Om du följer mikropluginmodellen (i brist på en bättre term) kommer den inte att fungera så du måste omorganisera dina filer, och det kan vara jobbigt med tiden.

Inspelningskälla: tommcfarlin.com