Archief - Custom WordPress workflow met SASS en GIT

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Fonskuh

Legacy Member
Hi iedereen,

Ik maak al een 6-tal jaar custom WordPress websites maar door het teveel aan werk ben ik lang wat vast blijven zitten in mijn eigen workflow en framework. Deze maand eindelijk tijd gehad om een aantal zaken te leren die ik veel te lang uitgesteld heb, waaronder SASS en GIT. Nu ben ik die in mijn workflow aan het implementeren maar enkele details zijn mij niet echt duidelijk.

Momenteel bouw ik altijd de front-end op basis van het design uit en integreer die nadien in WordPress zodat alles flexibel kan gekoppeld worden. Ik heb dus altijd een aparte front-end eerst vooraleer ik die koppel. Nu begin ik in te zien dat dit eigenlijk niet te combineren valt met versiecontrole. Vandaar dus mijn vragen:

- Is het niet beter om de front-end meteen als een WordPress theme op te bouwen, dus includief de functions, PHP templates, page templates,... ipv apart? Op deze manier doe ik geen dubbel werk en is er dus altijd een versiecontrole over het volledige thema.
- Maken de SASS files en directories deel uit van het WordPress theme? Dus zitten die gewoon in de theme folder zelf of is het beter een dist versie te hebben met enkel de build files?

Hopelijk kan iemand hier wat inzicht in geven!

Thanks!

Fransz

Legacy Member
Wat als de klant niet akkoord gaat met het design? In Photoshop kan je altijd eerst kort op de bal spelen. Om het nadien pas te coderen en te integreren in Wordpress. Neen?

Fonskuh

Legacy Member
Ik ontwikkel pas als design goedgekeurd is hoor, het gaat mij eerder om de effectieve workflow nadien. :)

Nu zie ik front-end en back-end als aparte entiteiten waarbij ik front-end eerst ontwikkel en dan pas koppel aan de back-end, maar het lijkt logisch om meteen te starten met het theme en daarin rechtstreeks de front-end en back-end simultaan op te zetten. Op die manier heb ik mijn GIT versiecontrole correct draaien in het thema en kan ik alle SASS files daarin structureren. Dan is het een kwestie van lokaal ofwel Gulp te laten draaien ofwel Codekit en MAMP samen, dan is alles één geheel.

Shaddix

Legacy Member
Meteen op Wordpress zelf developen vind ik wel het beste ja.

Mijn huidige structuur ziet er zo uit:

- public (met de wordpress installatie in)
- theme (met al mijn SCSS, Javascript, ...)
gulpfile.js (config van Gulp die alles gaat compileren).

Ik gebruik daarnaast ook Scotchbox als Vagrant setup. En Timber om mijn theme mee op te bouwen, dat is een library/plugin die u helpt om in Twig uw theme op te zetten wat resulteert in een veel properdere setup.

Greenie

Legacy Member
Fonskuh zei:
Ik ontwikkel pas als design goedgekeurd is hoor, het gaat mij eerder om de effectieve workflow nadien. :)

Nu zie ik front-end en back-end als aparte entiteiten waarbij ik front-end eerst ontwikkel en dan pas koppel aan de back-end, maar het lijkt logisch om meteen te starten met het theme en daarin rechtstreeks de front-end en back-end simultaan op te zetten. Op die manier heb ik mijn GIT versiecontrole correct draaien in het thema en kan ik alle SASS files daarin structureren. Dan is het een kwestie van lokaal ofwel Gulp te laten draaien ofwel Codekit en MAMP samen, dan is alles één geheel.
disclaimer: geen wordpress developer, maar werk wel dagelijks met git. (ik hoop dut dat dit lokaal git is op je PC en niet in een of andere website waar men het verpakt als git)

Versie controle is bovenal een tool he.
Als je huidige werkflow werkt met je klanten hoef je die niet persé om te gooien.
Een werkende website met een mockup backend hoeft onmiddelijk slecht te zijn.

Je moet je bv afvragen wat het nut zou zijn van een werkende versie met zowel back-end als front-end op een design die niet goedgekeurd is.
Gaat het je flow verbeteren door beiden al half klaar te hebben ?

Je kan nog altijd kiezen of je front-end en back-end apart in git steekt of samen.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan