初心者MODX Revoノート

免責事項：もちろん、この記事で紹介されている内容の多くは、知識のある人にとってはキャプテンのようです。 しかし、おそらく彼女は誰かを助けるでしょう...

はじめに

それで、MODXとは正確には何ですか（ちなみに、そのように書かれています-ハブの名前としてではなくMODX-MODx）？ 公式サイトを読むと-これはCMSです。 ただし、これは真実の一部にすぎません。 実際、MODXはCMSとCMFのほぼ中間です。 ただし、MODXに興味がある人は他の記事からすぐにわかるので、この点については詳しく説明しません。



MODXはCMSとCMFの中間にあるため、WordpressやJoomlaなどの単純なCMSほど簡単に学ぶことはできません。 おそらく、この記事は、一見して明らかではないように見える微妙な点のいくつかを明らかにするために書かれたのでしょう。

設置

個人的に、nginxとPHP-FPMを装備したサーバーにMODX Revo 2.2.4をインストールしました。

MODXは一般にApache + PHP拡張用に設計されているため、nginxには追加の構成が必要です。 私の構成は次のようになります。



実際、この設定は不完全であると確信していますが、初期設定ではおそらく適切です。 ここで停止することが2つあります。実際、MODXを接続します（CNCが正しく機能するため）。

  server_name example.com *.example.com; #   MODX        . #        MODX.        ( ),   (   ).    ,    MODX-? location / { try_files $uri $uri/ @rewrite; } #  .    - MODX     index.php?q= -       . location @rewrite { rewrite ^/(.*)$ /index.php?q=$1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これはMODXと他のすべて（PHPなしでnginx CSS、JS、画像、その他のものをロードする）の両方を正しく動作させるのに十分なようです。

インストール自体は非常に簡単です。ファイルを目的のフォルダーに解凍し、アドレスバーexample.com/setup/に移動するだけで、その後簡単なインストーラーが読み込まれます。

人に優しいURL（CNC）

デフォルトでは、CNCはMODXで無効になっています。 それは非常に簡単にオンになります：システム->システム設定->「friendly_urls」をフィルターに入れてEnterを押します（もちろん、ハンドルを使用して検索できますが、より高速です）->値を「はい」に切り替え、上部の「保存」をクリックします。

一般的に、MODXでは、保存ボタンが右上隅にあることを忘れないでください。 MODXでは自動保存がトリガーされる場合とそうでない場合があるため、設定を忘れてしまうことがあります。

同様に、CNCの自動生成のための関数 "automatic_alias"に対しても実行します。

CNCを正常にオンにしたので、リンクは次のように形成されます。

 example.com/resourcename.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に.htmlが挿入されていることに注意してください！ 個々のリソースのContent-Typeに依存します（リソース自体のプロパティの変更）。 コンテンツタイプ自体の設定は、システム->コンテンツタイプにあります。

ただし、追加のGETパラメーターはすべて同じままであり、これは次のように機能します。

 example.com/news.html?date=05092012&nid=1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

個人的に、私はそのようなシステムが好きではなかったので、これらのパラメーターをCNCの一部にする方法を探し始めました。 そして見つけた！

手始めに、MODXを拡張できるさまざまな要素について少しお話しする価値があります。 それらのいくつかがあります：

• テンプレート変数-追加のリソースプロパティフィールド。 後で彼らに戻ります
• チャンク-他のチャンク、リソース、または一般的にどこにでも挿入できるHTMLコードのブロック（MODXマークアップの可能性あり）。 注意！ ここにはPHPを挿入できません！
• スニペットは、特定のデータを挿入された場所に出力するPHPコードのブロックです（MODXマークアップを使用）。 チャンクの一種のPHPアナログ。
• プラグインは、MODX内で発生する特定のイベントに従って実行されるPHPコードのブロックです。 おそらくDrupalフックのようなもの。

この場合、スニペットとプラグインが必要です。

それでは、独自のURL形式でMODXにどのように統合しますか？ 実際、それは非常に簡単です-MODXに指定されたURLでページを見つけさせ、見つからない場合は制御して解析し、その後MODXをあるべき場所に送ります。 これを行うには、 OnPageNotFoundイベントのプラグインを使用します。



実際、ここではおそらく次のことをやめる価値があります。

 $modx->request->getResourceMethod()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CNCがオンになっているかどうかを確認します。

 $modx->resourceIdentifier
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このそれほど明白ではない変数は、要求されたURLを格納します。

 $paramDelimiter="-";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この変数は、GETパラメーターの名前とその値の間の区切り記号を設定します。 「/」以外に変更できます。

 $modx->request->parameters['GET'][$parameter[0]]=$parameter[1]; if(empty($modx->request->parameters['POST'][$parameter[0]])) $modx->request->parameters['REQUEST'][$parameter[0]]=$parameter[1];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、MODXは各リクエストでGETおよびPOSTパラメーターに関するすべての情報を独自の配列に保存し、その後、およそ次の方法で共通の配列を形成します。

 $modx->request->parameters['REQUEST'] = array_merge($modx->request->parameters['GET'], ($modx->request->parameters['POST']);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構造を保存するために、POST配列のデータがREQUEST配列に保存されているかどうかを毎回確認し、存在しない場合にのみREQUEST配列のデータを置き換えます。

 if (array_key_exists($uri, $modx->aliasMap)) { $modx->sendForward($modx->aliasMap[$uri]); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは実際に目的のリソースへのリダイレクトです。 CNCテーブル全体が$ modx-> aliasMapに保存されます。これを使用して、目的のリソースに移動する時間か、またはアンダーパースされたuriのコンテンツがまだパラメーターで構成されているかを確認します。 $ modx-> sendForwardとこのリダイレクトを実行します。



ただし、おそらく、このURL生成メカニズムを使用して、たとえば現在のページへのリンクをすぐに提供したいと思うでしょう。 これを行うために、現在のページのURLを生成するだけの簡単なスニペットを作成しました。 もちろん、生成や他のリンクのために拡張できますが、これはすでにそれを必要とする人の個人的な宿題になります-それについて複雑なことは何もありません:)

 <?php $currentURL=""; foreach($modx->request->getParameters() as $key => $value) { $currentURL.=$key."=".$value."&"; } $currentURL = $modx->makeUrl($modx->resource->get("id"), $modx->context->get("key"), $currentURL); return $currentURL;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、説明する特別なものはありません。 $ modx-> makeUrlはURLを形成します。 参考のために-それはコンテキストに関連してそれを形成します-2番目のパラメーターは単にコンテキストを設定します。

MODXのマルチサイト

同じMODXで異なるコンテキストの複数のドメインを処理する

実際、このトピックは、たとえばこのトピックやインターネットですでに取り上げられています 。 私の決断を提示したいと思います、それは私には非常に簡単なようです。 しかし、最初に、この問題を解決する主な方法をリストします。

1. index.phpの編集。 Index.phpは、起動時にロードされるコンテキストを明示的に示します。 それを完全に修正し、状況をコンテキストの選択に置き換えることができます。 私がこの方法を好まない理由：オリジナルのmodxファイルの編集。 なぜこの事実が好きではないのですか？ アップデートの難しさ。 私がmodxが好きなのは（そしてSMFフォーラムエンジンが好きではないのと同じように ）、元のMODXファイルを変更する必要がないことです。これにより、エンジンをできるだけ簡単に更新できます。
2. OnHandleRequestイベントのプラグインを作成します（一般的な欠点：もう少しリソースが使用されます-Webコンテキストが常に最初にロードされ、その後に必要なコンテキストがロードされます）：
   
   
   1. index.phpの編集に似ていますが、編集しません。 すべてがほぼ同じです-厳密に定義されたコンテキストのリストによって処理されるドメインのリストはハードコーディングされています。 または、コンテキスト名にはドメイン名の一部（forum.example.comサブドメインのフォーラムコンテキストなど）が含まれ、それに基づいて必要なコンテキストの検索が実行されます。単純なサイトの場合は適切ですが、十分な柔軟性はありません。
   2. コンテキスト設定をスキャンして、適切な設定を見つけます。 最大限の柔軟性、コンテキストの自動作成、作成後にプラグインを編集する必要はありません。
   
   
   

ここで最後のオプションのみを説明します。 私のプラグインのテキスト（思い出して、 OnHandleRequestイベント）：



使用するには、コンテキストプロパティの「multisite_http_host」パラメータに、処理するドメインの値を設定する必要があります。 適切なコンテキストが見つからない場合、プラグインはデフォルトでWebコンテキストを使用します。

ここでは、2つのことに焦点を当てたいと思います。

まず、MODXを正常に使用するには、xPDOの原理を理解する必要があります。 xPDOは、データベースとPHPオブジェクト間の通信のためのメカニズムです。 PHPでオブジェクトを操作すると、データベースにアクセスできます。 MODXのほぼすべてが、xPDOを使用してデータベースと通信します。

 $object = $modx->getObject('modContextSetting', array('key' => 'multisite_http_host', 'value' => $modx->getOption('http_host')));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、特定の条件を含むコンテキスト設定オブジェクト（つまり、httpホストの値を持つmultisite_http_host構成キー）を検索するためにデータベースに移動します。 その後、受信したオブジェクトからロードする必要があるコンテキストキーを取得します（$ object-> get（ "context_key"））。

第二に、haberuser XanderBassが正しい質問をしました。ここで私はそれを複製したいと思います。 では、なぜ「http_host」だけでなく「multisite_http_host」というパラメータ名を使用しているのでしょうか？

すべてが非常にシンプルで、システム設定、コンテキスト、ユーザーを組み合わせるメカニズムに基づいています。 実際、システム設定はコンテキスト設定によって上書きされ、それらはユーザー設定になります。

この場合、http_hostはシステム設定です。 コンテキスト設定でmultisite_http_hostの代わりにhttp_hostを使用すると、コンテキスト設定によって消去されます。 もちろん、この特定の例では、これはそれほど怖いものではありません。 ただし、このプラグインを少し書き換えて、特定のドメインのすべてのサブドメインを1つのコンテキストで処理します。 または、いくつかの異なるドメインの1つのコンテキストで処理を実行します（たとえば、ほぼこの形式のパラメーターに駆動する：sub1.example.com; sub2.example.com; sub3.example.com "など）。この場合、 http_hostでは、リクエストに使用されたhttp_hostではなく、この設定になりますが、あなたは決して知らないでしょう、元のhttp_hostがどこか他に必要になるかもしれません...

マルチコンテキスト認証

時には、複数のコンテキストでユーザーを一度に認証したいことがあります。 デフォルトでは、システムにログインする（たとえば、ログインmodを使用して）ユーザーは、1つのコンテキストのみでシステムにログインします。 次のプラグインは、承認中にいくつかのコンテキストに自動的にログインします（ OnWebLoginおよびOnWebLogoutイベント ）：



使用するには、パラメータ「multisite_site_group」を、ユーザーが同時にログインするすべてのコンテキストのすべての必要なコンテキストに同じ値を設定する必要があります。

ほんの少しのコメント：

ここで、必要なコンテキストの検索は、以前のプラグインで実装した方法と非常によく似ています。唯一の違いは、getObjectの代わりにgetCollectionを使用することです。 そうすることで、指定された条件に従うオブジェクトの配列を取得します。

 $modx->user->addSessionContext($contextKey);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 $modx->user->removeSessionContext($contextKey);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコンテキストまたはそのコンテキストでユーザーの承認を実行するだけです。

 $_SESSION['modx.'.$contextKey.'.session.cookie.lifetime']=$attributes["lifetime"];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在のコンテキストと同じように、他のすべてのコンテキストの承認の「存続期間」を付加します。



現時点では、私が伝えたかったすべてのことのように思えます。 言語の切り替えを伴う開発は、おそらく後で変更します。 ご清聴ありがとうございました！