Het behouden van functionaliteit gescheiden van de presentatie is een best practice voor de ontwikkeling van WordPress-thema's. In dit bericht leert u hoe u dat precies doet, zodat uw gebruikers een verpakte plug-in krijgen die uniek is voor uw thema's.
We verkopen al meer dan vier jaar WordPress-thema's op ThemeForest, en gedurende deze tijd hebben we veel dingen geleerd die ons hebben geholpen om succesvol te zijn op de markt. Een van de belangrijkste aspecten van succesvolle thema-ontwikkeling is "correcte logica voor het ontwikkelen van thema's".
Het belangrijkste voordeel van het scheiden van ontwikkelingslogica is productiesnelheid: hoe sneller u kwaliteitsthema's kunt maken, hoe meer inkomsten u kunt genereren. Het behouden van functionaliteit in een aparte plug-in is ook handig als het gaat om updates. Stel je voor dat je tien thema's hebt op ThemeForest en dat je nieuwe functionaliteit als update wilt toevoegen. Als u al uw functionaliteit in een enkele plug-in hebt, hoeft u deze slechts eenmaal over de hele linie bij te werken, anders wordt zelfs een kleine update traag en mogelijk pijnlijk.
Dus als u krachtige thema's wilt maken en meer geld wilt verdienen, respecteer dan het plug-in- en themasysteem van WordPress.
Welke functionaliteit kan een premium-thema bevatten? Wat voor soort dingen moeten we in een aparte plugin stoppen? Hier is een lijst met belangrijke componenten die we meestal gescheiden houden van themabestanden:
In deze post zullen we niet gedetailleerd beschrijven hoe we de componenten zelf moeten maken, maar we zullen uitleggen hoe we ze allemaal in één add-ons plug-in moeten stoppen.
Ga naar je wp-inhoud> plug-ins en maak een lege map met de naam van je ingepakte plug-in. We raden u aan een voor zichzelf sprekende naam te gebruiken. Onze invoegtoepassing voor add-ons wordt bijvoorbeeld "ninzio-addons" genoemd (Ninzio is de naam van ons bedrijf).
Belangrijk: gebruik geen onderstrepingsteken in de mapnaam! Gebruik indien nodig een streepje.
Vervolgens maakt u in die plugin-map een php-bestand met exact dezelfde naam als uw map. In ons voorbeeld zou dat "ninzio-addons.php" zijn. Nogmaals, geen onderstrepingstassen alstublieft. Open dat bestand en voeg de volgende DocBlock-headercommentaar toe:
/ ** * Naam van plug-in: de naam van uw plug-in * URI-plug-in: de URL van uw plug-in * Tekstdomein: tekst-domein * Domein-pad: / talen / * Beschrijving: korte beschrijving van de plug-in * Auteur: naam auteur * Versie: 1.0.0 * Auteur URI: auteur uri * /
Laten we de details bekijken die we hier hebben toegevoegd:
Nu, na het creëren van onze plug-ins add-onsmap en het hoofdbestand is het tijd om onze plug-in te configureren.
Voeg dit fragment in het hoofdinvoegbestand toe, na de koptekstcommentaar:
if (! defined ('ABSPATH')) exit; // Afsluiten indien rechtstreeks geopend
Dit is om veiligheidsredenen; het blokkeert directe toegang tot het plug-in bestand.
Voeg direct daarna deze code toe:
function your_addons_load_plugin_textdomain () load_plugin_textdomain ('ninzio-addons', false, dirname (plugin_basename (__ FILE__)). '/ languages /'); add_action ('plugins_loaded', 'your_addons_load_plugin_textdomain');
Hier laden we ons tekstdomein voor plug-ins in, zorg ervoor dat de functienaam correct is. Onze aanbeveling voor naamgevingsfuncties is om zelfbeschrijvende namen te gebruiken met een voorvoegsel van uw plug-in. Bijvoorbeeld ninzio_addons
. En omdat dit een php-functie is, kunnen we onderstrepingstekens gebruiken in plaats van streepjes.
Zorg ervoor dat u nauwkeurig bent bij het kopiëren of typen van de functie load_plugin_textdomain. Voer voor de domeinparameter het exacte tekstdomein in dat we eerder hebben gedefinieerd. En voor de relatieve parameter van het filterpad voert u het pad in naar de map met talen die we eerder hebben gemaakt.
Laten we nu het pad van onze invoegmap definiëren; voeg deze code toe:
define ('your_addons', plugin_dir_path (__FILE__));
Hier gebruiken we your_addons
als plugin-mappad. Tot zover goed; we hebben onze plug-in gemaakt, nu is het tijd om het met aangepaste functionaliteit te vullen.
We zullen deze stap niet gebruiken om te bespreken hoe een optiepaneel voor een thema kan worden gemaakt: u kunt een aangepast paneel maken of doen wat wij doen; gebruik een kant-en-klaar framework met een themaoptie. Als u nog niet bekend bent met de frameworks van optionele panels, raden we u aan Bonang Salemane's artikelen over de integratie van het Redux Framework-thema te lezen:
Als u een themakeuzepaneel aan uw add-ons wilt toevoegen, kopieert u de map met het optiepaneel volledig in de add-on-invoegtoepassing. Nu moeten we verschillende bestanden nodig hebben om het te activeren:
if (! class_exists ('ReduxFramework') && file_exists (your_addons. '/optionpanel/framework.php')) require_once ('optionpanel / framework.php'); if (! isset ($ redux_demo) && file_exists (your_addons. '/optionpanel/config.php')) require_once ('optionpanel / config.php');
In dit codefragment hebben we de twee hoofdbestanden van reduxframework nodig: het framework.php-bestand dat de functionaliteit van het optiepaneel beheert, en het config, php-bestand dat verantwoordelijk is voor configuraties van het optiepaneel. Onze optiepaneelbestanden bevinden zich in een "optionpanel" -map die zich in de map ninzio-addons-plug-ins bevindt. Gedaan.
Het wordt tijd dat we enkele aangepaste functies opnemen. Maak een bestand in uw add-ons-pluginmap en noem het iets als "addons-functons.php". Zet al je eigen functies in dit bestand.
Een ding om naar te kijken is dat u de juiste naamgevingsconventies voor de functie gebruikt. Gebruik beschrijvende functienamen met een uniek voorvoegsel. Bijvoorbeeld:
function your_addons_profile_social_links () ...
Direct na de themakaderbestanden hebt u uw aangepaste functiedossier nodig:
require_once ('includes / addons-functions.php');
En nu, voeg een aantal aangepaste widgets toe. Maak een map met de naam "widgets" in je invoegtoepassing add-ons add-ons, zet al je aangepaste widgets-bestanden in die map. Aangepaste widgets bestandsnamen zijn hier niet kritisch, maar het wordt aanbevolen om prefixen en streepjes te gebruiken, geen underscores.
Ons aangepaste Twitter-widgetbestand wordt bijvoorbeeld "ninzio-recent-tweets.php" genoemd. Op dezelfde manier wordt onze Mailchimp-widget "ninzio-mailchimp.php" genoemd. Laten we ze als volgt opnemen:
require_once ('widgets / ninzio-recent-tweets.php'); require_once ('widgets / ninzio-mailchimp.php');
Nogmaals, we zullen niet het feitelijke aangepaste creatieproces van widgets behandelen; kijk daarvoor eens naar het bericht van Bonang Salemane:
Als u een portfolio of evenementen wilt toevoegen of iets dat vergelijkbaar is met de reguliere berichten van WordPress, maar u moet wel gescheiden zijn van het thema, moet u aangepaste berichttypen gebruiken. Al onze thema's bevatten aangepaste berichttypen. Het maken van aangepaste berichttypen kan ingewikkeld zijn, dus nogmaals, dit valt buiten het bestek van deze tutorial, maar ik raad aan om Tom McFarlin's te lezen:
Voor aangepaste berichttypen moet u een aparte map maken in uw invoegtoepassing voor add-ons, bijvoorbeeld 'ninzio-projects'. En plaats in die map al uw bestanden die betrekking hebben op uw aangepaste berichttypen. De belangrijkste bestanden hier zijn de belangrijkste bestanden die de aangepaste berichttypen maken, het enkele berichtbestand en het loop- / archiefpostbestand. Geef een naam aan uw aangepaste hoofdbestand van het berichttype, zoals u uw aangepaste posttypemap hebt genoemd, zoals "ninzio-projects.php". Plaats uw aangepaste posttypecode in dat bestand en activeer vervolgens uw aangepaste berichttype om het hoofdbestand te kunnen gebruiken:
require_once ('ninzio-projects / ninzio-projects.php');
Wanneer u dergelijke functies van elkaar scheidt, moet u altijd rekening houden met uw klanten - meer precies, hoe zij uw aangepaste sjabloonbestanden van het berichttype (archief en single) kunnen uitbreiden / herschrijven. Laten we aannemen dat onze aangepaste naam van het berichttype "projecten" is. Het enkele aangepaste berichttype-bestand zou "single-projects.php" moeten heten en het loop- / archiefbestand zou "archive-projects.php" moeten heten.
En als uw aangepaste berichttype ook aangepaste taxonomieën heeft, moet u ook een apart bestand voor hen maken. Laten we ons taxonomiebestand "taxonomy-projects.php" noemen. Dus nu hebben we drie bestanden:
single-projects.php archive-projects.php taxonomy-projects.php
Laten we ze herschrijfbaar maken. Voeg deze drie functies toe aan uw hoofd-add-onbestand:
functie your_addons_projects_single_template ($ single_template) global $ post; if ($ post-> post_type == 'projects') if ($ theme_file = locate_template (array ('single-projects.php'))) $ single_template = $ theme_file; else $ single_template = your_addons. 'Projecten / single-projects.php'; return $ single_template; add_filter ("single_template", "your_addons_projects_single_template", 20);
function your_addons_projects_archive_template ($ archive_template) global $ post; if ($ post-> post_type == 'projects') if ($ theme_file = locate_template (array ('archive-projects.php'))) $ archive_template = $ theme_file; else $ archive_template = your_addons. 'Projecten / archive-projects.php'; return $ archive_template; add_filter ("archive_template", "your_addons_projects_archive_template", 20);
function your_addons_projects_taxonomy_template ($ taxonomy_template) if (is_tax ('projecten-categorie')) if ($ theme_file = locate_template (array ('taxonomy-projects.php'))) $ taxonomy_template = $ theme_file; else $ taxonomy_template = your_addons. 'Projecten / taxonomie-projects.php'; return $ taxonomy_template; add_filter ("taxonomy_template", "your_addons_projects_taxonomy_template", 20);
Wijzig de naam van deze functies om uw unieke voorvoegsel te hebben. De belangrijkste logica hier is om de sjabloonbestanden van het aangepaste berichttype te laden nadat gecontroleerd is of een kopie ervan aanwezig is in de themamap. Wanneer uw client de aangepaste berichttypesjabloon kopieert naar het thema en deze uitbreidt of overschrijft, laadt de plug-in voor add-ons de versie van uw klant van het aangepaste berichttypebestand. Dus in deze situatie zijn je kernbestanden in de add-ons-plug-in niet veranderd, ze zijn slechts verlengd door uw klant. Eventuele toekomstige updates van uw invoegtoepassing voor add-ons zullen de aangepaste aanpassingen van uw klant niet verwijderen.
Voor aangepaste scripts en stijlen raden we u aan om afzonderlijke mappen te maken en de bestanden in te palmen zoals u zou doen in het "functions.php" bestand van uw thema.
Als u van plan bent om aangepaste shortcodes toe te voegen, moet u uw shortcodes-bestand maken en opnemen in uw map add-ons. Maak een map met de naam "shortcodes" en maak in die map het bestand "yourprefix-shortcodes.php" (in ons geval: "ninzio-shortcodes.php"). In het bestand "-shortcodes.php" moet u al uw aangepaste shortcodes-code plaatsen.
Zoals je nu hebt verzameld, zullen we deze tutorial niet gebruiken om het maken van aangepaste shortcodes te maken, maar ik raad je aan de tutorial van Siddharth te lezen:
Laten we ons aangepaste shortcodes-bestand opnemen:
require_once ('shortcodes / ninzio-shortcodes.php');
We zijn bijna klaar met de plug-in add-ons. Nadat u al uw aangepaste functies hebt getest, is het tijd om het taalbestand te maken om uw plug-in vertaalbaar te maken.
Ga naar de add-ons plug-in map> talen. Gebruik de PoEdit-software (PoEdit is een gratis applicatie, beschikbaar voor Mac, Windows en Linux.) Om het taalbestand te genereren. Nogmaals, wees zeer accuraat met het benoemen van bestanden; de resulterende bestanden moeten exact dezelfde naam hebben als uw add-in-pluginmap. Onze plugin-naam is bijvoorbeeld "ninzio-addons", het taalbestand moet "ninzio-addons.pot" zijn. Dit is het hoofdtaalbestand dat alle tekenreeksen binnen uw tekstdomein bevat. Vanuit dit bestand kunt u andere taalbestanden maken.
Om uw add-on taalbestand te vertalen:
Nu is je plug-in klaar, goed gedaan! We hebben alle noodzakelijke functionaliteit uit onze presentatiebestanden gehaald en een volwaardige plug-in geleverd die we kunnen bijwerken over meerdere thema's.
Ik hoop dat je het leuk vond om mee te gaan, vergeet niet dat je het plug-in sample van plug-ins op Github kunt aanvullen en het als startpunt kunt gebruiken.