web-dev-qa-db-ja.com

WordPressコアライブラリを共有する方法

私たちは10のブログを小さなEC2インスタンスで実行しています。すべてのブログが同じワードプレスのPHPコードを共有できるかどうかを確認したいのです。

  1. Wordpressを更新すると、すべてのブログが更新されます
  2. Apache/mod_phpのメモリを、重複したスクリプトやキャッシュ内のバイトコードとして保存しない（APCの場合）。

すべてのブログを別のDBに保存する必要があるため、MUを使用することはできません。そのため、後で移動する必要があるときには、はるかに簡単になります。

誰もが以前にこれを試したことがありますか？

multisiteperformancecore-modifications
7
Yoga

すべてのインストールが同じインスタンス上にあり、したがってそれらの間で同じファイルを共有できると仮定すると、あなたがする必要がある主なことはすべてのカスタムコンテンツのものをメインのWordPressフォルダの外に置くことです。

まず最初に、WordPressの新しいコピーを手を付けずにどこかに置いておきたいと思います（そして手を付けられないのですが、全体的に重要なのは1つのコピーを持つことです）。

次に、これらのファイルを他の場所にミラーリングするためにハードリンクまたはsymリンクを使用します。通常、Unix風の環境では、シンボリックリンクを行うためにln -sを使用します。これを具体的に行う方法は読者に任されていますが、本質的にあなたがあなたのWordPressを/ example/wpに持っているなら、あなたはln -s /example/wp /home/username/public_html/wpのような何かまたはそのようなことをするでしょう。 sym-linksが問題を引き起こす場合は、代わりにハードリンクに切り替えてください。

さて、メインのWordPressフォルダの中にあるが、 "core"の一部ではないカスタムなものは、あなたのwp-config.phpファイルと全体のwp-contentフォルダです。そのため、各サイトのmain/wpフォルダの外側にこれらを配置する必要があります。どちらも可能です。

Wp-config.phpファイルは簡単です、なぜならWordPressもデフォルトでそれ自身からディレクトリを調べます。あなたのwpフォルダが/home/username/public_html/wpにあるなら、WPは/home/username/public_html/wp/wp-config.phpをチェックしますが、それが/home/username/public_html/wp-config.phpも探すことに失敗するでしょう。それで、あなたのwp-config.phpファイルを上のディレクトリに作ってください。

Wp-contentフォルダの場合は、wp-config.phpファイルに次のようにコードを追加することで、メインのwpディレクトリの外側に移動できます。

 define( 'WP_CONTENT_DIR', '/home/username/public_html/custom-content' );
 define( 'WP_CONTENT_URL', 'http://example.com/custom-content');

そしてWordPressは、コンテンツとその中のすべてのものが代わりにそこに存在すると期待します。/wpディレクトリ内のwp-contentフォルダは完全に無視されるため、このフォルダを作成してそこにテーマ/プラグイン/アップロードを配置する必要があります。

最後のステップは、.htaccess（あるいはApacheを使用していない場合は他の設定ファイル）を使用することです。/ wpフォルダが存在するかのように、ルートから見ることができます。これはトリッキーではありません、それはただ少しの思考を必要とします。通常のWordPressの.htaccessルール（デフォルト以外のパーマリンク用）は、基本的にすべてのリクエストをメインのWordPressのindex.phpファイルifにリダイレクトするように指示しています。いる。これにより、アップロードされた写真などをWPの外部で直接操作できます。

これを模倣するために/home/username/public_html/.htaccessで使用できるルールセットの例を次に示しますが、/ wpディレクトリも考慮に入れてください。

Options -Indexes
RewriteEngine on
RewriteCond %{HTTP_Host} ^(www.)?example.com$
RewriteCond %{REQUEST_URI} !^/wp/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wp/$1
RewriteCond %{HTTP_Host} ^(www.)?example.com$
RewriteRule ^(/)?$ wp/index.php [L]

基本的に、これらの規則は二つのことを言います。

最初に：要求されたURLに/ wp /が含まれていないおよびが既存のファイルまたはディレクトリではない場合は、内部の書き換えを使用してURLの前に/ wp /を付けます。 。これは http://example.com/whatever から http://example.com/wp/whatever へのすべてのURLを再マッピングする効果があります。基本的には、/ wp /が実際にサイトのルートにあるかのように動作します。

2番目のルールはルートURL（単に/）の要求を/wp/index.phpファイルに変更します。これは必ずしも必要ではないかもしれませんが、私にとってはうまくいきます。

これにより、/ wpディレクトリを「純粋な」ままにしておくことができます。したがって、サイト固有のものではなく、シンボリックリンクまたはハードリンクを使用して他の場所にone-true-WPインストールを維持できます。

よく書かれていないプラグイン（そしていくつかのテーマでさえも）は、それらがメインのwp-contentフォルダにあるという仮定をするかもしれないことに注意してください。 include '../../../wp-load.php';などのような愚かなことをしているものはすべて、この方法では壊されます。このエラーはプラグイン/テーマにあります。 プラグイン/テーマにwp-loadを含めるべきではありません 。

11
Otto

あなたの基本的な前提には意味をなさないいくつかのことがあります。最初に、別々のインスタンスに10個のブログがある場合、それらは同じコードベースを共有できません - 10個のEC2インスタンス= 10個のサーバー、したがって10個のファイルセットが必要です。第二に、あなたは必然的に同じ理由でスクリプトが重複しているでしょう。インスタンス間でクロストークできますか？私はそうは思わないが、たとえあなたが2つのサイトが同じコードベースから実行しようとしているとしても、最低でもデータベース設定とのwp-config.php衝突があるでしょう。

私はマルチサイトがここに行く方法ではないことを本当に確信していません。すべてのブログは同じDBに存在しますが、それらはすべてブログ固有のテーブルプレフィックスを持ち、DBバックアップを容易にし（1 DB対10）、それでも移植性を可能にします（詳細については here を参照）。 1つのブログをマルチサイトから移動するのは少し面倒です。単一のサイトを別のドメインに移動するのと同じくらい面倒です。

あなたが望んでいるのは10の異なるWP環境を持っていて、それらのうちの1つのための完全なコードベースだけを持っていることであるように聞こえます。したがって、「同じコードベースだがマルチサイトではない」というあなたの要求は相互に排他的であり、それが4日経って誰もこれに答えなかった理由です。要件を少し考え直す必要があるようです。

さて、もしあなたがWPがグローバルに更新されていることを確認したいだけなら、 あなたのコアWordPressインストールをSVN にフックすることを検討してください。リポジトリにある限り、個々のプラグインに対しても同じことができます。こうすれば、シェルスクリプトを実行して、10個すべてのインスタンスを一度にsvn upヒットすることができます。ただし、これはマルチサイトインストールを回避するための多大な作業のようです。

0
SickHippie