Na een tijd van rust kwam vanuit de provider de melding dat de site mogelijk gehacked was. Uit veiligheidsoverweging hadden ze de toegang beperkt en de webmaster geinformeerd. Keurig gedaan Alphamegahosting.com. 
Het was dus nodig om hier naar te kijken. In oktober 2017 is Google ook nog eens begonnen met het pushen van http naar https. Nog een reden om de website op schop te nemen. Vanuit de wetgeving moeten persoonsgegevens al langer beveiligd worden, maar in mei 2018 worden de eisen hiervoor aangescherpt. De vorige migratie is alweer van een paar jaar geleden. We hebben gekozen voor de uitdagende route in plaats van de relatief eenvoudige upgrade.Natuurlijk hebben we gekeken naar de eisen en bij de provider een SSL certificaat aangevraagd.
Hiermee hadden we een veilige site, maar deze moest wel even een poosje offline voor het onderstaande plan en onderzoek.
HTTPS voor veilige websites bestaat al veel langer. Ten tijd van de vorige migratie in 2012 zag de wereld er ongeveer zo uit:
Een website met een beveiligd gedeelte had twee mappen met daarin de website. Het meerendeel stond in HTTPDOCS en het beveiligde gedeelte stond in HTTPSDOCS.
Met de brede invoering van de SSL beveiliging kwam ook de wens om migraties inclusief behoud van de SEO ratings. Vandaar het nieuwe beleid om alleen een HTTPDOCS map te gebruiken met alleen een beveiligde aanroep via https://. Via en omzetting (die zo dicht mogelijk bij de DNS server komt te liggen) wordt ieder http:// verzoek omgezet naar een https:// verzoek. Bij de website wordt alleen gereageerd op een https verzoek. Aan de achterkant staat alles in “een map” en dit is normailter de oude httpdocs map.
Pakketten zoals WordPress en Joomla vragen om in te stellen dat ze nu gaan “luisteren” naar https verzoeken.
Binnen WordPress willen we daarnaast afdwingen dat gebruikers in gaan loggen in het kader van de persoonsgegevens bescherming. De blog reacties zetten we daarom ook achter een login:
Hiervoor gaan we naar Instellingen => reacties en zetten vervolgens een vinkje bij ““.
Zoals eerder aangegeven hebben we een uitdagende route gekozen. Bij een nieuwe WordPress installatie wordt uitgegaan van https instellingen als dit wordt opgegeven tijdens installatie. Hierdoor wordt alles keurig in de database opgeslagen zonder http:// verwijzingen. Een oude website heeft echter wel van dergelijke verwijzingen.
De gevolgde route was:
-
- Maak een dump van de bestaande database
- Maak een volledige backup van de website (minimaal root, httpdocs en httpsdocs)
- Installeer een nieuwe versie van WordPress.
(Hierbij forceren om over de bestaande omgeving heen te schrijven maar wel met een ieuwe database) - Maak een dump van de nieuwe database
- Vervang http:// door https:// in het oude dump bestand.
- Zoek op SQL niveau uit welke data uit de oude dump nodig is voor in de nieuwe database
- Verwijder alle overbodige SQL zodat alleen de INSERT nog overblijft.
- Her nummer de keys om overlap met de bestaande nieuwe database records te voorkomen.
Zoek hiervoor even de hoogste waarden in de dump van de nieuwe database. - Gebruik phpMyAdmin of een ander SQL tool en maak verbinding met de nieuwe database.
- Vul de nieuwe database aan met de voorbewerkte INSERT commando’s.
- Test je nieuwe website.
De oude blogs horen nu netjes in beeld te komen achter de “Hello-world” van de installatie. - Pas de nieuwe omgeving aan de verdere wensen aan en zet live.
Het doel van deze route was het in de database oplossen van de http:// verwijzingen en enkele uitdagingen met de verbinding.
De conclusie is als volgt: Volg de normale route voor het omzetten van HTTP naar HTTPS maar overweeg om een SQL script te gebruiken om de verwijzingen in de database eenmalig om te zetten. Hiermee voorkom je het gebruik van een extra plugin om de verwijzing telkens recht te trekken en daardoor de website weer iets trager te maken.