8 berichten aan het bekijken - 1 tot 8 (van in totaal 8)
  • Q:

    Bijdrager
    El Pablo 10

    WordPress + GitHub

    Ik zou graag mijn WordPress websites lokaal opzetten en onderhouden, de aanpassingen pushen naar GitHub, om ze vervolgens te pullen op mijn live sites. Maar hoe zet ik dit best op? Hoe houd ik de databases synchroon? Zet ik mijn hele WorPress installatie in Git, of enkel bepaalde mappen (wp-config, …)?

    Als test heb ik nu enkel mijn wp-config in GitHub staan, deze vervolgens gepulled op de server + een database dumb. Nu merk ik bvb dat mijn media files al niet zichtbaar zijn.


    Bijdrager
    koen

    Ik kan het mis hebben, maar werken mediafiles wel goed met git?


    Bijdrager
    computer space

    Wat voor sites zijn het.

    Heb je meer dan 1-3 mensen die content moeten vullen?

    Heb je complexe menustructuren en secties?

    Heb je commentaaropties voor bezoekers?

    Is je content dermate complex dat je WYSIWYG moet editten?

    Zo niet, ditch the bitch. WordPress zeker zelf gehost is een bak bloatware, daar wordt je eng van. Indexhibit?


    Bijdrager
    Shmoo

    Ik denk niet dat Git of GitHub hier een ideale workflow voor is en de reden is vooral omdat ….

     

    1)

    Je WordPress Core-bestanden nooit moet zien als ‘jouw’ bestanden. Daar mag je als het goed is niet aankomen dus die zou je dan ook niet moeten meenemen in je Git commits of backups. WordPress update automatisch /of handmatig, maar die updates komen via het internet binnen en overschrijven dan enkel bepaalde Core-bestanden. Als je al die wijzigingen in Git commits gaat duwen dan is de kans heel groot dat je ooit verkeerde versies terugzet. Niet alleen dat als WordPress niet update via hun gebruikelijke update-script dan loop je de kans dat een database-update niet wordt gedaan omdat jij alleen nieuwe versies van bestandjes online zet maar het update-script niet laat draaien. Soms zijn er WP-updates die eerst je database updaten en daar bepaalde aanpassingen doen en dan pas de bestanden gaan overschrijven. et is dus belangrijk dat updates verlopen die het update-script.

     

    2)

    Je kan er wel voor kiezen om enkel je WordPress Thema en eventueel eigen Plugins in een Git workflow te plaatsen maar dan loop je weer tegen een probleem aan dat WordPress een dynamisch systeem is. Stel jij maakt aanpassingen aan je site dan pas je een aantal bestanden aan. Die push je dan naar GitHub klaar. Mocht je ooit terug willen omdat de feature die je hebt toegevoegd niet werkt dan kun je relatie eenvoudig een comic ongedaan maken en een oudere versie terugzetten. In een ideale wereld werkt dat geweldig maar in jouw WordPress setup heb je ook te maken met het feit dat dankzij jouw feature push naar GitHub er ook instellingen IN je site aangepast worden. Een menu wordt misschien anders ingedeeld, er komt een extra pagina bij of Features producten die getoond moeten worden in dat nieuwe gedeelte broncode dat je hebt toegevoegd. Stel jij maakt die Feature push weer ongedaan, dan zet je wel je oude bestanden terug maar de instellingen IN WordPress en al die pagina’s die zitten in je database en die blijven gewoon bestaan. Kortom dan heb je nog steeds mogelijk conflicten want je menu staat nog op de oude versie en moet je dat weer handmatig terug gaan zetten.

     

    3)

    En automatische deploys richting je traditionele webserver moet je al helemaal niet gaan doen als je zoveel onzekerheden hebt. Mijn advies is vooral blijf vooral vrij statisch je aanpassingen doorvoeren via sFTP. Op die manier zie je namelijk heel goed welke bestanden je gaat overschrijven en heb je zelf de volledige controle over je uitvoering.

     

    4)

    Mediabestanden: Zoals Koen al aangeeft. In Git push je veranderingen A vs B –> C vs A en D is compleet nieuw. … haal je zo’n verandering weer weg dan haal je ook alle bestanden weg die met zo’n verandering gepaard gaan. Zitten daar mediabestanden bij dan verdwijnen deze ook van je site terwijl je die graag wilt behouden. Dit werkt niet zoals sFTP waar je veranderingen kunt doorvoeren en mocht je een van die veranderingen niet fijn vinden dan haal je maar een gedeelte van die verandering weg. Bij een Git workflow zullen ook alle mediabestanden in zo’n commit van je server gehaald worden omdat ze onderdeel zijn van zo’n commit. Zijn deze bestanden dan al ge├»ndexeerd door Google dan heb je dus een probleem.

     

    Ik heb het jaren geleden ooit geprobeerd maar dat was een nachtmerrie. Begin niet aan die onzin. Als Git/GitHub wilt gebruiken i.c.m auto-deploy functies dan zal je met een systeem moeten gaan werken die minder dynamisch en minder afhankelijk van server-side toepassingen is.

     


    Bijdrager
    EagerB0bNerd

    Denk ook dat het weinig zin heeft.  Het werd wel gedaan, met tools als Capistrano, maar dat is ingewikkeld en verouderd. Bedrock zou een moderner alternatief zijn, maar ook dat is gecompliceerd en overkill voor de meeste toepassingen.  Verder moet je Git en allerlei package managers installeren op je server, wat je op shared hosting wel kan vergeten.

    Pushen van veranderingen naar je live of staging server doe je gewoon met je editor. Ik gebruik Coda en hoef alleen maar een vinkje te zetten bij “use publishing” (en de FTP gegevens in te stellen natuurlijk)

    Synchroniseren van je DB doe je met wp-sync-db. Afbeeldingen met WP-sync-db-media. Beide zijn een fork van WP-migrate-db, wat een betaalde plugin is. Deze doet , naast de DB en de media ook plugins.

    Het hoeft allemaal niet zo ingewikkeld te zijn.

     

     


    Bijdrager
    Shmoo

    Is er niet ook een dienst dat Flying Wheel of zoiets heet?

     

    Toen ik WordPress verliet kwam deze dienst online. Het moet een dienst zijn dat helemaal gericht is op snel schakelen tussen lokale en online versies. Dus eenvoudig je online versie op je computer syncen en andersom. Database, thema’s, plugins en de hole shebang.

     


    Bijdrager
    EagerB0bNerd

    Denk dat je Local by Flywheel bedoelt.

    Ik gebruik dat voor al mijn lokale sites. De thema folder van elke site is dan tevens mijn lokale git repo. Ik ben een fan, maar echt snel schakelen tussen lokaal en remote had ik eigenlijk nog niet ontdekt. ┬áZit nu op de site te kijken en ze hebben het wel over “production deployment”. Zal eens kijken.

    //edit:

    dat op magische wijze switchen tussen lokaal en remote is alleen voor de “teams” optie:┬áhttps://getflywheel.com/wordpress-support/how-does-local-for-teams-handle-deployments/

    Verder, flywheel is een hosting  bedrijf (wat Local overgenomen heeft). Het is vooral bedoeld om naadloos te integreren met hun eigen managed WordPress hosting, of om je daarvoor te paaien.

    • Deze reactie is gewijzigd 1 maand geleden door  EagerB0bNerd.

    Bijdrager
    El Pablo 10

    Ok guys, thanks for de inzichten. Dan gaan we het niet ingewikkeld maken en gewoon blijven werken via FTP.

8 berichten aan het bekijken - 1 tot 8 (van in totaal 8)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.