oude / nieuwe site

[G.Scholtens]

Hallo,

Ik ben gevraagd om voor iemand een website te maken in wordpress. Huidige site is aan vernieuwing toe en heb ik zelf ook niet in beheer.

De nieuwe site moet worden gemaakt in wordpress, verzoek van de gebruiker.
Kan ik de nieuwe site het beste locaal maken met instantwp of kan ik de wordpress site ook naaste de huidige site draaien op hetzelfde domein?

[Johnny]

Geen idee hoe het werkt in Wordpress, maar binnen hetzelfde domein is over het algemeen vragen om problemen. Makkelijker is om voor de nieuwe website een subdomein te maken met een eigen document root en database. Op het moment dat de website live kan hoef je enkel wat verwijzingen aan te passen omdat alle bestanden al op de juiste plek staan.

[G.Scholtens]

Zat ik ook al aan te denken om subdomein aan te maken. Maar las dat instantwp makkelijker / beter is omdat je dan alles lokaal hebt. Heb zelf geen ervaring met instantwp

[Gooly]

Als de oude website geen WordPress is, dan kan je het er gewoon naast doen op de server. Als er al wel WordPress staat, dan werk ik zelf altijd locaal.

Uitgaande van het feit dat de oude website geen WordPress is, kan je WordPress in een eigen directory installeren (Dus: www.domein.nl/wordpress) en dan werk je helemaal via die URL, terwijl de oude site ondertussen gewoon bereikbaar blijft via de domein root.

Is je website af, dan kan je de WordPress site gewoon in de domein root publiceren
Kort samengevat: de URL in de settings aanpassen, een regel in de index.php aanpassen en deze naar de domein root kopieëren. (Maar dat staat in bovenstaande link uitgelegd)

[NMe]

Waarom is dit überhaupt een relevante vraag? Je ontwikkelt toch lokaal op je eigen devomgeving en pas als het zaakje af en goedgekeurd gaat het live? Dan kun je de oude site (na een eventuele backup) offline halen en de nieuwe ervoor in de plaats zetten. Waarom zou je in hemelsnaam beide tegelijk op dezelfde live-server willen draaien?

[Gooly]

NMe schreef op woensdag 13 december 2017 @ 13:33:
Waarom is dit überhaupt een relevante vraag? Je ontwikkelt toch lokaal op je eigen devomgeving en pas als het zaakje af en goedgekeurd gaat het live?

Dat is natuurlijk de meest geprefereerde methode. Maar voor sommige kleine projecten die niet veel mogen kosten is het soms een oplossing, omdat je de hele migratie stap over kan slaan. En misschien ligt het aan mij, maar ik kan de migraties die onmiddelijk de eerste keer 100% werkten op de vingers van één hand tellen
Er is altijd wel iets recht te zetten dat is omgevallen is, omdat er toch een verschil zat tussen mijn dev en de live omgeving van de klant.

[NMe]

Gooly schreef op woensdag 13 december 2017 @ 13:39:
[...]

Dat is natuurlijk de meest geprefereerde methode. Maar voor sommige kleine projecten die niet veel mogen kosten is het soms een oplossing, omdat je de hele migratie stap over kan slaan. En misschien ligt het aan mij, maar ik kan de migraties die onmiddelijk de eerste keer 100% werkten op de vingers van één hand tellen

Dat is juist de reden om het eerst lokaal te doen zodat je zeker weet dat de migratie goed gaat.

[Stoelpoot]

NMe schreef op woensdag 13 december 2017 @ 13:33:
Waarom is dit überhaupt een relevante vraag? Je ontwikkelt toch lokaal op je eigen devomgeving en pas als het zaakje af en goedgekeurd gaat het live? Dan kun je de oude site (na een eventuele backup) offline halen en de nieuwe ervoor in de plaats zetten. Waarom zou je in hemelsnaam beide tegelijk op dezelfde live-server willen draaien?

Niet als je richting een Scrum-workflow gaat waarbij de klant elke x weken op- en aanmerkingen kan geven. Anders kom je in zo'n 'what the customer expected'-situatie.

[Gooly]

NMe schreef op woensdag 13 december 2017 @ 13:42:
[...]

Dat is juist de reden om het eerst lokaal te doen zodat je zeker weet dat de migratie goed gaat.

Misschien wel op een uitgebreid dev platform. Maar dat van mij is niet veel meer dan een Ubuntu server op Virtual Box, met twee PHP- en één database versie en GIT (Waarmee ik alles naar Bitbucket push) en dan stuit ik regelmatig op dingen die op het uiteindelijke platform net niet-, of even anders werken. En dan werkt het voor de migratie dus vloeiend en naadloos op mijn devje.

[NMe]

Stoelpoot schreef op woensdag 13 december 2017 @ 13:47:
[...]

Niet als je richting een Scrum-workflow gaat waarbij de klant elke x weken op- en aanmerkingen kan geven. Anders kom je in zo'n 'what the customer expected'-situatie.

Ook dat hoor je gewoon op een aparte testing/staging-omgeving te doen die los staat van development maar zéker ook los staat van live.

Gooly schreef op woensdag 13 december 2017 @ 13:50:
[...]

Misschien wel op een uitgebreid dev platform. Maar dat van mij is niet veel meer dan een Ubuntu server op Virtual Box, met twee PHP- en één database versie en GIT (Waarmee ik alles naar Bitbucket push) en dan stuit ik regelmatig op dingen die op het uiteindelijke platform net niet-, of even anders werken. En dan werkt het voor de migratie dus vloeiend en naadloos op mijn devje.

Dat is nog steeds beter dan het de eerste keer dat je het doet meteen op live werken en met gekruiste vingers hopen dat het goed gaat...

[Verwijderd]

NMe schreef op woensdag 13 december 2017 @ 13:42:
[...]

Dat is juist de reden om het eerst lokaal te doen zodat je zeker weet dat de migratie goed gaat.

Zo lastig is dat niet hoor.

Je kunt wordpress prima in een subfolder plaatsen op hetzelfde domein, bijv /test/

Hier werk je de nieuwe website in samenspraak met je klant in uit, en als deze gereed is, dus ook alle pagina's van oude site hebt overgenomen, eventueele 301's hebt ingesteld, extract je de database eerst uit /phpmyadmin. Hier doe je een find & replace op o.a /test/ naar / en upload je er terug in.

De bestanden verplaats je vervolgens naar / en moet alles werken als het goed is. Ik migreer op wekelijkse basis websites voor klanten waaronder ook wordpress. Het lokaal uitwerken is niet echt een idee omdat je klant ook wil zien wat je aan het doen bent.

Wordpress doet alles zo goed als via de database, tenzij je plugins met configs gebruikt die alles hardcoded in een config bestandje opslaan, zoals bijv de verwijzing naar /test/wp-content/plugins/benodigd.php etc.

[Gooly]

NMe schreef op woensdag 13 december 2017 @ 13:54:
[...]

Dat is nog steeds beter dan het de eerste keer dat je het doet meteen op live werken en met gekruiste vingers hopen dat het goed gaat...

Nou ja, ik moet toegeven dat developen op een live server inderdaad risico's met zich mee kan brengen.
*Herinnerd zich die keer dat hij een (virtuele) webserver down bracht waardoor ook de oude website niet meer te bereiken viel*

[NMe]

Verwijderd schreef op woensdag 13 december 2017 @ 13:58:
[...]

Zo lastig is dat niet hoor.

Het gaat er niet om of het lastig is, het gaat erom dat het risico's met zich meebrengt als je ontwikkelt op een liveserver.

[Gooly]

Verwijderd schreef op woensdag 13 december 2017 @ 13:58:
[...]

Zo lastig is dat niet hoor.
Je kunt wordpress prima in een subfolder plaatsen op hetzelfde domein, bijv /test/
[...]
De bestanden verplaats je vervolgens naar / en moet alles werken als het goed is. Ik migreer op wekelijkse basis websites voor klanten waaronder ook wordpress. Het lokaal uitwerken is niet echt een idee omdat je klant ook wil zien wat je aan het doen bent.

En zelfs het verplaatsen van bestanden en aanpassen van de database is dus niet nodig
Alleen een setting in de backend, en de index.php (en eventueel .htaccess) verplaatsen volstaan
https://codex.wordpress.o...rdPress_Its_Own_Directory

[Verwijderd]

NMe schreef op woensdag 13 december 2017 @ 14:02:
[...]

Het gaat er niet om of het lastig is, het gaat erom dat het risico's met zich meebrengt als je ontwikkelt op een liveserver.

Zoals? Dat de migratie mogelijk niet volledig lukt? Je moet niet crosslink bestanden door elkaar heen gaan plaatsen nee zoals de vorige website in dezelfde map als waarin je wordpress gaat plaatsen. Maar dat spreekt voor zich. Testen / uitwerken doe ik nooit lokaal. Het is altijd op domein of subdomein daarvan. De klant wil inzage zien in wat je doet. Dat gaat niet lokaal.

[XyritZz]

Je hebt de oude site niet in beheer, dus met andere woorden als je per ongeluk iets sloopt heb je geen parate kennis van de omgeving hoe het te repareren.

Daarnaast heb je ook geen kennis van de staat van onderhoud aan de huidige site. Als die site niet goed onderhouden is en dus oude versies draait is de kans levensgroot dat de omgeving waar de site op draait compromised is.

Alleen om die redenen al zou ik de nieuwe site ook op een nieuwe omgeving opleveren. Ontwikkelen lokaal, op nieuwe omgeving plaatsen met htaccess er voor o.i.d. en zodra de klant zegt dat het live mag htaccess er af en DNS omzetten.

Oude omgeving waar je niet op kunt vertrouwen kan dan gewoon vernietigd worden.

[NMe]

Verwijderd schreef op woensdag 13 december 2017 @ 14:08:
[...]

Zoals?

Dat je de server onderuit trekt omdat bijvoorbeeld een plugin in je nieuwe site niet lekker werkt? Dat je mogelijk dingen zichtbaar maakt die niet zichtbaar horen zijn en dus hackers een extra ingang geeft? Dat je vervolgens zélf waarschijnlijk ook geen XDebug kan gebruiken? Developen op een liveserver is gewoon dom. Je developt lokaal op een server die zo veel mogelijk lijkt op de liveserver. Pas als alles doorgetest is door de eigen organisatie gaat het richting klant voor acceptatie, en dát zou eventueel op de productieserver (maar in een aparte omgeving op een apart (sub)domein!) kunnen.

De klant wil inzage zien in wat je doet. Dat gaat niet lokaal.

Daarom: Wikipedia: OTAP. Waarbij je voor simpele trajecten de T uit OTAP in de O kan combineren.

[Verwijderd]

NMe schreef op woensdag 13 december 2017 @ 14:15:
[...]

Dat je de server onderuit trekt omdat bijvoorbeeld een plugin in je nieuwe site niet lekker werkt? Dat je mogelijk dingen zichtbaar maakt die niet zichtbaar horen zijn en dus hackers een extra ingang geeft? Dat je vervolgens zélf waarschijnlijk ook geen XDebug kan gebruiken? Developen op een liveserver is gewoon dom. Je developt lokaal op een server die zo veel mogelijk lijkt op de liveserver. Pas als alles doorgetest is door de eigen organisatie gaat het richting klant voor acceptatie, en dát zou eventueel op de productieserver (maar in een aparte omgeving op een apart (sub)domein!) kunnen.

[...]

Daarom: Wikipedia: OTAP. Waarbij je voor simpele trajecten de T uit OTAP in de O kan combineren.

Slechte server dan als 1 wordpress installatie deze om wat voor een reden dan ook onderuit kan halen. Ik doe dit al 8 jaar en heb nog nooit een server zien crashen omwille een wordpress site. Het hackers valt ook wel mee tegenwoordig. Het is eerder allemaal geautomatiseerd zoeken naar exploits vs de echt skilled hackers die actief de tijd nemen je site uit te zoeken.

Ik ben geen voorstander van wordpress uberhaubt maar de klant wil wat eenvoudigs. Dus leveren we dat.

[G.Scholtens]

Wat een reactie opeens, maar zal hem eerst lokaal kan maken. Als alles gereed is en klant akkoord heeft gegeven. Alles uploaden en de oude verwijderen.

[Paradox]

tipje.. oude backuppen/renamen .. kijken of alles werkt dan verwijderen.

[NMe]

Verwijderd schreef op woensdag 13 december 2017 @ 14:20:
[...]

Slechte server dan als 1 wordpress installatie deze om wat voor een reden dan ook onderuit kan halen. Ik doe dit al 8 jaar en heb nog nooit een server zien crashen omwille een wordpress site.

Het gaat er niet om dat het een WP-site is, het gaat er om dat je tijdens het developen nogal eens dingen moet uitproberen. Het zou zeker niet de eerste keer zijn dat ik op onze devserver een proces moet killen omdat ik een foutje heb gemaakt waardoor de server traag wordt. Dat wil je gewoon niet veroorzaken op een productieserver.

Dat jij het blijkbaar al 8 jaar doet, doet daar niet aan af. Er zijn ook vast mensen die al 8 jaar elke straat oversteken zonder eerst naar links en rechts te kijken en die nog nooit aangereden zijn, maar dat maakt het nog steeds geen goed idee.

[Verwijderd]

NMe schreef op woensdag 13 december 2017 @ 14:23:
[...]

Het gaat er niet om dat het een WP-site is, het gaat er om dat je tijdens het developen nogal eens dingen moet uitproberen. Het zou zeker niet de eerste keer zijn dat ik op onze devserver een proces moet killen omdat ik een foutje heb gemaakt waardoor de server traag wordt. Dat wil je gewoon niet veroorzaken op een productieserver.

Dat jij het blijkbaar al 8 jaar doet, doet daar niet aan af. Er zijn ook vast mensen die al 8 jaar elke straat oversteken zonder eerst naar links en rechts te kijken en die nog nooit aangereden zijn, maar dat maakt het nog steeds geen goed idee.

Dan zou ik eerder de configuratie van je devserver eens nader inzien. Ik werk met virtueele servers en als daarin een proces langer dan 120 seconden de boel loopt te hoggen dan is het autokill. En dan nog zijn de toegewezen resources per gebruiker gewoon limited dus zoveel kan er niet misgaan al zouden er 10 threads in de soep lopen

[Hiroj]

NMe schreef op woensdag 13 december 2017 @ 14:15:
Daarom: Wikipedia: OTAP. Waarbij je voor simpele trajecten de T uit OTAP in de O kan combineren.

Meeste WordPress ontwikkelaars gebruiken geen OTAP straatje tijdens hun project(en).
Zonde in mijn opinie, maar hey als het voor hun werkt...

ontopic:
Download en installeer een XAMPP / MAMP / ander alternatief, waardoor je lokaal je ontwikkeling kan uitvoeren. Zodra de klant helemaal akkoord is met wat jij voor hen hebt gebouwd, kun je dat prima in zijn geheel publiceren op zijn website met een fresh install

[TeraMod]

Verwijderd schreef op woensdag 13 december 2017 @ 14:37:
[...]


Dan zou ik eerder de configuratie van je devserver eens nader inzien. Ik werk met virtueele servers en als daarin een proces langer dan 120 seconden de boel loopt te hoggen dan is het autokill. En dan nog zijn de toegewezen resources per gebruiker gewoon limited dus zoveel kan er niet misgaan al zouden er 10 threads in de soep lopen

Dat zijn dan wel 120 seconden dat ook de live website traag/trager of niet reageert.

[DJMaze]

G.Scholtens schreef op woensdag 13 december 2017 @ 14:22:
Als alles gereed is en klant akkoord heeft gegeven. Alles uploaden en de oude verwijderen.

Dan wens ik je veel succes met het zoeken in deze forums en Google.
Oh wee je gebeente als je een nieuw topic start dat al 1.000.000.000x is beantwoord op het grote internet.
WordPress zet je namelijk niet even live.

Hiroj schreef op woensdag 13 december 2017 @ 15:04:
Meeste WordPress ontwikkelaars gebruiken geen OTAP straatje tijdens hun project(en).
Zonde in mijn opinie, maar hey als het voor hun werkt...

Dat komt omdat OTAP niet goed werkt in WordPress.

Gavin Anderegg https://wordpress.stackexchange.com/a/53325
The database issue

Finally, the meat of the matter.

What I had to accept is, when using WordPress, there's no good way to "merge" database changes. Instead, we needed to develop rules of conduct to solve this.

offtopic:
Waarom je iets maakt in WordPress is ook totaal onzin. Je mag luisteren naar de wensen van de klant, maar in zo'n geval raad ik altijd direct aan om NIET de website in WordPress te maken.

[ Voor 39% gewijzigd door DJMaze op 13-12-2017 17:05 ]

[Ed Vertijsment]

DJMaze schreef op woensdag 13 december 2017 @ 15:25:
Dat komt omdat OTAP niet goed werkt in WordPress.

Ik lees dit topic on the side en doe al jaren niets meer in WordPress maar hoe zou zou OTAP niet werken in WordPress? Het is niet een een of andere spec die ondersteunt moet worden.

Simpel, bouwen doe je lokaal, opleveren op een staging, en na acceptatie draaien op productie. En dan laat ik voor het gemak testen even weg. Bij voorkeur dit alles ook nog miet iets als git flow.

Dit heeft IMO niets met WordPress/ maar puur met je workflow, zoals eerder al gepost is, is het gewoon niet handig om onbekende productie (!) omgeving te gaan gebruiken voor de nieuwe omgeving, laat staan voor development.

Het inrichten van deze omgevingen hoeft echt niet moeilijk/tijdrovend te zijn. Gewoon een paar vm'etjes cloudboxjes of whatever aanslingeren.

Bottom line, nooit devven op een productie box.

[ Voor 5% gewijzigd door Ed Vertijsment op 13-12-2017 19:32 ]

[DJMaze]

Ed Vertijsment schreef op woensdag 13 december 2017 @ 19:29:
maar hoe zou zou OTAP niet werken in WordPress?

Dat stond in mijn post, maar goed hier nog maals ff "The database issue" lezen: https://wordpress.stackexchange.com/a/53325

[ Voor 4% gewijzigd door DJMaze op 13-12-2017 22:44 ]

[Ed Vertijsment]

DJMaze schreef op woensdag 13 december 2017 @ 22:42:
[...]

Dat stond in mijn post, maar goed hier nog maals ff "The database issue" lezen: https://wordpress.stackexchange.com/a/53325

Ik zog steeds geen goede reden om niet aan OTAP, te doen, dat WordPress de taak als DBA niet van je wegneemt betekent niet dat je niet meer een losse productie omgeving kun hebben. Er zijn hier prima oplossingen voor te vinden, zoals in de post gewoon simpelweg afspraken maken.

Instead, we needed to develop rules of conduct to solve this. The rules are fairly simple, and have served us well so far.

Misschien ben ik bevooroordeeld omdat ik veelal met een systeem werkt die wel in migraties voorziet (Django) maar ik heb daarvoor ook gewoon schema/datamigraties uitgetikt in sql en meegecommit per review. Werkte ook prima.

Ik blijf er bij, blijf met je fikken van productie af. De enige code productie draait is je master branch. Staging/preproductie draait develop en lokaal maak je branches daarvan die weer teruggaan naar develop. Akkoord? Dan pas develop naar master.

[Verwijderd]

TeraMod schreef op woensdag 13 december 2017 @ 15:04:
[...]

Dat zijn dan wel 120 seconden dat ook de live website traag/trager of niet reageert.

Onzin dit ...

Webservers zijn niet meer van 1999 waarbij 1 thread een hele server kon doen crashen of vast laten lopen. Ja het kan wel maar binnen een virtual omgeving en met cap op resources is dat zo goed als onmogelijk.

Al lopen 10 threads vast, de server zal gewoon blijven draaien. De behorende user in waarin het draait zal wel grotendeels vastlopen waarop niets meer hierbinnen werkt. Maar het systeem zelf blijft gewoon draaien.

[borft]

Tis geen onzin

Sowieso, testen en ontwikkelen doe je niet op je productieomgeving, dat is echt bad practice.

@TS houd er rekening mee dat Wordpress hard coded paden/URL's in de database zet. Je kunt dus niet even simpel een dumpje van je dev omgeving naar productie copieren en verwachten dat het werkt. Een find/replace op een db dump werkt ook niet goed, omdat er ook serialized waardes in de DB staan, en die gaan dan stuk als mv het aantal tekens na de find/replace niet hetzelfde is.

[Verwijderd]

borft schreef op donderdag 14 december 2017 @ 15:18:
Tis geen onzin

Sowieso, testen en ontwikkelen doe je niet op je productieomgeving, dat is echt bad practice.

@TS houd er rekening mee dat Wordpress hard coded paden/URL's in de database zet. Je kunt dus niet even simpel een dumpje van je dev omgeving naar productie copieren en verwachten dat het werkt. Een find/replace op een db dump werkt ook niet goed, omdat er ook serialized waardes in de DB staan, en die gaan dan stuk als mv het aantal tekens na de find/replace niet hetzelfde is.

Ik doe dit bijna wekelijks, en echt, op een find & replace de boel niet werkend te krijgen is heel erg knap. Het enige waar je wel rekening mee moet houden is dat bepaalde thema's zoals Avada stukgaan na een Find & replace via de DB, en zoals je bovenstaande stelling dan aan de hand is. Maar dat is heel eenvoudig > Avada > Theme settings > Export. En op je live omgeving importeer je de boel weer en klaar.

Zo lastig is het niet.

[borft]

@Verwijderd het feit dat het bij jou werkt is natuurlijk geen garantie dat het altijd werkt. Overigens relaxt dat het in jouw geval wel werkt, ik heb andere ervaringen.

Zodra er serialized strings in je export staan, en je doet daar een find & replace op, dan gaan die zeer waarschijnlijk stuk. Het is dan aan WP of de desbetreffende plugin om daarmee om te gaan. In mijn ervaring reset Wordpress alle waardes dan naar een default, die vaak gewoon een lege string is, niet heel ideaal.

De export functie zou dit moeten oplossen, maar dat werkt alleen als al je plugins dat goed ondersteunen. Ik heb het uiteindelijk opgelost door een script te schrijven dat door de hele db heenfietst en de find & replace doet na de import. Als iets een string is, doe ik gewoon een find & replace. Als het iets geserialized is, dan unserialize ik eerst, en dan daarna de find & replace.

[DJMaze]

Ed Vertijsment schreef op donderdag 14 december 2017 @ 13:49:
Ik blijf er bij, blijf met je fikken van productie af. De enige code productie draait is je master branch. Staging/preproductie draait develop en lokaal maak je branches daarvan die weer teruggaan naar develop. Akkoord? Dan pas develop naar master.

Hier geef ik je 100% gelijk in hoor.

Het database probleem is alleen complexer dan je denkt.
Je kan bijvoorbeeld niet zomaaar in een development omgeving met meerdere mensen werken met de zelfde database omdat WordPress de volledige domeinnaam overal opslaat.
Nu kan je dit oplossen door je dns/hosts file aan te passen dat dev.example.com verwijst naar 127.0.0.1 en dan bij live gaan "dev.example.com" vervangen in "www.example.com".
So far so good.

Dan probleem twee: op de live website zijn comments en nieuwe artikelen geplaatst met post id's: 101, 102, 103
Nu heb jij op je ontwikkelomgeving een webshop toegevoegd en nieuwe producten/posts met id's: 101, 102, 103
Dat ga je niet zomaar migreren.
Je moet dus zorgen dat de auto_increment waarde bijvoorbeeld bij 200 begint zodat je wat ruimte krijgt en de id's worden opgeslagen als: 201, 202, 203

Etc. etc. etc. en dat maakt WordPress best onhandig en tijdrovend omdat je met zaken rekening moet houden die in andere systemen gewoon beter geregeld zijn.

[Dark Blue]

So far ben ik het unaniem eens met: niet ontwikkelen op je live omgeving!

Maar je kunt wel even een kijkje nemen in je database daar. WP tabellen herken je zo.
Prefix je eigen anders, lokaal, dan zit je elkaar nooit in de weg.

Dit, en alles wat hiervoor gezegd is.

En, er zijn meer CMS'sen op de wereld dan WP alleen.
Dat het platform misschien 20 huismoeders heeft die het moeten snappen, betekent niet dat ze het met een klein beetje leren in een beter onderhoudbaar CMS niet snappen. Leren ze wel, jij minder zorgen.

[Verwijderd]

Iets nieuws, zou ook kunnen betekenen dat je een nieuwe db aanwijst.
ik werk niet met wordpress, maar waar ik werk, hebben we een lokale database, test database en productie database.

Daarnaast moet je een test server / staging server opzetten die bijna matched met de live omgeving, dit zou op de productie server kunnen zijn met bijvoorbeeld test.domein.nl
en ik zou op je productie server geen master branch draaien maar een release branch (blijft ie mooi steken tot je een nieuwe release hebt uitgechecked).

[Ed Vertijsment]

Verwijderd schreef op maandag 1 januari 2018 @ 22:01:
Iets nieuws, zou ook kunnen betekenen dat je een nieuwe db aanwijst.
ik werk niet met wordpress, maar waar ik werk, hebben we een lokale database, test database en productie database.

Daarnaast moet je een test server / staging server opzetten die bijna matched met de live omgeving, dit zou op de productie server kunnen zijn met bijvoorbeeld test.domein.nl

Dit zou ik niet doen, als je net een virtualhost heb aangemaakt en niet helemaal goed gegaan is (configuratie error) ligt productie eruit. Voor een paar euro per maand (extra op de factuur) heb je ergens een VPS'je om op te testen. Bouw je gelijk deployment scripts met iets als Ansible dan kun je gewoon nieuwe omgevingen blijven uitspugen. Geen reden om productie aan te raken dus.

Verwijderd schreef op maandag 1 januari 2018 @ 22:01:
en ik zou op je productie server geen master branch draaien maar een release branch (blijft ie mooi steken tot je een nieuwe release hebt uitgechecked).

Ook goed, zolang je maar onderscheid kunt maken in welke code opgeleverd is en welke zich in een ander stadium bevind. Of je dat nu master, production, release, of live noemt maakt niet zo veel uit. Overigens zou je hier ook tags voor kunnen gebruiken.