Wie sollte ich ein WP-Website-Projekt mit Git strukturieren und über das WP-Dashboard aktualisieren?

13

Seit Monaten versuche ich, eine gute Projektstruktur für die Verwendung der Git-Versionskontrolle für die Entwicklung von WordPress-Websites zu entwickeln, die nicht die Möglichkeit einbüßt, Kern- und Plug-ins über das WP-Dashboard zu aktualisieren, und keine unkonventionelle Verzeichnisstruktur (wp -inhalt außerhalb des übergeordneten WP-Ordners) und das ist einfach zu verwalten und ganze Websites bereitzustellen. Ich habe über Submodule, Teilbäume, verschachtelte Repos usw. gelesen und es fällt mir immer noch schwer, alles zusammenzufügen und die richtige Strategie zu wählen.

Hier ist, was ich gerade denke, mit meinen Gedanken darüber, wie ich mit Git-Repos in Klammern umgehen würde.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Dies lässt mich mit mehreren Problemen / Fragen zurück;

  • Automatische Updates; Ich mag die neue Funktion für automatische Updates. Sie könnte möglicherweise viel Zeit und Mühe sparen, um meine Websites auf dem neuesten Stand zu halten und sicher zu halten, aber es scheint, als würde sie das Nachverfolgen von Codeänderungen mit git erleichtern. Gibt es eine Möglichkeit, meine Codeänderungen zu verfolgen, während WordPress Core weiterhin automatisch aktualisiert wird?

  • Verhindert das Vorhandensein von Teilbäumen unter dem WordPress-Core-Repo, dass ich git verwende, um neue Core-Updates einzufügen, oder das Zurückschreiben meiner Änderungen in den WordPress-Core-Repo (falls ich jemals entscheiden würde, ein Core-Mitarbeiter zu werden)?

  • Bei Plugins ohne öffentliches Git-Repo führt das vollständige Ignorieren dazu, dass die gesamte Site auf einem neuen Server nicht schnell geklont werden kann, ohne dass Dateien manuell auf den Server kopiert werden müssen. Es verursacht auch ein Problem, wenn ich den Code dieses Plugins ändern möchte. Diese Änderungen werden nicht nachverfolgt und können bei einem Plugin-Upgrade leicht verloren gehen.

Zusammenfassend lässt sich sagen, was ist ein gutes git + WordPress-Setup, das diese Probleme vermeidet? Ich würde mich über Ihr Feedback zu meiner vorgeschlagenen Projektstruktur freuen. Jede Art und Weise, wie Sie mir helfen können, dies zu verbessern, wäre sehr dankbar!

PS, wenn es ein besseres Forum für diese Diskussion gibt, weisen Sie mich bitte dorthin.

updates automatic-updates git Josiah Sprague
quelle

Antworten:

6

Aus meiner Sicht gibt es zwei Probleme mit Ihrem Plan - Git und "konventionelle" Struktur. Also im Grunde alles. :)

  1. Git (und die Versionskontrolle im Allgemeinen) ist ein schlechtes Tool für ganze Site-Stacks. Warst du dort, hast du das getan, es tat sehr weh.

  2. Was Sie eine "unkonventionelle" Struktur nennen, deren Inhalt vom Kern getrennt ist, war für eine Weile eine sehr konventionelle und robuste Wahl für jede ernsthafte Site.

  3. Es gibt so gut wie keine schlüsselfertigen Möglichkeiten, den gesamten Site-Stack mit nativen Updates zu kombinieren. Das passt einfach nicht zusammen, da versucht wird, unterschiedliche Ziele in Projekten auf unterschiedlichen Ebenen zu erreichen (Entwickler unter Kontrolle vs. Endbenutzer unter Kontrolle).

Wenn Sie mich fragen, ob der beste Weg für den gesamten WordPress-Stapel der Website derzeit Composer ist , können die Meinungen jedoch vorsichtig sein. :)

Zu Ihren speziellen Anliegen:

  1. Wie oben - native Updates (eher automatische Updates) eignen sich nicht für streng kontrollierte Stacks.

  2. Der WordPress-Kern ist nicht in Git entwickelt und akzeptiert keine Pull-Anfragen. Alle Beiträge erfolgen (bisher) über Patch-Dateien an Subversion.

  3. Sie werden wahrscheinlich solche Plugins in Ihr Repo einspielen müssen. Oder gehen Sie mit einem anderen Ansatz wie Composer.

Rarst
quelle
WordPress verwendet Git nicht für die Entwicklung, aber es gibt einen Spiegel unter github.com/WordPress/WordPress (alle 15 Minuten vom SVN synchronisiert). Es ist nicht für das Verschieben von Patches usw. gedacht - dafür müssen Sie auf jeden Fall SVN & Trac verwenden. Ich weiß nicht, ob dies für die Zwecke des OP geeignet sein wird oder nicht, aber der Vollständigkeit halber existiert es.
Pat J
@PatJ ein guter Punkt, ich nahm an, dass Q die Verwendung dieses Punktes bedeutete, aber vielleicht auch nicht
Rarst
Sehr gute Punkte. Ich habe einen ganzen Site-Stack eingerichtet, der Git mit Submodulen verwendet, und es ist ein großes Problem. Ich frage mich wohl, ob es eine weniger strenge Möglichkeit gibt, Git immer noch auszunutzen, aber auch die nativen Updates zu nutzen, um mir etwas Beinarbeit zu ersparen. Im Moment bin ich ein Ein-Mann-Team, also versuche ich im Grunde nur, Websites so effizient wie möglich einzurichten.
Josiah Sprague
@JosiahSprague Wenn der Hauptschwerpunkt in der Ersteinrichtung liegt (und nicht in der langfristigen Stapelwartung), ist es möglicherweise sinnvoll, sich mit benutzerdefinierten install.phpRoutinen oder Ähnlichem darauf zu konzentrieren und die normalen Update-Mechanismen von dort aus zu verwenden. Der Composer-Stack kann Aktualisierungen abstrakt sehr gut verarbeiten, hängt jedoch von der Qualität der von Ihnen verwendeten Pakete und von Dingen wie dem Proxy von offiziellen WP-Repositories ab, da diese noch nicht ausgereift sind.
Rarst
3

Vielleicht werfen Sie einen Blick auf dieses Problem und dieses Problem.

Schauen Sie sich auch die README-Dateien in jedem Repo an:

Basierend auf den obigen Repos habe ich dies als ein weiteres Beispiel für ein Git / WP-Setup erstellt . Ich habe mich für die Verwendung von Symlinks für Themen entschieden (ich versuche dies in meiner README-Datei zu behandeln ).

Ich bin ein bisschen im selben Boot mit den automatischen Updates ... Mein Plan war es, das WP-Submodul manuell zu aktualisieren, wenn Updates stattfinden. Ich denke, die Alternative ist theoretisch (ich muss mich noch testen), das Submodul selbst für kleinere Updates aktualisieren zu lassen (es gibt eine WP-Einstellung dafür) und dann ein gitForce / Reset des Submoduls durchzuführen, wenn größere Updates herauskommen ( Vielleicht könnte eine der Antworten hier hilfreich sein ... Natürlich würde man beim Aktualisieren auf die nächste Hauptversion auf ein bestimmtes WP-Tag abzielen wollen.

Eine zu beachtende Sache ist, dass, wenn WP .gitin den Pfaden sieht , die automatischen Updates automatisch deaktiviert werden. Weitere Informationen finden Sie unter:

Für die Aktivierung der automatischen Updates gelten einige einfache Anforderungen:

  • Wenn die Installation FTP für Updates verwendet (und zur Eingabe von Anmeldeinformationen auffordert), werden automatische Updates deaktiviert
  • Wenn die Installation als SVN- oder GIT-Prüfung ausgeführt wird, sind automatische Updates deaktiviert
  • Wenn die Konstanten DISALLOW_FILE_MODSoder AUTOMATIC_UPDATER_DISABLEDdefiniert sind, sind automatische Updates deaktiviert
  • Wenn die Konstante WP_AUTO_UPDATE_COREals falsch definiert ist, sind automatische Aktualisierungen deaktiviert
  • Ihre WordPress-Installation muss auch in der Lage sein, über HTTPS-Verbindungen mit WordPress.org Kontakt aufzunehmen, daher muss Ihre PHP-Installation ebenfalls OpenSSLinstalliert sein und funktionieren
  • Wp-Cron muss betriebsbereit sein, wenn cron aus irgendeinem Grund für Ihre Installation nicht funktioniert, sind auch keine automatischen Updates verfügbar

Andere verwandte Links:

Update vom Mai 2015

Ich habe dieses Repo erstellt, mit dem ich schnell WordPress-Projekte starten kann. Mein neuester Ansatz ist, nur die Versionskontrolle der Themes vorzunehmen. Mit anderen Worten, ich installiere WP lokal (unter Verwendung von Setup im oben genannten Repository) und in der Produktion, ändere dann die Konfigurationsdatei auf jedem System und gitziehe meine Themes, um eine funktionierende Site zu erhalten.

mhulse
quelle
2

Diese Art der Entwicklung fällt in die Kategorie "nicht so einfach und erfordert einen benutzerdefinierten Workflow, mit dem es möglicherweise lange dauert, bis man zufrieden ist".

Ich finde Unterbäume, Submodule oder verschachtelte Repos, ein großer Schmerz im Arsch.

Einige Gedanken (verfolge alles).

  1. Aktivieren Sie automatische Updates mit git / svn mit:
    add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Sichere Methode über manuelle Commits + E-Mail:

Sie können einen Staging-Server verwenden und Benachrichtigungen über E-Mail-Updates an sich selbst senden, die Updates festschreiben und auf den Live-Server übertragen, auf dem die automatischen Updates deaktiviert sind.

Auf diese Weise können Sie auch Ordner für Ihre eigenen Repos nach Belieben kopieren / einfügen, wie ich es oft tue. Es macht es auch einfach, mehrere Staging-Server zu klonen / zu zerstören. Git wird mit dieser Methode wirklich wirksam, da es verteilt wird.

Der Nachteil: Kopieren / Einfügen von Ordnern, Verwaltung.

Automatische Methode

Richten Sie ein Build-Skript (Phing, Ant, Bash, Capistrano usw.) und einen benutzerdefinierten Code ein, der ein git add + commit ausführt, wenn ein Update angewendet wird, und senden Sie es an den Live-Server. Sie können Plugins / Theme-Repos auch trennen und dann das Skript kompilieren / verschieben / was auch immer und / oder Composer in der Mischung verwenden.

Die Automatisierung eines solchen Workflows ist in der Regel auch unflexibel und lohnt sich nur, wenn Sie einen echten Bedarf an investierter Zeit sehen.

Der Nachteil: unflexibel, braucht Zeit zum Erstellen.

Git sollte nicht für Backups verwendet werden, und im Allgemeinen müssen Sie den Festschreibungsverlauf von WP nicht klonen.

Wyck
quelle
0

Nach einigem Überlegen, da ich auf jeden Fall die nativen WP-Updates nutzen möchte, um mir die Arbeit zu ersparen, ist es nicht sinnvoll, alles zu verfolgen, was WP mit git aktualisieren wird. Hier ist eine überarbeitete Idee.

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Dann verliere ich natürlich die Möglichkeit, zu verfolgen, welche Plugins und Themen Teil des Projekts innerhalb des VCS sind, aber ich brauche das wirklich nur für Sicherungszwecke, und ich werde sowieso eine Art reguläres Sicherungssystem verwenden.

Das Einzige, was mir wirklich fehlt, ist die Möglichkeit, den gesamten Stack auf einfache Weise auf verschiedenen Servern bereitzustellen, ohne FTP zu verwenden, um das Ganze manuell zu kopieren. Hat jemand irgendwelche Gedanken dazu?

Josiah Sprague
quelle
0

Ok, wenn ich Mark Jaquiths Vortrag hier sehe, bin ich vielleicht auf dem falschen Weg. Hier ist ein weiterer Versuch, der alles nachzeichnet.

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

Ich vermute, der größte Nachteil dabei ist, dass es ein benutzerdefiniertes Inhaltsverzeichnis gibt, was in der Vergangenheit Probleme mit schlecht geschriebenen Plugins und Themen verursacht hat, die das Inhaltsverzeichnis nicht finden konnten.

Josiah Sprague
quelle