-
-
Save TomOffringa/2004eafb6abcfd65b02d to your computer and use it in GitHub Desktop.
| Even een comment geschreven gezien 140 tekens niet voldoet. | |
| Je zegt dat Wordpress geen juiste of duidelijke manier biedt om een front-ender te laten doen waar hij goed in is, namelijk HTML/CSS en JS. | |
| Ik vind juist dat het templaten van Wordpress hier zéér geschikt voor is. Hoe wij bij Studio Wolf werken is dat de front-ender / designer een statische website maakt in HTML/CSS/JS. Dit doen ze gewoon in een mapje in het project die bijv. /raw/ heet. Daar werken ze al hun front-end werk uit tot de website volledig statisch is. | |
| Wat de back-ender vervolgens doet is een theme aanmaken binnen Wordpress. Gewoon een kale map 'leukthema' met een (verplichte) style.css en index.php. | |
| Je kunt in je header.php en footer.php gewoon de algemene header en footer HTML stoppen die de front-ender heeft geschreven, en daardoor dus ook gewoon de CSS blijven gebruiken zoals de front-ender dat doet, met SASS, gulp and all. | |
| Daarna is het een kwestie van de HTML bestanden van de front-ender in die map te zetten en de juiste namen te geven. Een standaardcontent pagina wordt in wordpress 'page.php' of als je een andere template wil *-page.php. De voorpagina wordt front-page.php et cetera. | |
| We hebben nu een kant en klaar WP thema met enkel nog HTML. Waar de back-ender vervolgens mee aan de slag gaat is die statische data vervangen door data uit WP. Wordpress biedt met WP Query alleen al een bijzonder uitgebreide manier om je 'logica' te scheiden van je HTML. | |
| In functions.php kun je al je logica stoppen. Dit moet je zien als je 'algemene' controller. Hier kun je functies maken die met WP Query of subsets werken (get_users, get_posts, etc). Je stopt al je $args, functionaliteit e.d. in je functies en doet in je templates niks meer als met die functies door de data heen loopen. Gewoon met de HTML die de front-ender voor je heeft geschreven. | |
| Hierdoor krijg je Wordpress websites waarvan in de source niet eens te zien is dat het WP is, krijg je weinig bloat, hoef je geen extra Javascript structuur op te zetten en kan de front-ender doen waar hij goed in is, en de back-ender ook. |
Ik snap je workflow wel hoor, maar waar jij tegen aanloopt, namelijk dat de front-ender vastloopt op zaken in de back-end (WP) komen wij zelden tegen. Uitbreiden doen we door vanuit /raw/ verder te werken en ik verwerk dat in de templates.
Daarnaast kunnen kleine aanpassingen van div namen of classnames e.d. gemakkelijk in de WP templates zelf worden aangepast, doordat we voornamelijk PHP uit de templates houden op de loopjes na, blijven de templates ook voor niet-PHP-ers relatief overzichtelijk.
Doordat we eerst front-end uitwerken komt er tot de back-ender daadwerkelijk om de hoek komt kijken ook geen WP aan te pas.
In jullie geval zal het dan ook prima werken. Als je maar een manier vind om het netjes te verzorgen voor beide partijen. Mijn probleem is een probleem waar je misschien ooit nog tegen aan zal gaan lopen.
Het is vooral gericht op incrementeel en paralel werk, dus niet op de waterval methode.
En ik ben gewoon vooral geen fan van WordPress haha.
Ik denk niet dat het perse bij Wordpress is. Ik heb niet heel veel ervaring met andere CMS-en maar het lijkt me doorgaans bij veel systemen wel werken dat er een bepaalde overlap gaat plaats vinden tussen back- en front-ender.
Ik denk dat veel mensen die Wordpress niet tof vinden maar er wel mee werken nog niet de daadwerkelijke potentie hebben ontdekt. Alles heeft z'n quirks maar ik denk dat je met een beetje PHP kennis en het gebruiken en toepassen van functions.php en de vele bestaande Wordpress functies en filters al snel een mooi overzichtelijke template kan bouwen waar de logica voornamelijk in functions.php gebeurd.
Je begrijpt me inderdaad een beetje verkeerd. Wat mijn probleem is, is precies hoe jullie te werk gaan.
Op het moment dat de front-end "klaar" is met het htmlen van de site gooit hij als het ware zijn stuff over de heg en kijkt er niet meer naar om. Jullie gaan als back-end devs vrolijk bezig met het dynamisch maken van de pagina.
Wat nu als er iets veranderd en de front-ender een uitbreiding / aanpassing moet doen? Gaat hij dan opnieuw zijn source over de heg gooien waarna jullie dat weer copy pasten in de template bestanden?
Het is handiger (archituur en software engineer technisch) om dit werk gescheiden te houden en dat de front-ender zelf de loops en "dynamische" content kan bepalen in zijn templates.
Het ophalen van informatie in je templates is een bad practice en vraagt om problemen bij uitbreiding en aanpassing. Door het voeden van informatie vooraf te laten gebeuren zal de template nooit afhankelijk heden krijgen met het uiteindelijk toegepaste systeem, en dat is wenselijk.
En wat nu als je niet meer voor WordPress kiest de volgende keer? Kunnen de templates dan overgedragen worden? Waarschijnlijk moet je ze in de nieuwe omgeving weer uitwerken naar dat systeem, dat is ook verloren tijd.