Share
In de afgelopen maanden hebben we gekeken naar alle functies en aspecten die WordPress een mogelijk fundament voor de ontwikkeling van toepassingen maken..
We hebben zelfs ongeveer 15 artikelen uitgegeven over alles wat WordPress biedt.
En hoewel we elk van de punten in deze e-mail zullen herzien, misschien wel het grootste om mee weg te nemen dat het bouwen van webapplicaties met WordPress anders is dan het gebruiken van veel populaire kaders die momenteel beschikbaar zijn, namelijk omdat WordPress geen kader.
Het is een basis waarop we kunnen bouwen; geen raamwerk waarmee we bouwen.
Dit betekent dat we ons denkmodel moeten verschuiven over hoe verschillende componenten van onze applicatie worden gebouwd, zodat ze optimaal presteren in de context en omgeving waarin ze worden uitgevoerd.
In de eerste post in de serie kijken we kort naar wat het betekent om een raamwerk te zijn:
Bij computerprogrammering is een softwareframework een abstractie waarin software die generieke functionaliteit biedt, selectief kan worden gewijzigd door extra door de gebruiker geschreven code, waardoor toepassingsspecifieke software wordt geboden. Een softwareframework is een universeel, herbruikbaar softwareplatform om toepassingen, producten en oplossingen te ontwikkelen. Softwarekaders bevatten ondersteuningsprogramma's, compilers, codebibliotheken, tool sets en API's (Application Programming Interfaces) die alle verschillende componenten samenbrengen om de ontwikkeling van een project of oplossing mogelijk te maken..
En wat het betekent om een stichting te zijn:
Kort gezegd, software kan op frameworks worden gebouwd, software kan funderingen verlengen.
Deze twee definities bepalen de weg voor hoe we vervolgens naar WordPress gaan kijken, hoe het is gebouwd, de ontwerppatronen die het implementeert en hoe we ons conceptuele model zodanig moeten aanpassen dat we goed nadenken over de onderliggende codebasis, zodat we gebruiken het zo goed mogelijk voor het werk dat we moeten doen.
Zoals met de meeste webtoepassingen, is WordPress op dezelfde manier gestructureerd:
Maar als het gaat om het bouwen van applicaties bovenop WordPress, veranderen we de zaken een beetje. Dat wil zeggen dat, hoewel WordPress dezelfde structuur behoudt, en we onze eigen oplossingen kunnen bouwen met behulp van onze eigen strategieën, ontwerppatronen, en wat niet, we een beetje in de WordPress-applicatie zullen ingrijpen om onze eigen bedrijfslogica te laten ontbranden en om dingen weer te geven in onze eigen presentatie laag.
Om dit te doen, is het belangrijk om het ontwerppatroon van WordPress te begrijpen. En hoewel MVC en zijn varianten tegenwoordig de rage zijn, volgt WordPress een andere conventie.
In een vervolgartikel over de architectuur van WordPress hebben we besproken hoe WordPress gebruik maakt van door gebeurtenissen gestuurde programmering.
In plaats daarvan werkt evenementgestuurde programmering van het uitgangspunt dat "zoiets is gebeurd". Vandaar de naam voor acties in het WordPress-jargon (natuurlijk hebben we ook filters, maar ik zal die even behandelen).
Concreet hebben we gesproken over hoe dit ons leidt naar het idee hoe, in de programmering, Er gebeurt iets en dan kunnen we profiteren van die kernpunten.
In WordPress worden deze specifieke kenmerken hooks genoemd en kunnen ze op twee verschillende manieren worden gedefinieerd:
We gaan dan verder om elk van deze meer in detail te bespreken. Door het gebruik van langere definities, codevoorbeelden en enkele van de meest voorkomende hooks die beschikbaar zijn, hebben we bekeken hoe we ze allemaal goed kunnen gebruiken en hoe ze ons kunnen helpen wanneer we met onze eigen webtoepassingen werken..
Toen begonnen we te praten over verschillende functies die de kern vormen van de ontwikkeling van webtoepassingen:
We hebben deze items op volgorde behandeld, niet alleen omdat ze de kern zijn van veel moderne webtoepassingen, maar omdat ze vaak in combinatie met elkaar worden gebruikt.
Wanneer een nieuwe gebruiker bijvoorbeeld een account registreert, ontvangt hij / zij een e-mail over hoe het te activeren of hoe hij in moet loggen. Zodra de gebruiker zich bij het systeem aanmeldt, gaan ze waarschijnlijk een sessie opzetten zodat gegevens worden met hen rond de site tot hun sessie wordt beëindigd.
De reden dat dit een beetje een probleem is voor het bouwen van applicaties in WordPress, is omdat er niet echt een sessie-API is. In plaats daarvan moeten we terugvallen op de faciliteiten die worden aangeboden door PHP. Dit is niet moeilijk, maar als je nog nooit de tijd hebt genomen om een native PHP-functie goed te introduceren in een bestaande applicatie die deze op geen enkele manier incorporeert, zijn er verschillende punten die moeten worden begrepen.
En tenslotte is e-mail overduidelijk de sleutel tot communicatie met gebruikers; Veel ontwikkelaars die werken met WordPress (ongeacht hun ervaringsniveau) zijn echter niet altijd op de hoogte van het vermogen om e-mails volledig aan te passen die niet alleen tijdens de gebruikelijke gang van zaken worden verzonden, maar ook wanneer bepaalde gebeurtenissen plaatsvinden die een e-mail in de context van uw toepassing die niet standaard is voor WordPress.
Als de gebruiker eenmaal is aangemeld bij de toepassing, zullen ze waarschijnlijk gegevens opslaan en ophalen, maar als dat niet het geval is, bestaat de kans dat we sommige van hun gegevens opslaan, voor niets anders dan om te weten hoe ze dat doen ' opnieuw gebruik van de site, of om informatie aan hen terug te geven.
Gelukkig heeft WordPress een API die dit heel gemakkelijk maakt, maar het gaat ook ten koste van het moeten valideren en ontsmetten van gegevens, zowel bij het opslaan als ophalen van informatie..
Dit is essentieel omdat we willen voorkomen dat kwaadaardige informatie in de database wordt geplaatst en we zorgen ervoor dat we informatie op een veilige manier ophalen zodat het leesbaar en gebruiksvriendelijk is voor de gebruikers om te zien.
Toen we begonnen met het inpakken van de serie, hebben we een beetje gesproken over moderne URL-herschrijfschema's en hoe WordPress verschillende manieren biedt om dit uit de doos te doen.
Maar we hebben een diepere blik en vergeleken wat veel moderne raamwerken bieden in het aanpassen van routes. We hebben specifiek gekeken naar hoe RESTful routes kunnen worden geïmplementeerd in WordPress met behulp van de Rewrite API om een schoner URL-schema te geven, waarom dit voordelig is voor de gebruikers en hoe het te beheren in WordPress.
Daarnaast hebben we gesproken over een aantal valkuilen bij het doen van dit en hoe ze te vermijden bij het opnemen van aangepaste regels in onze applicatie.
Omdat snelheid een functie is, zijn we toen doorgegaan met een beetje praten over de WordPress Transient API om informatie te leren cachen in onze applicatie.
Hoewel er veel plug-ins en andere softwarepakketten zijn die caching in onze websites en applicaties kunnen introduceren, zijn er nog andere dingen die we als programmeurs kunnen doen om te profiteren van de native functies van WordPress en de onderliggende database die goed zal spelen met de genoemde caching-applicaties.
Het punt is dat, zelfs als u voor caching niet op toepassingen van derden vertrouwt, u nog steeds kunt profiteren van hoe WordPress informatie in zijn database organiseert, zodat u nog steeds de prestaties van uw werk kunt verbeteren door gebruik te maken van deze API.
Ten slotte beëindigden we onze verkenning en bespreking van de functies van het gebruik van WordPress als een basis voor applicatieontwikkeling door te praten over de beste manieren om gegevens te zoeken.
Concreet hebben we het gehad over:
Accentsconagua
WP_Query die wordt gebruikt om geavanceerdere query's uit te voeren over berichttypen, taxonomieën, metadata en meer.WP_User_Query die wordt gebruikt om geavanceerde query's te schrijven tegen de tabel van de gebruiker.$ wpdb voor het schrijven van aangepaste databasequery's.Vervolgens hebben we toepassingsgevallen bekeken voor elk van de beschikbare API's, hoe deze te gebruiken in ons project en onder welke voorwaarden die moeten worden gebruikt.
Omdat WordPress is een database-gestuurde toepassing en vervolgens de applicaties die we er bovenop bouwen, en het is dus belangrijk om precies te weten hoe we moeten omgaan met de beschikbare API's, zodat we niet alleen correcte informatie ophalen, maar dat doen in een performant , gemakkelijk te lezen, te onderhouden en schaalbare manier.
Het uiteindelijke doel van deze reeks artikelen was om een uitgebreid overzicht te geven van wat WordPress biedt voor de ontwikkeling van webtoepassingen.
Natuurlijk moeten we ons als ontwikkelaars herinneren dat er geen wonder bestaat omdat het oplossingen biedt voor onszelf, onze klanten en onze klanten - het gaat erom de juiste tool voor de klus te vinden. In sommige gevallen is dat WordPress, in andere gevallen niet. Dat alles om te zeggen, alleen maar omdat WordPress kan gebruikt, betekent niet dat het gebruikt zou moeten worden, en we zouden niet moeten werken om ons probleem in WordPress te dwingen als het niet het goede is.
Dat gezegd hebbende, toen WordPress doet bied de juiste functionaliteit, API's en structuur om het gegeven probleem op te lossen, en houd deze serie artikelen direct beschikbaar voor referentie omdat het erop gericht is u exact te voorzien van wat u nodig hebt om solide webtoepassingen te bouwen bovenop de bestaande WordPress-foundation.
