web-dev-qa-db-ja.com

Git展開問題のあるWordpress

私は開発ワークフローとサイト配備のためのかなり確立された標準があるpython/Djangoの世界から来て、私はwordpressに不慣れです、そこで私は配備を管理する方法に関するいくらかの指導を見つけることを試みています。

私がやろうとしていることのいくつかの背景については：私はデジタルオーシャンでホストされている電子商取引のワードプレス展開を引き継いでいます。このサイトは稼働中で、長期的には別のプラットフォームに移行する可能性が高いため、インストールされているテーマをカスタマイズしてDigital Oceanに簡単にデプロイできるようにするための一時的な解決策です。 ） コントロール。

私は最初にWPをMySQLを使うためのポートでherokuにデプロイしようとしました Mhoofmanのリポジトリ 。私が遭遇した問題はWP Read Onlyエクステンションがインポーターとサムネイルのようなものを壊していたということでした、そしてそれはそれがもう開発中ではないように思えます。そうでなければそれが私の優先解決策だろう。

私の最新の試みは、 Efeqdevの方法 を使ってwordpressをサブモジュールとして設定することです。 OS X上のMAMPで静的ファイルを扱う問題に遭遇した後、私はついにそれを動かしました。

今私はインストールされたプラグインでこれらの問題を抱えています：

Strict Standards: Redefining already defined constructor for class WXR_Parser_Regex in [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php on line 408

Strict Standards: Declaration of WP_Import::bump_request_timeout() should be compatible with WP_Importer::bump_request_timeout($val) in [...]/project-wordpress/wp-content/plugins/wordpress-importer/wordpress-importer.php on line 38

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wp-content/plugins/ninja-forms/ninja-forms.php on line 638

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 750

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 751

もちろん、投稿に関するコメントをすべて読み終え​​てから、 Bedrock を使用したデプロイに移行したようです。 Bedrockを使用することに対する私の躊躇は、Composerが私のためにプラグインを管理し、私がそれらに行ったかもしれないカスタマイズを一掃するかもしれないように思えるということです。私が言ったように、PHP/Wordpressにはあまり慣れていないので、それについて間違っていて、それがより安全な選択肢のように思われる場合は、私に知らせてください。

WPの部分を動き回ることで、物事が壊れる可能性がたくさんあるようです。 wp-contentサブディレクトリをgitサブモジュールに、その他すべてを標準的な方法で保持するのがより理にかなっているでしょうか。 uploadsフォルダの内容を処理する方法が完全にはわからないので、gitに保存するのはお勧めできません。新しい画像がアップロードされるとサーバーで変更されるため、メディアの配信にcloudflareを使用しています。

pluginsgitdeployment
1
Andres

1つのサイトに関連する1つの大きなボールのコードと見なすので、すべてのWordPressをコミットします。つまり、コアWordPressファイル、プラグイン、およびテーマの更新はすべてコミット履歴の一部になります。

サブモジュールや他の奇妙な入れ子になったリビジョン設定は使いません。複数のリポジトリを含めるという複雑な構造がある場合は、それらを別々にしておき、別々のアプリケーション履歴ではなく、ファイルを使ってメインリポジトリを更新するためにcomposerまたは別のツールを使用することをお勧めします。

私はgitがWP特有のものを無視するのを無視します：

  • 任意のキャッシュファイルまたは一時ファイル（たとえば、objectcache/、pgcache/など）
  • /wp-content/uploads/
  • バックアップディレクトリ、ログ、サイトマップ
  • 設定（wp-config.php、.htaccess、任意のキャッシュ設定など）

すべてのサイトが同じというわけではありません。私はwp-config.phpをマルチ環境コードでコミットすることもありますが、/wp-content/uploads/をコミットすることもあります。

また、プラグインやテーマによっては、メディアファイルを他の場所にアップロードするのが面倒なので、ファイルの種類を無視することもあります。

意見がいくつかあります：

私がなぜリポジトリ内のすべてのWPをコミットしないのか私は理解していません、あなたが更新のためにあなたの履歴にWP変更があるときあなたはずっと少ない責任を負います）.

セットアップを正しく行い、テストするために時間をかけてください。stuffは、後でそれを変更しようとしたときに起こることとは対照的に、よりスムーズに実行できます。

それはそこにはないことに気づくためだけに何かを探すのが面倒だからです。しかし、望まないことをコミットするのも嫌なので、単純にすると、頭脳と机のシナリオが合わなくなります。

これは私が始める.gitignoreの例です： https://Gist.github.com/wycks/574052a64eee9307b06c

4
Wyck