WordPress website update theme

Ik heb in onderhoud een website die ik niet zelf gemaakt heb. (https://www.zuiderzeepraktijk.nl)

Op een gegeven moment ben ik zoals elke week, updates aan het uitvoeren.
Ik had een oude back-up bewaard vanaf de dag dat ik de website in onderhoud kreeg en bij wie wordt gehost.
Dus ik had de website overgezet naar "mijn" hosting.

Ik update alle, vooral het theme Divi die aangekocht scheen te zijn.
Maar, er was een child theme aanwezig die geactiveerd is in het dashboard.

Bleek dus na update Divi de boel overhoop te liggen, met missende afbeeldingen, Divi die zich anders gedroeg maar vooral de website zag er niet meer uit zoals bij overname.

Klant helemaal "boos", ik back-up terug gezet maar het rare was dat de website hetzelfde bleef.

Nu heb ik alles zowat gemaakt zoals het was, goedkeuring krijg ik nog hoop ik. Maar er staat nu weer een update klaar voor Divi, maar de vraag is wel duidelijk:
zal ik wel of niet updaten?

En hoe komt het dat wanneer je een child theme gebruikt, dan toch de hele layout anders was geworden?

Ik heb de website niet gemaakt, en dat is wel in mijn nadeel. Maar goed, wat zal ik doen met de update?

Geen idee wat er misging? Maar als je de HTML-broncodes met elkaar vergelijkt zou je toch verbanden moeten gaan zien.

Een nieuwe update kan je proberen. Maak wel even een kopie van je themes.

Je schrijft "op mijn hosting". Antagonist?
Dan kan je na een update terug naar een versie van een paar uur ervoor

@Bron Ik zit niet bij Antagonist. Maar als je op snapshots doelt, dan wordt (denk ik) lastig terugzetten als je op je account ook een productiesite hebt draaien.
Grote kans dat ook de mail terug gaat naar het moment van het maken ervan, evenals de data in de database.

In testomgevingen, of als je echt een hoop vernacheld hebt, dan is het raadzaam. Maar dan moet je echt een grote f*ck up gemaakt hebben door bijv. je public_html weg te gooien, of je rechten op de directory's behoorlijk om zeep te helpen.

Denk vooral aan browsers die onnodig lang cash bijhouden. IK heb al browser gezien waar deze echter 5dagen een css bleef hangen.
Een oplossing is om de developer toolbar even open te zetten, nu sommige browsers gaan anders reageren en minder bij houden en vooral als je naar netwerk gaat en dan reload(om laadtijden te zien).
Nu echter merkte ik een browser op die een svg had geladen deze was met zekerheid verandert en bij netwerk zag ik de nieuwe maar in het browserscherm bleef de oude van enkele minuten geleden te zien.
Dus de file was twee keer verschillend actief in de zelfde browsertab ter info.


Even naast de kwestie maar wel belangerijk er is w p - a d m i n te lezen zonder spaties. Toch even allert zijn dat er automatisch hier kan worden aangevallen.
Echter krijg ik op verschillende websites regelmatig pogingen tot die dir die bij mij niet bestaat.

Als je wil zet ik even een honingpot bij mij om te kijken wat hackers effectief proberen maar dan het ik de html die te zien is bij niet ingelogt even afleveren.

kenikavanbis zei:

Denk vooral aan browsers die onnodig lang cash bijhouden.

Klik om te vergroten...

Je bedoeld cache. Mijn portefeuille houdt mijn cash wel bij me.
Verder is de Developer Toolbar zeker een goed idee, maar let er wel op dat hij de HTML die je op dat moment ziet opnieuw opbouwt, en dat het niet de rauwe HTML is die de browser ontvangt.
Dus als er een hoop interacties gebeuren met de CSS en de HTML, dan zal je die realtime in de developertoolbar zien.

En over Wordpress. Ik draai het ook niet, maar ik krijg wel een hoop /wp-admin requests. Die krijgen gewoon een 404.
Een honingpot kan je opzetten, maar wat bereik je ermee? Alles komt vaak uit botnetjes met miljoenen verschillende IP-adressen vanuit de hele wereld, en het kan geen kwaad.

Grote kans dat ook de mail terug gaat naar het moment van het maken ervan, evenals de data in de database.

Klik om te vergroten...

Hier heb ik 7 bedrijven bij Antagonist zitten, ikzelf (nog) niet.

Bij het terugzetten van automatisch gemaakte backups kan per domein worden aangevinkt: de website bestanden, elk emailadres apart, en elke database apart.

Bij het terugzetten van een handmatig gemaakte backup (via DirectAdmin) kan heel veel worden aangevinkt. Ook kan een handmatige backup worden gedownload en dan werkt het in 5 min in xampp

Ja, DirectAdmin backup kan wel helpen inderdaad. Maar dat gaat wel per entiteiten per domein die je kan instellen. Zoals database, web, mail, etc...
Niet per map voor zover ik weet.

Ontwikkelen doe je liever op een subdomein, of een aparte domein.
Ikzelf heb een www.bla.me.uk domein aangeschaft voor testdoeleinden. De naam vond ik wel grappig bedacht.
Maar bij .tk kan je ook een .ml, en .ga domein gratis aanmaken met DNS koppeling. DNS is wel rottig instelbaar, maar het is iets om mee te testen.
Een .xyz domein is ook wel goedkoop.

Maar nergens in jullie commentaar vind ik het antwoord op mijn vraag.
Hoe kan het dat de website werkt met het child theme van Divi en dat ik dan Divi upload naar de nieuwste versie, dat dan de layout veranderd wordt?
Er staat nu weer een update van Divi klaar, maar ik update hem niet. Straks is weer alles anders en kan ik weer aan de slag.

Ik schreef ook dat ik een back-up had terug gezet en dat die dus ook de boel niet recht trok. Ik snap het dus niet.

Heb je post #2 soms overgeslagen? We hebben geen glazen bol, maar dit is wel een goed advies. Misschien is het een bug in de update?

Heb je dit al met de maker gecommuniceerd?
Want met een child-theme hoort er niks bij een update te 'breken'.

Als de klant boos is, is het tijd voor een OTAP-flow. Ontwikkeling, Test, Acceptatie en Productie.

Om dit beter uit te leggen voor mijn situatie: Ik ontwikkel mijn site op mijn eigen lokale webserver onder een lokaal .test domein. Als alles ontwikkeld en getest is, dan rol ik het uit naar de Acceptatie omgeving die op dezelfde server draait als mijn live site, maar op een gescheiden account. Als alles daar ook goed werkt, dán zet ik het live in productie.

Je klant kan je uiteindelijk alles laten testen in de acceptatie omgeving. Die kan dan nooit boos zijn vanwege een f*ck up.

Het opzetten van zo'n werkomgeving lijkt ingewikkeld en hoeft niet eens complex te zijn. Je kan alles vanuit je testomgeving via (S)FTP naar de Acceptatie omgeving overzetten.

Maar je kan ook als je Pro bent met een versioningsysteem werken en alles binnenladen via Git en de recente Wordpress via Composer. En een script maken om het live te zetten. Ikzelf bouw hier nu scriptjes voor om dit via Linux te doen. Voor het gemak met een keuzemenu in de commandline.

bron zei:

Je schrijft "op mijn hosting". Antagonist?
Dan kan je na een update terug naar een versie van een paar uur ervoor

Klik om te vergroten...

Reseller bij antagonist. Heb daar back-ups staan en ook de back-up van de verhuizing. Dus dat is de originele. Maar zelfs die back-up gaf hetzelfde aan, raar toch?

EN inderdaad, ik had even een subdomein aangemaakt, getest en zo. Dus kloon gemaakt en getest hoe en wat. Maar nu staat er dus weer een back-up voor Divi. Vandaar de vraag.
Ik zal hem nog een klonen en dan die back-up doen.

Nee, antwoord 2 had ik niet gemist.

Testen op een subdomein is niet altijd het prettigst, omdat je vaak in dezelfde webroot zit, en weer met paden moet stoeien.

Of je moet een nieuwe subdomein aanmaken als domein in je webhostingpaneel (DirectAdmin bijv.). Dan heeft je subdomein een eigen webroot.

Dus acceptatie.JOUWDOMEIN.NL als voorbeeld.

Reseller bij antagonist. Heb daar back-ups staan en ook de back-up van de verhuizing. Dus dat is de originele. Maar zelfs die back-up gaf hetzelfde aan, raar toch?

Klik om te vergroten...

Misschien een backup teruggezet die "te recent" was, dus een backup waar al wat rommel in zat?

Testen op een subdomein is niet altijd het prettigst

Klik om te vergroten...

Zelf haal ik (uit gewoonte) een website naar xampp op m'n pc. Dat doe ik door de handmatige backup te downloaden. Daarin zit o.a. de complete map/file structuur en een .sql bestand.
Dan kan je in xampp de hele update testen.

Of je moet een nieuwe subdomein aanmaken als domein in je webhostingpaneel (DirectAdmin bijv.). Dan heeft je subdomein een eigen webroot.

Klik om te vergroten...

Ja, zo doe ik het. Ik zal zoals gezegd, weer de website klonen en dan eens kijken hoe of wat.
Gaat de update goed, kan het ook op de eigen domein.

Prima werkwijze :thumb:

@femke98 mocht je het nog niet gedaan hebben, check ook de bestanden in het child theme. Want afhankelijk wat daar in zit kan dat zeker invloed op de lay-out hebben. Daar kunnen oude Divi thema bestanden in zitten. Of code in functions.php bijvoorbeeld die roet in het eten geeft.
En ook nakijken of php versie xampp/wamp zelfde is als de live server.
Succes! :thumb:

Dank, ik heb de website helemaal up-to-date nu, op de test server.
De klant vind hem in orde, op twee kleine dingen na.

Het is altijd lastig als je een website in onderhoud hebt, en je hebt die website niet zelf gemaakt.
Ik heb mij echt moeten inwerken bij het theme Divi. Ik vind het helemaal niets zoals die gemaakt is, ik hou zelf niet van blokken en vakken etc.
Geef mij maar de "gewone" WP websites

Maar goed, als ik die twee dingetjes hebt veranderd, kan ik hem uploaden naar het werkelijke domein.

Kan ik misschien het beste een schone WP doen en dan de website van de test server overzetten, zodat het vers is?

Zou ik wel doen.

Ja lijkt me wel, alle bestanden verwijderen en database leeg maken. Mooi dat het updaten bij test omgeving is gelukt.

Zou ik ook doen, maar ook weer eerst testen