🤹🏿 👨🏽‍🤝‍👨🏼 🍤 マルチワードプレス 🌌 👩🏻‍💼 🔠

タスク条件：

同じ種類のブログをいくつか作成します。
ブログはリモート公開をサポートする必要があります。

解決策：

これまでのリモートパブリッシング機能の不足により、MaxSite CMSのサイトですぐに繁殖するという非常に魅力的なアイデアを放棄しなければなりませんでした。より正確には、すでに存在しますが、作成者の標準に従って、Windows用の彼自身のクライアントとともに開発されました。

次の簡単な解決策は、Wordpressを繁殖させることでした。最初のバイトを持つ通常のプログラマーが吸収する最も重要なことの1つはコードの再利用であるため、彼はこの考えも放棄しました。 30のWPインストールを想像して、それぞれの更新をフォローし、異なるディレクトリでトピックを編集し、各ブログの各プラグインのアップデートをフォローしてください。これにより、システム全体が一般的に複雑になり、許容できない時間を要する自動更新システムが作成されます。

それで私はMovable Typeに来ました。プラットフォームはperlで記述されており、トレンドセッターです。OpenID 、 Trackback、および他の多くのテクノロジーが最初に登場したのはその中にありました。 Movable Typeの主な利点の1つは、コンテンツの静的な公開です。つまり、サーバーへのアクセス時にスクリプトによってユーザー用にページが生成されるのではなく、古き良きhtmlファイルとして作成されます。システムの1つのインストールは、理論的には、サーバーファイルシステム内のあらゆる場所で、異なるドメイン、サブドメイン、サブディレクトリにある何千ものブログを提供できます。ページは静的であるため、サーバーはDigg効果を生き残ります。

主な利点から、主な欠点が続きます。ブログを公開したり、デザインの変更があった場合に完全に再公開したりすると、「7890のレコード2を公開する」などの投稿を何時間も見ることになります。

管理者が遅い。非常に遅い。共有ホスティングの使用は非常に困難であることが判明しました。コメントにも問題が生じました-ホスティング事業者はhttpd.confへのアクセスを許可しなかったため、スクリプトのエイリアスを登録することはできませんでした。

彼は、 Wordpress MU-マルチユーザー版の実験を始めました。インストールの問題は、Movable Typeで発生しました。実際、MUはサブディレクトリまたはサブドメイン内のブログ向けに設計されています。ただし、別のドメインでの作業には問題が発生します。プラグインを使用して見つかったソリューションには問題がないわけではありません。別の解決策には、httpd.confの編集も含まれていました。

ドメインの1つに通常のWordpressを1回インストールし、残りのドメインをエイリアスにします。構成で、MySQL c 'wp_'というテーブル名のハードプレフィックスを、$ _SERVER ['HTTP_HOST']に基づいて作成された動的に変更します。見つかったコードは次のようになりました。

$prefix = $_SERVER["HTTP_HOST"]; 
      

        
        
        
      

     $prefix = str_replace("www.", "", $prefix); 
      

        
        
        
      

     $prefix = str_replace("-", "", $prefix); 
      

        
        
        
      

     $prefix = str_replace(".", "", $prefix); 
      

        
        
        
      

     $table_prefix = $prefix."_" ; //"wp_";

str_replaceをereg_replaceに置き換えました（「www \。| \-| \。」、「」、$ Prefix）。

偏執的なバージョンでは、md5（$ _ SERVER ['HTTP_HOST']。$ Salt）の形式のプレフィックスを指定することも、条件によって指定することもできます。

もう一つの手がかり。既存のブログをこのアセンブリに統合すると、管理パネルへのアクセスに問題が発生します。この場合、prefix_optionsテーブルのオプション名「wp_user_roles」の名前を「prefix_user_roles」に変更し、prefix_usermetaテーブルの古いオプション「wp_」で始まるすべてのオプションの名前を同じように変更します。

タスク条件：

Wordpressがインストールされている1つのドメインと、そのドメインに対する複数のドメインエイリアス（同義語）があります。たとえば、メインドメインとしてdomain.ruを、エイリアスとしてalias.ruを使用します。そのため、リンクhttp://domain.com/wp-adminに従って、最初のブログの管理パネルにアクセスします。したがって、リンクalias.ru/wp-adminに続いて、 2番目のブログの管理パネルに移動しますか？なんらかの理由はありません。何らかの理由で、最初のブログの管理パネルに再び登場します。何が問題なのかを理解してください。

解決策：

この問題は、Apache mod_dirモジュールの機能に起因しています。ドキュメントからの抜粋：

ディレクトリのインデックスは、次の2つのソースのいずれかから取得できます。

*ユーザーが作成したファイル。通常、index.htmlと呼ばれます。 DirectoryIndexディレクティブは、このファイルの名前を設定します。これはmod_dirによって制御されます。

*それ以外の場合、サーバーによって生成されたリスト。これはmod_autoindexによって提供されます。

2つの機能は分離されているため、必要に応じて自動インデックス生成を完全に削除（または置換）できます。

サーバーがURL servername / foo / dirnameの要求を受信すると、「末尾のスラッシュ」リダイレクトが発行されます。ここで、dirnameはディレクトリです。ディレクトリには末尾のスラッシュが必要なので、mod_dirはservername / foo / dirnameへのリダイレクトを発行します。

要するに、サーバー上のファイルではなくディレクトリに対してリクエストが行われ、リクエストがスラッシュで終わらない場合、モジュールはリクエストを自動的に同じアドレスにリダイレクトしますが、最後にスラッシュを追加します。これはバグではなく、非常に不便な機能です。これは、 末尾のスラッシュリダイレクトと呼ばれます。

また、エイリアスドメインの場合は、同時にエイリアス名をメインドメインの名前に置き換えます。したがって、2番目のリクエストにスラッシュを追加すると、2番目のブログの管理パネルに移動し、追加しない場合は、最初のブログの管理パネルに移動します。

問題の最終的な解決策として、お気に入りの.htaccessファイルすべてに変更を加える必要があります。私の場合、CNC（人に優しいURL）を表示するオプションがオンになっているときにWordpressによって生成され、次のようになります。

<IfModule mod_rewrite.c> 
      

        
        
        
      

     RewriteEngine On 
      

        
        
        
      

     RewriteBase / 
      

        
        
        
      

     RewriteCond %{REQUEST_FILENAME} !-f 
      

        
        
        
      

     RewriteCond %{REQUEST_FILENAME} !-d 
      

        
        
        
      

     RewriteRule . /index.php [L] 
      

        
        
        
      

     </IfModule>

.htaccess構文は非常に単純です。 RewriteEngine Onディレクティブは、変換メカニズムの処理を有効にしたことを意味します。 RewriteBaseは、このディレクトリに関連する翻訳のベースURLです。

RewriteCond-これらは、変換の条件、作業のロジックです。最初のパラメーターは比較する文字列で、2番目のパラメーターは条件です。比較される文字列として、サーバー変数が通常使用されます。たとえば、 REQUEST_FILENAMEは 、サーバーファイルシステム内の要求されたファイルへのパスです。条件！-Fは要求がファイルではないことを意味し、 ！-Dは要求がディレクトリではないことを意味します。したがって、 RewriteCondの2行は、実際に既存のファイルまたはディレクトリが要求されていない場合、次の手順を実行する必要があることをモジュールに伝えます。

RewriteRuleは、変換ルール自体です。 RewriteCondの2つの条件が真である場合、このケースで満たされます。構文は単純です-最初のパラメーターはテンプレートで、2番目のパラメーターは置換です。テンプレートでは、Web開発に干渉しない方がよいかどうかを知らずに、Perlの正規表現の全機能を使用できます。さらに、必要な量の彼らの研究は1日以上かかりません。

そこで、さらに2つの条件を追加します。

RewriteCond %{REQUEST_FILENAME} -d 
      

        
        
        
      

     RewriteCond %{REQUEST_URI} !^%{HTTP_HOST}$

すでに理解されているように、最初のリクエストは、リクエストがディレクトリにつながる場合に当てはまります。 2番目は、さらに2つのサーバー変数を使用します-REQUEST_URI-リクエスト自体とHTTP_HOST-サーバー名。 2番目の条件は、要求がサーバー名と等しくない場合に当てはまります。つまり、リクエストがサーバーのサブディレクトリにつながる場合、条件も真です。

次に、リダイレクトルールを追加します。

RewriteRule ^(.+[^/])$ %{HTTP_HOST}/$1/ [R]

テンプレートは、単純な正規表現を使用します。 ^および$は、行の最初と最後のチェックを意味します。 -数量詞*（くさび形星印）とは対照的に、数量詞+の文字をチェックすると、前の表現の1つ以上のコピーが表現されます。角括弧[] -文字クラスを定義し、 ^は排他クラスを宣言します。したがって、 [^ /]はリテラル/の排他的な文字クラスです。

式全体は、文字列が1から無限の任意の文字で始まり、リテラル/ではない任意の文字で終わることを意味します。つまり、スラッシュで終わらない単なる文字列です。ルール置換テンプレートが作成されました。次に、この行を置き換えるものを検討します。

http：//プレフィックスは明確で、サーバー名変数も明確です。 /ここで、彼らは自分自身を意味しますが、 1ドルより興味深いものです。

$ Xは、 RewriteRuleディレクティブからのフィードバックであり、シーケンス番号Xの RewriteRuleテンプレートのグループ化された部分へのアクセスを提供します。それらは括弧でグループ化されています。この場合、最初で唯一のグループは（。+ [^ /]）です。

その結果、ルールは既存のディレクトリへのリクエストであるリクエストをスローしますが、サーバー/このリクエストへのバックスラッシュに限定されません。 / -mod_dirを閉じるだけで、管理パネルにアクセスできます。

マルチワードプレス

More articles: