Om funktioner och insticksprogram som måste användas

Jag har arbetat med ett litet projekt, mer av en webbapplikation än en webbplats, som har krävt utveckling av både ett anpassat tema och tätt kopplade, men mycket specifik funktionalitet.

Det här är ett mycket snävt fokuserat projekt (som jag förmodligen kommer att prata om någon gång i framtiden) men när jag arbetar med det har det tvingat mig att gå tillbaka till temautvecklingsaspekten av WordPress-utveckling lite.

Nej, jag gör ingen design – tack och lov – men jag måste arbeta med temaanpassningar ur ett funktionellt perspektiv. Genom att göra detta har det dock fått mig att återkomma till de nödvändiga functions.phpoch några överväganden som jag aldrig har haft tidigare.

Dessutom har det fått mig att titta djupare på användningen av mu-pluginsoch fråga när de är nödvändiga och varför jag inte har använt dem mer tidigare (eller ens när man verkligen skulle behöva använda dem).

Så jag tänker poetisk lite om det.

TL;DR

När jag höll på med temautveckling, functions.phpanvändes det till två saker (vilket är problematiskt i sig) men ändå:

1. för att aktivera eller inaktivera funktioner i teman,
2. för att definiera temaspecifik funktionalitet.

Theme Developer Handbook lyder:

Filen functions.phpär där du lägger till unika funktioner till ditt WordPress-tema. Det kan användas för att ansluta till WordPresss kärnfunktioner för att göra ditt tema mer modulärt, utbyggbart och funktionellt.

Temafunktioner, Handbok för temautvecklare

Och jag förstår det, men ur mitt perspektiv och som WordPress har utvecklats tycker jag att det functions.phpborde ägnas åt temaspecifik funktionalitet när det gäller saker som hakar direkt in i kärnan som:

• anpassarfunktion,
• menyfunktioner,
• manus- och stilregistrering,
• och så vidare.

Men om det är något som behöver köras under en av krokarna och det är mer i linje med domänspecifik logik, så hör det inte hemma i den filen.

Detta väcker dock en fråga: Var finns domänspecifik funktionalitet?

Ange måste-använda plugins

Jag vet att incdet blir allt vanligare att se saker som kataloger, men jag bryr mig inte om dem när jag pratar om temautveckling, särskilt när temautveckling inte är mitt fokus och den speciella katalogstrukturen inte är min stil.

Hur som helst, när det kommer till högspecialiserade lösningar (där en lösning är en kombination av presentation och hårt fokuserad funktionalitet) börjar jag fundera på mu-plugins.

Och anledningen till att jag inte tänker på ett standard WordPress-plugin är att de i allmänhet är designade för att fungera med vilket tema som helst och för att lägga till funktionalitet. Inte så med mu-plugins.

Måste plugins (alias mu-plugins) är plugins installerade i en speciell katalog i innehållsmappen och som automatiskt aktiveras på alla platser i installationen.

Måste använda plugins, WordPress.org

Så här är min tankeprocess:

1. Teman är för presentation
2. Plugins är för funktionalitet.
3. Plugins är designade för att användas oavsett ett tema och över en bredd av en webbplats.
4. Must-Use Plugins är plugins som är aktiverade och används som standard
5. Därför bör domänspecifik logik för en specialiserad lösning finnas i ett plugin som måste användas.

Visst kan man säga att vissa teman kan kräva funktionalitet som måste användas, men passar det inte fortfarande med tanken att funktionaliteten ska finnas i ett plugin som måste användas?

Oavsett vilket tillvägagångssätt som jag har följt är detta:

1. Funktionalitet som specifikt kopplar temafunktioner till WordPress-kärnan går in i functions.php.
2. Funktionalitet som är domänlogik men kräver att hela lösningen för att fungera finns i en mu-plugin.

Vid den här tidpunkten i min karriär gör jag inte mycket arbete som fokuserar på något annat än backend, men i de sällsynta möjligheter jag har att utöka det arbete jag gör, upptäcker jag att jag fortfarande försöker vara som analytisk och eftertänksam om hur jag bygger projektet.