コンテキストとの戦い方

真の保守派として、長い間、MODx Evolutionのみを使用していました。 まず、包括的なドキュメント、豊富な記事、およびこのバージョンのMODx CMFの非常に理解しやすいアーキテクチャの可用性に満足しました。 革命版について、私は定期的にさまざまな記事を読みましたが、他の何かのために私の通常のシステムを変更したくありませんでした。 しかし、ある時点で、ホスティング上のマルチドメイン「ハムスター」のデータベース内のテーブルの数が恐ろしいサイズに達しました。 マルチドメインソリューションについて質問がありました。 MODx Revolutionでマルチドメインサイトを作成する可能性について読んだことがあります。 テストサブドメインにエンジンをインストールし、さらに掘り下げました。 判明したように、フレームワーク自体にはマルチドメイン用の既製のソリューションはありません。 コンテキストの特定のシステムがあります。 異なるコンテキストを異なるサブドメインで定義できます。 このためにのみ、index.phpファイルを編集する必要があります。



最初に頭に浮かぶのは、すでに実証済みの人気のあるコードを使用することです。

switch($_SERVER['SERVER_NAME']) { case 'sub1.domain.tld': $modx->initialize('sub1'); break; case 'sub2.domain.tld': $modx->initialize('sub2'); break; case 'sub3.domain.tld': $modx->initialize('sub3'); break; default: $modx->initialize('web'); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、多言語がコンテキストシステムに基づいている場合は、次のこともできます。

 switch($_SERVER['SERVER_NAME']) { case 'domain.ru': case 'www.domain.ru': $modx->initialize('ru'); break; //    case 'domain.fr': case 'www.domain.fr': $modx->initialize('fr'); break; //    ( ) default: $modx->initialize('web'); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、サブドメインの数がホスティング/ドメイン管理者によって制御され、めったに変更されない非常に大規模なポータルでは、このようなソリューションで十分です。 しかし、あなたと空想しましょう。 独自のサーバーがあります。 それはあなたの個人的なサーバーまたはあなたの好きなホスティングのVDS-kaでありえます。 プログラムでサブドメインを作成することができます。 livejournal.comのアナログを書いているとしましょう...



APIを使用してコンテキストを作成することはそれほど難しくありません。 詳細については説明しませんが、MODx Revolution APIについてこれまであまり勉強していません。 それでも、コンテキストとサブドメインを作成することは1つのことですが、それをリンクすることは別です。 ここでは、上記のソリューションは機能しません。サブドメインの数とそれらのコンテキストがどのように呼び出されるかが事前にわからないためです。 理論的には、コンテキストエイリアスがサブドメインの名前と一致する場合、ソリューションは非常に適切です。

 define("myRootDomain","domain.tld"); $ctxKey = 'web'; if (preg_match('#(\w+).'.myRootDomain.'#si',$_SERVER['SERVER_NAME']) > 0) { $ctxKey = preg_replace('#(\w+).'.myRootDomain.'#si','\1',$_SERVER['SERVER_NAME']); if ($ctxKey == 'www') $ctxKey = 'web'; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MODxのメインコンテキスト情報は、 context_settingテーブルのデータベースに保存されます。 最初の表には、コンテキストの説明（キー、説明、表示順序）が含まれています。 2番目のコンテキスト設定。 一般的なソリューションでは、エラーページ、ホストなどを登録する必要があったことを覚えていますか？ これが格納されているすべてです。 そして最初に思い浮かぶのは、このテーブルのSQLクエリです。

 $SQL = "SELECT * FROM ".$table_prefix." WHERE `key`='http_host' AND `value`='".$_SERVER['SERVER_NAME']."'";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテキストシステムが古いEvolutionで提供されていた場合、アルゴリズムを使用するとすべてが簡単になります。

 $ctxKey = 'web'; if ($result = $modx->db->query($SQL)) if ($row = mysql_fetch_assoc($result)) $ctxKey = $row['context_key'];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、この点で、MODx RevolutionアーキテクチャはxPDOに基づいているため、MODx開発者はMODxを使用する開発者に少し不満を募らせています。 そして、これは私たちにとって通常のAPIではなく、まったく異なる会話です。



MODx Revolution APIの公式ドキュメントを含む多数のGoogle検索結果を調べたが、MODx Revolutionでデータベースクエリを作成することがどれほど簡単かを理解できませんでした。 しかし、 core / model / modx / modx.phpファイルをコピーすると、次のようなものが見つかりました。

 $pluginEventTbl= $this->getTableName('modPluginEvent'); $eventTbl= $this->getTableName('modEvent'); $pluginTbl= $this->getTableName('modPlugin'); $propsetTbl= $this->getTableName('modPropertySet'); $sql= " SELECT Event.name AS event, PluginEvent.pluginid, PropertySet.name AS propertyset FROM {$pluginEventTbl} PluginEvent INNER JOIN {$pluginTbl} Plugin ON Plugin.id = PluginEvent.pluginid AND Plugin.disabled = 0 INNER JOIN {$eventTbl} Event ON {$service} Event.name = PluginEvent.event LEFT JOIN {$propsetTbl} PropertySet ON PluginEvent.propertyset = PropertySet.id ORDER BY Event.name, PluginEvent.priority ASC "; $stmt= $this->prepare($sql); if ($stmt && $stmt->execute()) { while ($ee = $stmt->fetch(PDO::FETCH_ASSOC)) { $eventElementMap[$ee['event']][(string) $ee['pluginid']]= $ee['pluginid'] . (!empty($ee['propertyset']) ? ':' . $ee['propertyset'] : ''); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、modXクラスのgetEventMapメソッドのスニペットです。 長いリクエストの代わりにリクエストを挿入できると仮定するのは論理的です。理論的には、リクエストを適切に処理する必要があります。 結果は解決策です。

 $ctxCur = 'web'; $ctxQur = "SELECT * FROM `".$table_prefix."context_setting` WHERE `key`='http_host' AND `value`='".$_SERVER['SERVER_NAME']."'"; $ctxSQL = $modx->prepare($ctxQur); if ($ctxSQL && $ctxSQL->execute()) if ($ctxRes = $ctxSQL->fetch(PDO::FETCH_ASSOC)) $ctxCur = $ctxRes['context_key']; $modx->initialize($ctxCur);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このソリューションを使用するときは、管理パネルのhttp_hostフィールドの正しい表示についてのみ心配する必要があります。 この場合のコンテキスト名は、サブドメインと一致する必要はありません。 シミュレーションは以上です。 私の次の自転車に注目してくれてありがとう！