web-dev-qa-db-ja.com

どのように私は構築する必要があります WP gitを使用してから更新するWebサイトプロジェクト WP ダッシュボード？

私は何ヶ月もの間、WordPress Webサイト開発のためのgitバージョン管理を使うための良いプロジェクト構造を計画しようとしていました。それはWPダッシュボードを通してコアとプラグインを更新する能力を犠牲にしません。従来とは異なるディレクトリ構造（WP親フォルダの外側のwp-content）で、Webサイト全体の管理と展開が簡単です。サブモジュール、サブツリー、入れ子になったリポジトリなどについて読んだことがありますが、それをすべてまとめて正しい戦略を選択するのはまだ困難です。

これが私が今考えていることで、私がどうやってgitリポジトリをかっこで処理するかについての私の考えと共にです。

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

これは私にいくつかの問題/質問を残します。

  • 自動更新;私は新しい自動更新機能が大好きで、私のサイトを最新かつ安全に保つために時間と労力を大幅に節約することができるかもしれませんが、それはgitでコード変更を追跡するのにレンチを投げかけているようです。それでもWordPressコアに自動更新を許可しながら、コードの変更を追跡する方法はありますか？

  • WordPressコアレポジトリの下にサブツリーがあると、gitを使って新しいコアアップデートをマージしたり、自分の変更をWordPressコアレポジトリにプッシュバックしたりできなくなりますか（コアコントリビュータになりたいと思った場合）。

  • 公開gitリポジトリを持たないプラグインの場合、それらを完全に無視すると、手動でファイルをサーバーにコピーしなければサイト全体を新しいサーバーにすばやく複製できないという問題が生じます。そのプラグインのコードに変更を加えたい場合にも問題が発生します。それらの変更は追跡されず、プラグインのアップグレードで簡単に失われる可能性があります。

それで、要約すると、これらの問題を回避する良いgit + WordPressセットアップは何ですか？私が提案したプロジェクト構造についてのあなたのフィードバックに感謝します。あなたが私がこれを改善するのを助けることができるどんな方法でも、大いに感謝されるでしょう！

PS、この議論のためのよりよいフォーラムがあれば、そこに私を向けてください。

updatesauto-updategit
12
Josiah Sprague

私の考えでは、あなたの計画には2つの問題があります - Gitと「従来の」構造です。だから基本的にすべて。 :)

  1. Git（そして一般的にはバージョン管理）はサイト全体のスタックにとって貧弱なツールです。そこにいた、それをやって、それはとても痛い。

  2. コアからコンテンツを分離して「非従来型」の構造と呼ぶものは、しばらくの間、どの深刻なサイトでも非常に一般的で堅牢な選択でした。

  3. サイトスタック全体をネイティブアップデートと組み合わせるための簡単な方法はほとんどありません。異なるレベルのプロジェクト（開発者管理とエンドユーザー管理）で異なる目標を達成しようとするため、うまくいきません。

あなたが私に全体のサイトのための最善の策を頼むならば、WordPressスタックは現在 Composer です、しかし意見は慎重になるかもしれません。 :)

あなたの具体的な懸念について：

  1. 上記のように - ネイティブアップデート（もっと自動）は厳密に制御されたスタックではうまく動きません。

  2. WordPressコアはGitで開発されておらず、プルリクエストを受け付けません。すべての貢献は（今のところ）Subversionへのパッチファイルを介して行われます。

  3. そのようなプラグインをリポジトリにコミットする必要があるでしょう。それとも、Composerのような他のアプローチで行きましょう。

6
Rarst

this issueおよび this issueを見てください。

各リポジトリのREADMEファイルも見てください。

上記のリポジトリに基づいて、Git/WP設定の別の例として、私は this を作成しました。私はテーマにシンボリックリンクを使うことにしました（私は をカバーしようとします - 私のREADME でそれをカバーします）。

私は自動更新と同じボートにいるのですが...私の計画は更新が行われたときに手動でWPサブモジュールを更新することでした。理論的には（私はまだテストしていませんが）、サブモジュールにマイナーな更新のために自分自身を更新させ（これにはWP設定があります）、次にgitforce/resetを実行します。メジャーアップデートが出たときのサブモジュール（多分 ここの答えの一つ /は役に立つかもしれません...もちろん、次のアップデートには特定のWPタグをターゲットにしたいと思います。メジャーリリース）。

注意すべきことの1つは、WPがパス内で.gitを検出した場合、自動更新を自動的に無効にすることです。詳しくは、以下を参照してください。

自動更新を有効にするには、いくつかの簡単な要件があります。

  • インストールで更新にFTPが使用されている場合（および資格情報を要求されている場合）、自動更新は無効になっています
  • インストールがSVNまたはGITチェックアウトとして実行されている場合、自動更新は無効になります。
  • 定数DISALLOW_FILE_MODSまたはAUTOMATIC_UPDATER_DISABLEDが定義されていると、自動更新は無効になります。
  • 定数WP_AUTO_UPDATE_COREがfalseとして定義されている場合、自動更新は無効になります
  • あなたのWordPressインストールもHTTPS接続でWordPress.orgに連絡できる必要があるので、あなたのPHPインストールもOpenSSLname__がインストールされ動作している必要があります
  • 何らかの理由でcronがインストールに失敗した場合、Wp-Cronが機能する必要があります。自動更新も使用できなくなります。

その他の関連リンク

2015年5月更新

このリポジトリ を作成しました。これは、WordPressプロジェクトを開始するための簡単な方法です。私の最近のアプローチはテーマをバージョン管理することだけです。言い換えれば、WPをローカルに（前述のリポジトリの設定を使用して）インストールしてから、各システムの設定ファイルを変更し、gitname__を機能サイトに移動します。

3
mhulse

この種の開発は「それほど簡単ではなく、満足するのに長い時間がかかるかもしれないカスタムワークフローを必要とする」に分類されます。

私は、サブツリー、サブモジュール、または入れ子になったリポジトリ、お尻の大きな痛みを見つけます。

いくつかの考え（すべてを追跡します）。

  1. 以下を使用してgit/svnで自動更新を有効にします。
    add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

手動コミット+電子メールによる安全な方法：

ステージングサーバーを使用して自分自身に更新通知を電子メールで送信し、更新をコミットして自動更新がオフになっているライブサーバーにプッシュできます。

これはまたあなたが自由にあなた自身のリポジトリのためにフォルダをコピー/ペーストすることを可能にします、それはしばしば私がそうする方法です。それはまた、複数のステージングサーバのクローンを作成/破壊することを容易にします。それが配布されているので、gitは本当にこの方法で有効になります。

欠点：フォルダのコピー/貼り付け、管理。

自動方式

ビルドスクリプト（Phing、Ant、Bash、Capistranoなど）と、更新が適用されたときにgit add + commitを実行するカスタムコードを設定し、それをライブサーバーに送信します。また、プラグイン/テーマリポジトリを分離してからスクリプトにコンパイル/移動/それらを適用させたり、Composerを組み合わせて使用​​することもできます。

このようなワークフローを自動化することは、柔軟性に欠ける傾向があり、投資する時間が本当に必要な場合にのみ価値があります。

欠点：柔軟性がないため、作成に時間がかかります。

Gitはバックアップには使用しないでください。一般的に言って、WPのコミット履歴を複製する必要はありません。

2
Wyck

もう少し考えてみると、私は間違いなく自分自身の足跡を節約するためにネイティブのWP更新を利用したいので、WPがgitを使用して更新することを追跡するのは意味がありません。これは修正された考えです。

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

もちろん、その場合、どのプラグインやテーマがプロジェクトの一部であるかをVCS内から追跡することはできなくなりますが、実際にはバックアップ目的でのみ必要となるため、とにかく通常のバックアップシステムを使用します。

だから、これが本当に欠けている唯一のことは、手動で全体をコピーするためにFTPを使わずに、スタック全体を異なるサーバーに簡単にデプロイできることです。誰かそれについて何か考えがありますか？

0
Josiah Sprague

Mark Jaquithの話 here を見て、多分私は間違った道を進んでいます。これがすべてを追跡するもう1つの突き刺しです。

   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

これの主なマイナス面はカスタムコンテンツディレクトリを持っていることであると思います。これは過去のプラグインの書き方やテーマがコンテンツディレクトリを見つけられないという問題を引き起こしていました。

0
Josiah Sprague