Hoi Wim,
Je stelt als "programma van eisen":
- Ik wil dat mijn vriend de nieuwe site kan testen op dezelfde server terwijl de oude site gewoon nog werkt ...
- ... zonder een volledige kopie van de site te maken,
- ... en zonder dat ik moet uitzoeken wat ik nou allemaal precies had veranderd.
Ik weet het niet 100% zeker, maar het lijkt me dat er wat tegenstrijdige eisen spelen:
Eis 2 betekent dat er alleen de gewijzigde bestanden bij mogen komen, zonder de hele rest te verdubbelen.
Dan moet ofwel:
- Optie A: het bestand in een subdomein of subdirectory geplaatst worden, en kan dan de oude naam houden.
ofwel:
- Optie B: het bestand een andere naam krijgen en kan dan in dezelfde map als het oude bestand geplaatst worden.
=======
Optie A (zelfde naam, andere plaats)
Als een nieuwe/gewijzigde pagina op een andere plek staat, moeten wel alle onveranderde verwijzingen (interne links naar bv. css- en javascriptbestanden, plus gehandhaafd beeldmateriaal) overeind blijven.
Dat kan door ofwel:
- hard coderen van alle interne verwijzingen (bv. <img scr="http://zijnsite.nl/images/logo.png" ... />), ofwel:
- relatieve links gebruiken, maar een <base href="http://zijnsite.nl/..." /> in de <head> toevoegen.
Stel de oude pagina zit hier: zijnsite.nl/paginas/nieuws.htm, en de nieuwe zit hier: zijnsite.nl/test/nieuws.htm, dan moet het worden: <base href="http://zijnsite.nl/paginas/" />.
- Als de nieuwe versie wordt goedgekeurd: in beide gevallen geen probleem. Dan kan de oude pagina overschreven worden door de nieuwe.
- Als de nieuwe versie wordt afgekeurd: ook in beide gevallen geen probleem. Dan kan de nieuwe pagina gewoon gewist worden uit de test-directory.
Maar:
- Complicatie 1: als de nieuwe wordt goedgekeurd en je alles ook nog wilt kunnen terugzetten, mag de oude pagina (in elk geval lokaal) niet gewist worden. Dwz: eerst lokaal opslaan in bv. een mapje "archief" - maar dan moet de oude pagina toch een nieuwe naam krijgen, anders is er geen verschil met een latere gewijzigde versie van dezelfde pagina die er in het archief bij komt.
- Complicatie 2: als het gaat om een afgeleide van een pagina (of: van alle pagina's), dan kan deze methode niet. Stel er komt een wijziging in het css-opmaakmodel (bv. van 3 naar 2 koloms) dan moet een duplicaat-pagina gemaakt worden die verwijst naar een ander css-bestand dan het oude, anders gaat de bestaande site om zeep.
Bij goedkeuring van de nieuwe styles moet dan toch de oude versie gewist worden en die met de nieuwe naam omgedoopt worden in de normale naam (en ook weer gebackupt met een eigen naam).
Hetzelfde geldt voor bv. een vervangende foto op dezelfde pagina.
- Complicatie 3: de complicaties gaan stapelen, als er zowel tekst als css als foto's op een pagina veranderd worden.
Bv. een testpagina met nieuwe kop (die als achtergrond-img via de css wordt aangehaakt). Dan moet zowel het css-bestand een (tijdelijke) andere naam krijgen als de kop-afbeelding, anders gaat het fout door het systeem van de absolute interne links. Bij goedkeuring moeten ze dan alle twee aangepast worden.
Ergo: om het allemaal te kunnen overzien, lijkt me een "boekhouding der wijzigingen" nodig.
Dat is dan in strijd met eis 3: "zonder uitzoeken wat ik nou allemaal precies had veranderd".
=======
Optie B (zelfde plaats, andere naam)
Je verandert een pagina, dwz alleen de tekst in de content > dan kan mijn methode toegepast worden.
Je verandert méér op een pagina, bv. je verandert een "ruimteverslindende foto" > dan moet zowel de nieuwe pagina-versie als de nieuwe foto geupload worden.
- Geen probleem > dan kan mijn methode toegepast worden op de nieuwe pagina (oude paginanaam plus wijzigings-datum), en ook op de nieuwe foto (fotonaam plus dezelfe wijzigings-datum).
- Om de nieuwe pagina te laten werken, moet daarop dus een link naar de nieuwe foto (met datum!) staan.
Vervolgens zijn er twee mogelijkheden:
- Als de nieuwe versie wordt goedgekeurd: oude pagina-bestand moet gewist worden, nieuwe pagina-bestand moet link naar definitieve foto-naam krijgen, en moet herdoopt worden in oude naam. Plus: oude foto-bestand moet gewist worden, nieuwe foto-bestand moet herdoopt worden in oude naam.
- Als de nieuwe versie wordt afgekeurd: nieuwe pagina-bestand moet gewist worden, nieuwe foto-bestand moet gewist worden.
Dit kan nog steeds allemaal.
- Maar ... als je géén volledige kopie van de site hebt na een aanpassing (eis 2), moet je via de Verkenner (of misschien kan dat ook in DW) alle bestanden van een bepaalde datum er uit fietsen; want ze zullen in verschillende mappen staan. En dan stuk voor stuk wissen/omdopen, resp. alleen wissen (als het feest niet door gaat).
- En/of: toch weer een boekhouding.
Dan komt eis 3: onthouden wat er veranderd is. Daar loopt het weer op stuk, want dat gebeurt niet vanzelf.
Conclusie
Ik kom er op uit, dat je of de boekhouding in moet gaan (= handmatige registratie van voorgenomen wijzigingen, met alles er op en er aan), of een schaduwsysteem (dubbele site) moet maken, waarop naar hartelust geëxperimenteerd kan worden.
Een schaduwsysteem zal zowel lokaal als op de server moeten staan.
Een gedeeltelijk schaduwsysteem (bv. voor allerhande javascripts e.d. die niet van essentieel belang zijn voor wijzigingen op een pagina) kan prima om te testen.
Maar dan zit je met het omzetten van een goedgekeurde versie: het gedeeltelijk schaduwsysteem kan je niet gebruiken om in z'n totaliteit de draaiende site te laten vervangen.
Kortom: het ligt niet zo eenvoudig.

Tenzij iemand het handige tooltje weet waar je in je startvraag op doelde!
Alternatief?
Iets heel anders: de site ombouwen en laten draaien op een CMS.
Daarin kan je dan proefpagina's lanceren met bepaalde rechten (alleen na inloggen kan iemand ze zien).
En via een admin-panel kan je even een vinkje zetten: "voor publiceren goedgekeurd" > draaien maar.
Met vriendelijke groet,
CSShunter