👄 🖥️ ⤵️ एकल YII उदाहरण पर साइटों के कई संस्करण कैसे परिनियोजित करें 🔰 🕵️ 🤙🏿

इस लेख में, हम यह वर्णन करेंगे कि हमने yii फ्रेमवर्क पर एक परियोजना में अपनी साइटों के काम को कैसे व्यवस्थित किया। पहले भाग में, हम थोड़ा सिद्धांत देते हैं कि किन मामलों में इसकी आवश्यकता हो सकती है और इसके लिए क्या आवश्यक है। और दूसरे भाग में हम तकनीकी कार्यान्वयन के लिए आगे बढ़ते हैं।

भाग 1

परिचय

कई कंपनियां विभिन्न बाजारों में अपने उत्पादों को बढ़ावा देने के लिए कई साइटों के संचालन का समर्थन करती हैं। तो हम करते हैं। हमारे पास रूसी, अमेरिकी, यूरोपीय और अन्य बाजारों के लिए साइटें हैं, मोबाइल उपकरणों के लिए अलग-अलग साइटें हैं, सहबद्ध कार्यक्रमों की साइटें हैं, जो विभिन्न देशों के लिए भी अलग हैं। विकास में, हम yii फ्रेमवर्क का उपयोग करते हैं, जिसके लिए हमने पिछले साल अपनी मुख्य साइट Alawar.ru स्थानांतरित की, और इस साल भी Alawar.com, Alawar.pl और iOS डिवाइस साइटें। Yii पर हमारी साइटों की तैनाती की एक विशेषता यह है कि वे सभी इस अद्भुत रूपरेखा के एक उदाहरण पर काम करते हैं।

इस समस्या को हल करने में कोई समस्या नहीं है, हम एक विशिष्ट कार्यान्वयन पर विचार करेंगे।

साइट अंतर

एक ही मंच पर कई साइटों की व्यवस्था करने के तरीके को समझने के लिए, आपको यह पता लगाने की आवश्यकता है कि उनके पास क्या है और वे कैसे भिन्न हैं। बस यह नोट करना चाहते हैं कि विभिन्न साइटों से हमारा मतलब है कि न केवल स्थानीयकरण में अंतर, जो कि विभिन्न Yii::t('messageFile', 'messageCode') विचारों और विभिन्न messageFile में भिन्न-भिन्न स्थानों के लिए messageFile ।

और साइट में अलग चीजें हो सकती हैं:

सामग्री;
फ्रंटेंड मॉड्यूल की कार्यक्षमता;
थीम / खाल;
भाषा / स्थानीयकरण।

हम प्रत्येक आइटम का विस्तार से विश्लेषण करेंगे।

भरने

भरने से हमारा मतलब विभिन्न साइटों के लिए अलग-अलग सामग्री से है। चूंकि साइटें विभिन्न देशों के लिए भिन्न होती हैं, जिसका अर्थ है कि वे विभिन्न बाजारों में उत्पाद बेचते हैं, तो एक बाजार में बिक्री के लिए पेश किए जाने वाले उत्पादों को कभी-कभी दूसरे में बिक्री से हटा दिया जाना चाहिए। विभिन्न साइटों में अलग-अलग विशेष ऑफ़र हो सकते हैं और उनके आगंतुकों के लिए अलग-अलग छूट हो सकती है।

अंत में, यहां तक कि स्थिर सूचना पृष्ठ भी भिन्न हो सकते हैं। इस प्रकार, हमें ढांचे के एक उदाहरण के साथ डेटा विसंगतियों को हल करने में सक्षम होना चाहिए।

व्यक्तिगत ब्लॉक / फ्रंटेंड मॉड्यूल की कार्यक्षमता

उदाहरण के लिए, Alawar.com की वेबसाइट पर असीमित कार्यक्षमता है - उपयोगकर्ता के लिए सभी खेलों के लिए इसी लागत के लिए सदस्यता। Alawar.pl भी उपयोगकर्ताओं को यह कार्यक्षमता प्रदान करता है, लेकिन अंग्रेजी साइट से अलग सदस्यता विकल्प प्रदान करता है। रूसी साइट पर, असीमित का काम बिल्कुल भी प्रदान नहीं किया गया है।

थीम्स / खाल

इस अनुच्छेद में, विभिन्न विकल्प संभव हैं:

विभिन्न साइट विषय (उदाहरण के लिए, एक मोबाइल साइट में मुख्य एक से अलग विषय है)।
साइटों के समान थीम, लेकिन विभिन्न डिज़ाइन विकल्प (उदाहरण के लिए, 9 मई को Alawar.ru पर एक उत्सव की त्वचा या 4 जुलाई को Alawar.com पर एक त्वचा)।

Yii इंजन के लिए थीम बनाना सीखना मुश्किल नहीं है। रूपरेखा में संरचनात्मक रूप से विषयों को विभाजित करके, साइटों पर डिज़ाइन को विभाजित करने का मुद्दा हल किया गया है।

भाषा / स्थानीयकरण

और केवल अंतिम स्थान में स्थानीयकरण है, जिसका उल्लेख ऊपर किया गया था।

साइट समानताएँ

अब देखते हैं कि सभी साइटों में क्या आम है।

सबसे महत्वपूर्ण समानता और एकमात्र महत्वपूर्ण और पर्याप्त कारण है कि आपको एक ही मंच पर अलग-अलग साइटें क्यों बनानी चाहिए, एक ही बैकएंड है। यदि आपकी साइटों पर बैकएंड अलग है, तो शायद आपको उन्हें एक प्रोजेक्ट में नहीं मिलाना चाहिए। हां, हम विभिन्न साइटों पर बिक्री के लिए विभिन्न उत्पादों का चयन करते हैं। लेकिन सभी उत्पाद एक ही डेटाबेस में हैं और एक ही व्यवस्थापक क्षेत्र में उपलब्ध हैं। हम विभिन्न साइटों के लिए अलग-अलग खाल खींचते हैं, लेकिन वे सभी एक विषय पर खराब हो सकते हैं। खासकर अगर बैकएंड mysql व्यवस्थापक क्षेत्र तक सीमित नहीं है।

हमारे मामले में, बैकएंड का मतलब है:

जटिल mysql-admin, एक अलग सर्वर पर स्थित है, जो दूसरे CMS पर लिखा गया है;
rabimq के माध्यम से yii प्रोजेक्ट के बैकएंड में इस व्यवस्थापक पैनल से डेटा भेजना;
mysql और nosql डेटा दोनों में yii बैकएंड शार्पेबल का गठन;
स्फिंक्स द्वारा अनुक्रमित डेटा।

कल्पना कीजिए कि प्रत्येक नई साइट के लिए आपको इन सभी तकनीकों को खरोंच से उठाना होगा।

कार्य

हमारी साइटों की समानता और अंतर की तुलना को सारांशित करते हुए, हम यह निर्धारित करते हैं कि साइटों के बीच क्या कार्य विभाजित किए जाने चाहिए:

एक सामान्य बैकएंड को बनाए रखते हुए विभिन्न साइटों पर अलग और / या अद्वितीय सामग्री प्रदर्शित करें।
अलग-अलग साइट मॉड्यूल की कार्यक्षमता को एक-दूसरे से अलग करने की क्षमता।
विभिन्न विषयों या विभिन्न त्वचा विषयों, विभिन्न पाठ स्थानीयकरणों के लिए समर्थन।

भाग २

साइट परिभाषा के लिए कॉन्फ़िगर करें

इस लेख में, हम एप्लिकेशन को दो साइटों: रूसी और अंग्रेजी: में अलग-अलग दिखाएंगे। वास्तव में, इस तरह से आप अपनी ज़रूरत के अनुसार कई साइटों को विभाजित कर सकते हैं।

हम यह निर्धारित कर सकते हैं कि निम्नलिखित मापदंडों द्वारा किस स्थिति में कौन सी साइट प्रदर्शित की जाए:

वह डोमेन जिससे उपयोगकर्ता आया था;
डिवाइस के उपयोगकर्ता-एजेंट द्वारा;
कुकी / सत्र में डेटा से साइटों पर रूपांतरणों के इतिहास पर।

निम्नलिखित सामग्री के साथ एक protected/config/sites.php बनाएँ:

 <?php return array( 'mywebsite.ru' => array( 'host' => array( 'mywebsite.ru', 'www.mywebsite.ru', ), 'userAgent' => false, ), 'mywebsite.com' => array( 'host' => array( 'mywebsite.com', 'www.mywebsite.com', ), 'userAgent' => false, ), );

इस उदाहरण में, हम केवल डोमेन द्वारा साइट की परिभाषा का विश्लेषण करेंगे। हमारे मामले में, उपयोगकर्ता एजेंट की परिभाषा का उपयोग नहीं किया जाता है, इसलिए, 'userAgent' => false निर्दिष्ट करें। यह कुंजी उस स्थिति के लिए सेट की जाती है जब एक डोमेन को विभिन्न संस्करणों के साइट्स दिखाने की आवश्यकता होती है।

अलग-अलग साइटों के लिए अलग-अलग कॉन्फ़िगरेशन

हम प्रत्येक साइट के लिए अपनी अनूठी सेटिंग्स के साथ एक अलग कॉन्फ़िगरेशन फ़ाइल बनाएंगे। और इन फ़ाइलों को उपरोक्त सरणी में कुंजियों के नाम दें। अर्थात्, फ़ाइलें बनाएँ:
protected/config/mywebsite.ru.php
protected/config/mywebsite.com.php

नीचे फ़ाइल की सामग्री protected/config/mywebsite.ru.php :

 <?php return CMap::mergeArray( array( 'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..', 'name'=>'Application name', 'theme' => 'mywebsite', 'language' => 'ru', 'modules'=>array( ), 'controllerMap'=>array( 'site'=>'application.sites.common.controllers.SiteController', 'promo'=>array( 'class' => 'application.sites.mywebsite-ru.controllers.PromoController', 'viewPrefix' => '/mywebsite-ru/promo/', ), 'support'=>array( 'class' => 'application.sites.common.controllers.SupportController', 'viewPrefix' => '/mywebsite-ru/support/', ), ), 'components'=>array( 'urlManager'=>array( 'urlFormat'=>'path', 'showScriptName' => false, 'urlSuffix' => '/', 'rules' => array( '' => 'site/index', 'promo/' => 'promo/index', 'support/' => 'support/index', ), ), 'errorHandler'=>array( 'errorAction'=>'site/error', ), ), 'params'=>array( 'adminEmail'=>'admin@mywebsite.ru', 'arCustomParams' => array( 'customBannerPath' => '/promo/mywebsite.ru/promo-banner.png' ), ), ), require_once(dirname(__FILE__).'/main.php') );

जैसा कि आप देख सकते हैं, हमने अलग-अलग फ़ाइलों के लिए सभी साइट-विशिष्ट सेटिंग्स को स्थानांतरित कर दिया, जो विशिष्ट साइटों के कॉन्फ़िगरेशन हैं। इस कॉन्फ़िगरेशन में साइट का नाम, विषय, स्थान परिभाषित हैं।

विशेष साइट सामग्री को लागू करने या विशेष अनुरोधों को संसाधित करने के लिए, हम अलग-अलग नियंत्रकों को कस्टम तर्क युक्त जारी करेंगे। हम उन तरीकों को परिभाषित करते हैं जिनमें सभी साइटों और साइट-विशिष्ट नियंत्रकों के लिए आम उपलब्ध होगा। controllerMap पैरामीटर में इस साइट का उपयोग करने वाले controllerMap निर्दिष्ट हैं:

  'controllerMap'=>array( 'site'=>'application.sites.common.controllers.SiteController', 'promo'=>array( 'class' => 'application.sites.mywebsite-ru.controllers.PromoController', 'viewPrefix' => '/mywebsite-ru/promo/', ), 'support'=>array( 'class' => 'application.sites.common.controllers.SupportController', 'viewPrefix' => '/mywebsite-ru/support/', ), ),

यहाँ हम देखते हैं कि mywebsite.ru दोनों साइटों के लिए सामान्य रूप से SiteController का उपयोग करता है। इस नियंत्रक के लिए प्रदर्शन पथ मानक होगा, कोई अतिरिक्त संकेत की आवश्यकता नहीं है।
PromoController , इसके विपरीत, केवल इस साइट पर लागू होता है, क्योंकि केवल किसी विशेष साइट पर लागू विभिन्न प्रचार पर डेटा हो सकता है। SupportController दोनों साइटों के बीच साझा किया जाता है, लेकिन इस नियंत्रक के लिए कस्टम मैपिंग का उपयोग किया जाता है।

प्रत्येक सामने render फ़ंक्शन के पुनर्परिभाषित के साथ इस संपत्ति को परिभाषित किए बिना सभी फ्रंट-एंड नियंत्रकों में viewPrefix प्रॉपर्टी के सही प्रसंस्करण को प्राप्त करने के लिए, हम protected/components/AController.php क्लास से विरासत में प्राप्त protected/components/AController.php क्लास बनाएंगे:

 <?php /** * Controller is the customized base controller class. * All controller classes for this application should extend from this base class. */ class AController extends CController { /** * @var string the default layout for the controller view. Defaults to '//layouts/column1', * meaning using a single column layout. See 'protected/views/layouts/column1.php'. */ public $layout='//layouts/main'; public $baseHref=false; public $viewPrefix=''; /** * @var array context menu items. This property will be assigned to {@link CMenu::items}. */ public $menu=array(); /** * @var array the breadcrumbs of the current page. The value of this property will * be assigned to {@link CBreadcrumbs::links}. Please refer to {@link CBreadcrumbs::links} * for more details on how to specify this property. */ public $breadcrumbs=array(); /** * @var string page description */ public $pageDescription = ''; public function render($view,$data=null,$return=false) { return parent::render($this->viewPrefix.$view,$data,$return); } }

हमारे आवेदन में सभी फ्रंटएंड नियंत्रक इस वर्ग से विरासत में मिलेंगे। इसमें, हमने viewPrefix प्रॉपर्टी को परिभाषित किया और, इसे ध्यान में रखते हुए, render($view,$data=null,$return=false) विधि render($view,$data=null,$return=false) फिर से परिभाषित किया, जो हमें दिए गए उपसर्ग द्वारा नियंत्रकों के प्रदर्शन को संरचनात्मक रूप से अलग करने की अनुमति देता है।

यह एक लचीली प्रणाली है जो आपको केवल उन डिस्प्ले / कंट्रोलर को बनाने की अनुमति देती है जो इतने भिन्न होते हैं कि उनके लिए अलग-अलग फ़ाइलों का उपयोग करने के लायक है। चूंकि हमारी सभी साइटें एक ही बैकएंड का उपयोग करती हैं, हमें केवल फ्रंटएंड लॉजिक को साझा करना चाहिए, अर्थात्। नियंत्रकों और विचारों, और मॉडल, रूप, घटक, एक्सटेंशन, और बाकी सब कुछ हमेशा सभी साइटों के लिए सामान्य हैं। साथ ही URL प्रेषण विभिन्न साइटों पर अलग-अलग होगा। इसलिए, हम एक अलग कॉन्फ़िगरेशन में urlManager । वैसे, सभी साइट के लिए सामान्य सभी अन्य सेटिंग्स, हमेशा की तरह, मुख्य। main.php फ़ाइल में संग्रहीत की जाती हैं, जो CMap::mergeArray माध्यम से वर्तमान के साथ विलीन हो जाती है CMap::mergeArray

SiteDispatcher

हम सभी नियंत्रक और डिस्प्ले बनाएंगे जो हमारी साइटों द्वारा उपयोग किए जाएंगे। हम निम्नलिखित फाइलें और उनके लिए आवश्यक फ़ोल्डर बनाते हैं:
protected/sites/common/controllers/SiteController.php
protected/sites/common/controllers/SupportController.php
protected/sites/mywebsite-ru/controllers/PromoController.php
protected/sites/mywebsite-com/controllers/PromoController.php
public/themes/mywebsite/views/site/index.php
public/themes/mywebsite/views/mywebsite-ru/promo/index.php
public/themes/mywebsite/views/mywebsite-ru/support/index.php
public/themes/mywebsite/views/mywebsite-com/promo/index.php
public/themes/mywebsite/views/mywebsite-com/support/index.php

बनाए गए प्रत्येक नियंत्रक को AController क्लास से विरासत में प्राप्त होना चाहिए। इस प्रकार, हम YII के मानक ढांचे का थोड़ा उल्लंघन करेंगे, लेकिन चिंता की कोई बात नहीं है। हमने परियोजना की तार्किक संरचना को बनाए रखा।

हमारे द्वारा बनाए गए कॉन्फ़िगरेशन का उपयोग करके आवश्यक नियंत्रकों को लॉन्च करने के लिए yii सिखाने के लिए, हम एक अलग घटक वर्ग protected/omponents/SiteDispatcher , जिनमें से कार्य एक विशिष्ट स्थिति के लिए वांछित कॉन्फ़िगरेशन फ़ाइल का चयन करना है:

 <?php class SiteDispatcher { //      public static function setCurrentSiteConfig( $configName ) { @session_start(); $_SESSION['CURRENT_SITE_CONFIG'] = array( 'host' => $_SERVER['HTTP_HOST'], 'configName' => $configName ); @session_write_close(); @session_destroy(); } //       public static function getCurrentSiteConfig() { @session_start(); $res = isset( $_SESSION['CURRENT_SITE_CONFIG'] ) ? $_SESSION['CURRENT_SITE_CONFIG'] : false; @session_write_close(); @session_destroy(); return $res; } public static function getConfigPath() { $arSites = self::getAvailableConfigs(); /*      ,     ,   ,   -          */ if ( ($arCurrent = self::getCurrentSiteConfig()) && $arCurrent['host'] == $_SERVER['HTTP_HOST'] && isset($arSites[$arCurrent['configName']]) ) { return 'protected/config/' . $arCurrent['configName'] . '.php'; } foreach ( $arSites as $configName => $arSiteConfig ) { $res = true; $res &= in_array( $_SERVER['HTTP_HOST'], $arSiteConfig['host'] ); if ( $res && $arSiteConfig['userAgent'] && isset( $_SERVER['HTTP_USER_AGENT'] ) ) { $m = false; $res &= preg_match( $arSiteConfig['userAgent'], $_SERVER['HTTP_USER_AGENT'], $m); } if ( $res ) { return 'protected/config/' . $configName . '.php'; } } error_log('Can\'t determine config to site: ' . var_export( array( 'host' => $_SERVER['HTTP_HOST'], 'userAgent' => $_SERVER['HTTP_HOST'], ), 1)); throw new Exception('Can\'t determine config to site'); } /** * * @static * @return mixed */ protected static function getAvailableConfigs() { return require( dirname(dirname(__FILE__)) . '/config/sites.php' ); } }

अब हम यह निर्धारित कर सकते हैं कि किस मामले में कौन सा कॉन्फिगर चलाना है। getConfigPath() विधि चयनित getConfigPath() का पथ लौटाती है। इसी समय, आगे की पहुंच की सुविधा के लिए सत्र में चयनित कॉन्फ़िगरेशन को सहेजा जाता है।

इस विधि को कॉल करने के लिए, index.php फ़ाइल की शुरुआत में, लाइन को बदलें

 $config=dirname(__FILE__).'/../protected/config/main.php';

पर

 require dirname(__FILE__).'/../protected/components/SiteDispatcher.php'; $config=dirname(__FILE__).'/../'.SiteDispatcher::getConfigPath();

इस प्रकार, अलग-अलग साइटों के लिए कॉन्फ़िगरेशन, कुछ नियंत्रक और मैपिंग को अलग करके, हमने पहले भाग में निर्धारित पहले दो कार्यों को हल किया।

त्वचा का अलग होना

अलग-अलग साइटों के लिए अपनी स्वयं की खाल का उपयोग करना साइट कॉन्फ़िगरेशन में स्थान निर्दिष्ट करके तय किया जाता है। एक नियम के रूप में, एक त्वचा एक थीम और छवि की अलग सीएसएस और जेएस फाइलें है। हमारी परियोजना में, हम कुछ वैश्विक सीएसएस और जेएस फाइलों का उपयोग करते हैं जो सभी साइटों के लिए विषय के संरचनात्मक लेआउट को परिभाषित करते हैं। साथ ही अलग स्थानीय सीएसएस और जेएस जो इस संरचना के डिजाइन को परिभाषित करते हैं। इन सभी शैलियों और लिपियों को हमारे अपने मिनीफ़ायर द्वारा एक फ़ाइल के परिणामस्वरूप एकत्र किया जाता है और निम्नानुसार लेआउट में जोड़ा जाता है:

 <link rel="stylesheet" type="text/css" href="<?php echo Yii::app()->theme->baseUrl . '/css/'. Yii::app()->getLanguage() .'/main.minified.css'; ?>" /> <script type="text/javascript" src="<?php echo Yii::app()->theme->baseUrl . '/js/' . Yii::app()->getLanguage() . '/main_minified.js'; ?>"></script>

चूँकि Yii::app()->getLanguage() एक विशेष साइट के लिए एक अलग कॉन्फिग फाइल में परिभाषित लोकेल को लौटाता है, थीम स्ट्रक्चर में एक ही नाम के फोल्डर बनाकर हम अपनी css और js फाइल्स को वहां सेव कर सकते हैं। यह केवल मिनिफाइज़र को अंतिम रूप देने के लिए बना हुआ है, जो सभी फाइलों को एक में इकट्ठा करता है ताकि यह लोकेल के साथ काम करने का समर्थन करे। लेकिन यह एक अलग लेख के लिए एक विषय है।

अलग-अलग, मैं हमारी साइटों पर काउंटर रखने के मुद्दे को नोट करना चाहता हूं। कई अलग-अलग स्क्रिप्ट, गूगल एनालिटिक्स, यैंडेक्स मेट्रिक, एडथिस और अन्य हैं। विभिन्न साइटों के लिए, विभिन्न काउंटरों का उपयोग किया जाता है। Yii::app()->getLanguage() साथ बैसाखी से छुटकारा पाने के लिए किसी विशेष साइट पर वांछित काउंटर को सही ढंग से प्रदर्शित करने के लिए स्विच करें, हमने काउंटरों को स्थानीयकरण फ़ाइलों में स्थानांतरित करने का निर्णय लिया।

फ़ाइलें बनाएँ:
protected/messages/ru/scripts.php
protected/messages/en/scripts.php

निम्नलिखित कोड उन्हें जोड़ें:

 <?php return array ( 'GoogleAnalitics' => ' <!-- GoogleAnalitics begin --> <script type="text/javascript"> //    RU </script> <!-- GoogleAnalitics end --> ', );

अब मैपिंग फ़ाइलों में वांछित साइट के लिए वांछित कोड प्रदर्शित करने के लिए echo Yii::t('scripts', 'GoogleAnalitics') को कॉल करना पर्याप्त है।

निष्कर्ष

साइटों को साझा करने के हमारे तरीके के साथ-साथ अन्य तरीके भी हैं जिन्हें आप खुद इस्तेमाल करते हैं।

आपका ध्यान के लिए धन्यवाद!

एकल YII उदाहरण पर साइटों के कई संस्करण कैसे परिनियोजित करें