overstap van mappenstructuur naar cms

[TromboneFreakus]

Ik ben jaren webmaster van de site www.jubalvarsseveld.nl geweest en houd me hier nu vooral nog wat op de achtergrond mee bezig. Al een hele tijd heb ik het idee dat de website vanwege makkelijker onderhoud eigenlijk in een CMS gegoten zou moeten worden. Dit zodat bijvoorbeeld ook bestuursleden die zaken als FTP en HTML niet snappen, de site ook zouden kunnen bewerken. Op dit moment is het namelijk simpelweg een grote mappen/bestanden-structuur.

Het probleem hierbij is dat de website qua omvang niet zo 1-2-3 even omgezet is. Er zijn vele duizenden interne hyperlinks die dan allemaal overgenomen zouden moet worden. Juist bij gebruik van een CMS wijzigen immers deze hyperlinks vaak.

Nu speelt dit probleem ongetwijfeld vaker. En er zijn ongetwijfeld praktische hulpmiddelen beschikbaar om een dergelijke overstap te vereenvoudigen. Dit is vast per CMS overigens ook weer anders.

Dus mijn vraag is vooral: wie kan op deze afweging vanuit eigen ervaring/de praktijk wat licht laten schijnen en welke voors en tegens zijn er in dit kader?

Alvast bedankt.

[ppx17]

Afhankelijk van hoe logisch je bestandsnamen en hyperlinks zijn kan je met htaccess heel veel verkeer op je oude hyperlinks re-routen. Zo kan je een cms bouwen die daar mee om kan gaan en de juiste (oude) html pagina's uit een database laad en weergeeft. Niet 100% optimaal maar is vrij snel te implementeren.

[benoni]

Stel dat het niet zo logisch is met de oude URL's dan zou je de oude links ook als soort van tags bij de artikelen in het CMS kunnen zetten, zodat je de bijbehorende pagina's met de zoekfunctie van het CMS, of met een simpele SQL lookup voor de dag kunt toveren. Je hebt dan maar één rewrite rule in .htaccess nodig, die de oude link naar een zoekopdracht omzet, van '/hoofdstuk-x/pagina-y.html' naar 'index.php?key=/hoofdstuk-x/pagina-y.html'.

Als de website erg omvangrijk is zou je voor het oververhuizen van de artikelen een script kunnen maken dat alle pagina's van de oude website afloopt, en zo goed mogelijk de content in de database probeert te krijgen.

[TromboneFreakus]

benoni schreef op zondag 29 juni 2008 @ 14:48:
Stel dat het niet zo logisch is met de oude URL's dan zou je de oude links ook als soort van tags bij de artikelen in het CMS kunnen zetten, zodat je de bijbehorende pagina's met de zoekfunctie van het CMS, of met een simpele SQL lookup voor de dag kunt toveren. Je hebt dan maar één rewrite rule in .htaccess nodig, die de oude link naar een zoekopdracht omzet, van '/hoofdstuk-x/pagina-y.html' naar 'index.php?key=/hoofdstuk-x/pagina-y.html'.

In dat geval zou je dus, als ik het goed begrijp, niet eens de hyperlinks zoals ze in de documenten zelf (en na conversie dus in het CMS) staan te veranderen, omdat ook die hyperlinks immers worden opgevangen door dergelijke htaccess rules? Dat zou ideaal zijn, want juist het grote aantal onderlinge hyperlinks is een reden geweest om tot nu toe niet te converteren.

Belast dit gebruik van htaccess echter de server niet heel erg?

Als de website erg omvangrijk is zou je voor het oververhuizen van de artikelen een script kunnen maken dat alle pagina's van de oude website afloopt, en zo goed mogelijk de content in de database probeert te krijgen.

Stappenplan
Als ik het goed begrijp, zou dit leiden tot grofweg dit stappenplan:

1. Installeer een CMS naar keuze
2. Onderzoek de databasestructuur van dat CMS, om te ontdekken hoe artikelen ingevoegd kunnen worden
3. Maak een script dat alle bestanden van de website afloopt dat
   • ... de content van het bestand al nieuw artikel invoegt in het CMS
   • ... een aparte tabel opslaat wat de oude bestandsnaam is en wat de nieuwe URL is (dankzij het CMS)
4. Maak een script (of zoiets??) voor htaccess dat op basis van laatstgenoemde tabel verkeer voor de "oude" URLs, doorstuurt naar de nieuwe URLs
5. Zoek/vervang door de database alle verwijzingen naar oude URLs en vervang deze door nieuwe verwijzingen conform de hyperlinkstructuur van het CMS

Begrijp ik het zo goed?

Vragen rondom stappenplan
Ad 3) Dit zal moeten gebeuren met een script dat op basis van regular expressions zoekt naar alle hyperlinks in een bestand, deze hyperlinks ook weer volgt, in die bestanden dezelfde analyse uitvoert, enzovoort, enzovoort. Toch?

Ad 4) Hoe moet dit? Kan in htaccess naar bijvoorbeeld een PHP-script verwezen worden dat deze verwijzingen verder uitzoekt? Of kan dit in htaccess zelf eenvoudig? Ik zie bijv. hier wel een concrete tip, maar in de comments wordt daar opgemerkt dat dit beter niet in PHP maar beter in htaccess gedaan kan worden.

Ad 5) MySQL ondersteunt geen zoeken/vervangen conform regular expressions toch? Hoe zou je dan alle links kunnen vervangen? De enige keer staat er immers

code:

<a href="../index.php">

en de volgende keer

code:

<a href="../">

De praktijk
Heeft niemand praktijkervaring rondom dit probleem? CMS'en worden immers veel gebruikt, maar vast niet als startpunt voor iedere website. Hoe is de conversie bij jullie gegaan dan?

Alvast heel erg bedankt.

[ Voor 3% gewijzigd door TromboneFreakus op 01-07-2008 19:32 ]

[benoni]

TromboneFreakus schreef op dinsdag 01 juli 2008 @ 19:23:
In dat geval zou je dus, als ik het goed begrijp, niet eens de hyperlinks zoals ze in de documenten zelf (en na conversie dus in het CMS) staan te veranderen, omdat ook die hyperlinks immers worden opgevangen door dergelijke htaccess rules? Dat zou ideaal zijn, want juist het grote aantal onderlinge hyperlinks is een reden geweest om tot nu toe niet te converteren.

Nou, mijn idee was dus om te beginnen met één htaccess rule die alles wat op .htm of .html eindigt herschrijft naar een php pagina met lookup functie. Zit je nog wel met de URLs op submappen (waar index.html is weggelaten), die moet je nog apart afvangen.

Oh, om 'permanent redirects' te genereren zou je link naar de PHP lookup pagina 'intern' moeten rewriten, en die PHP pagina moet dan de lookup doen, en dan een 301 header schrijven met de nieuwe link. Of nog beter: er zit ook een functie in Apache waarmee je de URL voor de rewrite kunt laten samenstellen door een extern script, waarna Apache zelf de 301 header genereert. Kijk even hier in de handleiding onder 'RewriteMap' en dan 'External Rewriting Program'

Belast dit gebruik van htaccess echter de server niet heel erg?

Voorkom ten alle tijde loopende rewrites, want daar is je provider niet blij mee
't Lijkt me verder wel simpel te houden: zo weinig mogelijk rewrite rules, voor de oude URL's één lookup in de database. Minimale belasting lijkt me. 't Kan natuurlijk wat veel tegelijk zijn in 't geval dat er honderd plaatjes in een pagina staan die allemaal tegelijk een rewrite genereren.

Stappenplan
Als ik het goed begrijp, zou dit leiden tot grofweg dit stappenplan...

Een aparte tabel voor de 'nieuwe' URLs lijkt me niet nodig. Je kunt waarschijnlijk de oude URL's wel ergens kwijt in de tabel die voor de artikelen is bedoeld. Daar kun je een SQL lookup op uitvoeren, daarmee heb je het artikel ID te pakken. Als het CMS een functie heeft voor zoekmachinevriendelijke links kun je 's kijken of je het verkregen ID daardoorheen kunt jassen.

Vragen rondom stappenplan
Ad 3) Dit zal moeten gebeuren met een script dat op basis van regular expressions zoekt naar alle hyperlinks in een bestand, deze hyperlinks ook weer volgt, in die bestanden dezelfde analyse uitvoert, enzovoort, enzovoort. Toch?

Voor het importeren van de oude website kun je denk ik het beste gewoon een backup maken naar je eigen computer, en lokaal het script draaien dat de mappen in het filesystem afloopt. Dan weet je zeker dat je alle pagina's hebt, ook als ze niet vanuit de oude menustructuur gelinkt waren.

Je zou in principe, als de rewrite met gekoppelde lookup goed functioneert, de bestaande hyperlinks gewoon moeten kunnen laten staan in de content die je overneemt. Maar het gaat alleen niet werken als het relatieve links zijn, en waarschijnlijk wil je de afbeeldingen ook herorganiseren. Daarvoor moet je inderdaad wel wat greppen en/of later bijwerken. Bovendien denk ik dat de Googlebot het niet waardeert als veel interne links van de website een 301 geven, dus gaandeweg zul je de links toch moeten vernieuwen denk ik. Of je kiest ervoor de oude links permanent te integreren in de nieuwe structuur, zodat je geen 'permanent redirects' hoeft te gebruiken.

Ad 4) Hoe moet dit? Kan in htaccess naar bijvoorbeeld een PHP-script verwezen worden dat deze verwijzingen verder uitzoekt? Of kan dit in htaccess zelf eenvoudig? Ik zie bijv. hier wel een concrete tip, maar in de comments wordt daar opgemerkt dat dit beter niet in PHP maar beter in htaccess gedaan kan worden.

Oh, dat heb ik inmiddels dus al aangehaald, zie hierboven.

Ad 5) MySQL ondersteunt geen zoeken/vervangen conform regular expressions toch? Hoe zou je dan alle links kunnen vervangen? De enige keer staat er immers

code:

<a href="../index.php">

en de volgende keer

code:

<a href="../">

Je kunt grootschalige zoek- en vervang acties met wat handwerk er tussendoor waarschijnlijk makkelijker lokaal doen met een editor (bv. TextWrangler voor de Mac).

Het kan voor een deel vooraf, met de uitgebreide vervang-functie kun je in één keer een grep uitvoeren op alle html-bestanden in een map. Zo kun je 't vast opschonen voordat je 't importeert.

Achteraf kun je de artikelen ook en-masse bijwerken door een SQL dump van die tabel te maken, die lokaal te editten en daarna weer terug uit te voeren op de server. Let wel op eventuele problemen met codetabellen (Latin1, UTF). Of zorg ervoor dat je vooraf met een scriptje of een editor de vreemde tekens in HTML-entiteiten omzet.

[MAX3400]

Eerlijk antwoord: begin zoveel mogelijk opnieuw! Hierdoor leert eenieder die beheer/onderhoud uitvoert het nieuwe systeem kennen, kan je knelpunten uit de oude opzet oplossen en misschien kan er x MB aan data weg en krijg je weer een lean, mean CMS-machien...

[TromboneFreakus]

Allereerst: @Benoni: hartelijk dank voor het uitgebreide antwoord. Ik ga dit nog eens een paar keer rustig doorlezen.

@Max3400: leren kennen van het - nog te kiezen CMS - is uiteraard heel belangrijk. Maar meer dan 2000 bestanden gaan knippen/plakken in het CMS lijkt me wat te veel van het goede. Juist daarom ben ik op zoek naar een slimme wijze van migreren.

Uiteraard is het zaak na die migratie, voor het lanceren van de site, eerst heel veel te gaan werken met het CMS en alles goed te gaan testen e.d.

[MAX3400]

TromboneFreakus schreef op dinsdag 01 juli 2008 @ 21:05:
@Max3400: leren kennen van het - nog te kiezen CMS - is uiteraard heel belangrijk. Maar meer dan 2000 bestanden gaan knippen/plakken in het CMS lijkt me wat te veel van het goede. Juist daarom ben ik op zoek naar een slimme wijze van migreren.

Maar dan zitten we toch een beetje met kip&ei? Je hebt nog geen CMS voor ogen, dus ken jij noch ik de interne datastructuur van dat CMS maar ondertussen wil je wel vast weten hoe je moet migreren?

Je geeft wel terecht aan dat er veel getest en geoefend moet worden: ik denk dat je dan gewoon eens een paar CMS'en (desnoods thuis onder VMWare/VirtualPC) moet testen. Kijken wat je ermee kan. Daarna dat voorstellen als nieuw CMS voor de site en vanaf dat punt verder gaan.

Vooruit kijken is handig maar als de opzet helemaal anders wordt (van mappenstructuur naar een CMS, met bepaalde database/directory/etc), kan je dus imho beter weer kaal en vers beginnen.

*edit*
Dingetje vergeten: de kans dat een CMS de huidige opmaak/file-extensions van je huidige bestanden snapt is "niet al te groot". Dat je dus moet gaan knippen/plakken, zit er wel in...

[ Voor 8% gewijzigd door MAX3400 op 01-07-2008 21:13 ]