Föreställ dig det här scenariot, du hittar ett riktigt coolt kodavsnitt på en av de många WordPress-tutorialsajterna och klistra in det i ditt temas functions.php-fil.
Kodavsnittet fungerar som annonserat och släpper sedan ditt tema till försäljning på en välkänd temamarknad. Låt oss välja en slumpmässigt från en hatt och gå med… ThemeForest.
Plötsligt blir ditt tema riktigt populärt, det kan bero på den enorma listan med till synes användbara “funktioner” du har inkluderat på ditt temas försäljningssida. Med framgången med ditt tema kommer också ett antal supportfrågor, främst relaterade till plugins som går sönder när du använder ditt tema.
Hur gick det till, frågar du dig? Kanske beror det på att du blint klistrat in slumpmässiga globs av WordPress-kod i din functions.php-fil utan att egentligen tänka på eller förutse några potentiella kompatibilitetsproblem.
Ett verkligt exempel
Så jag försökte hitta ett kodavsnitt som skulle extrahera alla bifogade bilder från ett inlägg och sedan visa dem i det inlägget automatiskt. Jag hittade äntligen ett kodavsnitt på Stack Overflow, klistrade in det i min funktionsfil och det verkade lösa problemet.
Den första raden med kod var följande:
add_filter('the_content', 'strip_shortcodes');
Nåväl, det fungerade, jag tänkte ingenting på det. Senare försökte jag bädda in ett kontaktformulär med en kortkod. Överraskning, det fungerade inte och jag ägnade ungefär en timme åt att försöka ta reda på varför. Om jag hade läst koden jag klistrade in hade jag vetat det.
Det här var för en klientsajt, inte ett publicerat ämne, så som tur var slapp jag ta itu med en flod av supportfrågor p.g.a. mitt dumma misstag.
Vad kommersiella plugin-utvecklare tycker
Här är ett citat från Carl Hancock (Gravity Forms-utvecklare) om just detta ämne:
Stöd för det populära insticksprogrammet Gravity Forms innebär att vi ser mer än vår beskärda del av dåligt kodade teman. Ett av de viktigaste supportrelaterade problemen vi stöter på är teman som inte har utvecklats med hjälp av bästa praxis, vilket resulterar i Gravity Forms stylingproblem och, i vissa fall, konflikter som gör att Gravity Forms inte fungerar korrekt.
Den största boven i dessa situationer är teman som inkluderar kodavsnitt som kopierats och klistrats in från självstudiewebbplatser. Temautvecklare verkar tycka att det faktum att kodavsnittet finns på en tutorialsajt måste vara bra. Tyvärr är det inte alltid så och dessa dåliga beslut resulterar i huvudvärk och supportfrågor för användarna.
Vill du begränsa chansen att få problem med plugin-program orsakade av ett underutvecklat tema? Håll dig till välrenommerade temautvecklare som Press75, iThemes, Headway Themes, Organic Themes, WooThemes och StudioPress, för att nämna några. Var trött på ämnesmarknader där författarens erfarenhet och kompetens kan saknas. I de flesta fall får du vad du betalar för.
Bästa praxis för kodning
Många av dessa problem kan sannolikt undvikas genom att följa WordPress-kodningsstandarder. Till exempel bör du prefixa dina funktionsnamn för att undvika potentiella konflikter.
I fallet med stilproblem med Gravity Forms, kanske du vill undvika vissa allmänna stilar på formuläret och inmatningselementen och istället använda standardvalen för WordPress ID för de flesta av dina stilar.
Dessa inkluderar #searchform, #s, #searchsubmit i sökrutan. Även #commentform #author, #url, #email, #comment, #submit för kommentarsformuläret.
Slutsats
Om du är en temautvecklare och inte har mycket PHP-kunskap, var försiktig när du kopierar och klistrar in dessa kodavsnitt i ditt tema. Även om du inte är så bra på PHP kan du åtminstone läsa koden och försöka förstå den innan du använder den.
Om du till exempel upptäcker att dina kortkoder inte fungerar korrekt, kan en kodrad som nämner “strip_shortcodes” ha något att göra med det.
Ibland får jag en känsla av att WordPress-temautvecklare bara klistrar in slumpmässiga utdrag i sin functions.php-fil, bara så att de kan lista en annan “funktion” på sina temaförsäljningssidor.
Även om jag inte är ett stort fan av den här typen av idéer, går det in på ett helt annat argument om rollen av teman och plugins på WordPress-webbplatser, som jag sparar till ett framtida inlägg.
