💅🏼 💥 🎅 नौसिखिया MODX रेवो नोट्स ☀️ 🔷 🐥

अस्वीकरण: बेशक, सबसे अधिक संभावना है कि इस लेख में जो कुछ प्रस्तुत किया गया है वह जानकार लोगों के लिए उपयुक्त होगा। हालाँकि, शायद वह किसी की मदद करेगी ...

परिचय

तो, वास्तव में MODX क्या है (वैसे, यह उस तरह से लिखा गया है - MODX, और हब के नाम के रूप में नहीं - MODX)? यदि आप आधिकारिक साइट पढ़ते हैं - तो यह सीएमएस है। हालाँकि, यह सच्चाई का केवल एक हिस्सा है। वास्तव में, MODX CMS और CMF के बीच लगभग आधा है। हालांकि, जो कोई भी MODX में रुचि रखता है, वह अन्य लेखों से जल्दी पता लगा लेगा, इसलिए मैं इस बिंदु पर अधिक विस्तार से ध्यान नहीं दूँगा।

चूंकि MODX CMS और CMF के बीच में है, इसलिए Wordpress या Joomla जैसे सरल CMS को सीखना आसान नहीं है। शायद यह लेख कुछ ऐसी सूक्ष्मताओं को प्रकट करने के लिए लिखा गया था, जो पहली नज़र में अटपटी लगती हैं।

स्थापना

व्यक्तिगत रूप से, मैंने nginx और PHP-FPM से सुसज्जित सर्वर पर MODX Revo 2.2.4 स्थापित किया।
चूंकि MODX को आम तौर पर Apache + PHP एक्सटेंशन के लिए डिज़ाइन किया गया है, इसलिए nginx के लिए अतिरिक्त कॉन्फ़िगरेशन आवश्यक है। मेरा विन्यास कुछ इस तरह दिखता है:

nginx कॉन्फ़िगरेशन

server { listen 80; server_name example.com *.example.com; #   MODX        . index index.php index.html; root /srv/http/example.com/public; access_log /srv/http/example.com/logs/http_access.log main buffer=50k; error_log /srv/http/example.com/logs/http_error.log; #    robots.txt.      ? location = /robots.txt { access_log off; log_subrequest off; log_not_found off; } #    favicon.ico location = /favicon.ico { access_log off; log_subrequest off; log_not_found off; } #    sitemap.xml location = /sitemap.xml { access_log off; log_subrequest off; log_not_found off; } #    *.css  *.js  location ~* ^.+\.(css|js)$ { access_log off; log_subrequest off; log_not_found off; } #     ,  location ~* ^.+\.(bmp|gif|jpg|jpeg|ico|png|swf)$ { access_log off; log_subrequest off; log_not_found off; } #      ,   ,   .htaccess, .git, .svn  .. location ~ /\. { deny all; } #        MODX.        ( ),   (   ).    ,    MODX-? location / { try_files $uri $uri/ @rewrite; } #  .    - MODX     index.php?q= -       . location @rewrite { rewrite ^/(.*)$ /index.php?q=$1; } #   php-fpm location ~ \.php$ { # php-fpm.   . fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /srv/http/example.com/public; #   ,   root fastcgi_param SCRIPT_FILENAME /srv/http/example.com/public$fastcgi_script_name; #   ,   root + $fastcgi_script_name include fastcgi_params; fastcgi_param REMOTE_ADDR $remote_addr; # ,  IP   PHP   localhost-. } }

वास्तव में, यह विन्यास, मुझे यकीन है कि यह अपूर्ण है, लेकिन प्रारंभिक विन्यास के लिए, शायद उपयुक्त है। यहां रुकने के लिए केवल दो चीजें हैं, जो वास्तव में, MODX (सही ढंग से काम करने के लिए सीएनसी के लिए) को जोड़ते हैं:

  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 और बाकी सब (सही नगनेक्स CSS, JS, चित्र और PHP के बिना अन्य चीजों को लोड करना) दोनों के सही संचालन के लिए पर्याप्त लगता है।
स्थापना स्वयं बहुत सरल है, बस वांछित फ़ोल्डर में फ़ाइलों को अनज़िप करें और उन्हें पता बार example.com/setup/ में ड्राइव करें, जिसके बाद एक साधारण इंस्टॉलर लोड हो जाएगा।

मानव-अनुकूल URL (सीएनसी)

डिफ़ॉल्ट रूप से, MODX में सीएनसी अक्षम है। यह बहुत सरल रूप से चालू होता है: सिस्टम -> सिस्टम सेटिंग्स -> फिल्टर में "friendly_urls" ड्राइव करें और एंटर दबाएं (आप, निश्चित रूप से इसे खोजने के लिए हैंडल का उपयोग कर सकते हैं, लेकिन तेजी से) -> मूल्य को "हां" पर स्विच करें और शीर्ष पर "सहेजें" पर क्लिक करें।
सामान्य तौर पर, यह मत भूलो कि MODX में सेव बटन टॉप राइट कॉर्नर में है। कभी-कभी आप इसके बारे में भूल सकते हैं, और फिर सेटिंग्स खो सकती हैं - क्योंकि MODX में कभी-कभी ऑटोसैव ट्रिगर होता है, और कभी-कभी नहीं।
इसी तरह, हम सीएनसी के स्वचालित उत्पादन के लिए फ़ंक्शन "ऑटोमैटिक_लियास" के लिए करते हैं।
हमने सफलतापूर्वक सीएनसी चालू कर दिया है, और अब लिंक निम्नानुसार बनेंगे:

 example.com/resourcename.html

कृपया ध्यान दें कि .html अंत में डाला गया है! यह प्रत्येक व्यक्तिगत संसाधन की सामग्री-प्रकार पर निर्भर करता है (संसाधन के गुणों में परिवर्तन)। सामग्री-प्रकारों के लिए सेटिंग्स सिस्टम -> सामग्री प्रकारों में पाई जा सकती हैं।
हालाँकि, सभी अतिरिक्त GET पैरामीटर वैसे भी समान हैं, और यह निम्नानुसार काम करता है:

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

व्यक्तिगत रूप से, मुझे इस तरह की व्यवस्था पसंद नहीं थी, और मैंने इन मापदंडों को सीएनसी का हिस्सा बनाने के तरीकों की तलाश शुरू कर दी। और पाया!
शुरुआत के लिए, यह उन विभिन्न तत्वों के बारे में थोड़ी बात करने लायक है जो आपको MODX का विस्तार करने की अनुमति देते हैं। उनमें से कई हैं:

टेम्पलेट चर - अतिरिक्त संसाधन संपत्ति फ़ील्ड। हम थोड़ी देर बाद उनके पास लौट आएंगे
चंक्स - HTML कोड के ब्लॉक (संभव MODX मार्कअप के साथ) जिसे किसी भी अन्य चंक, संसाधन या आम तौर पर कहीं भी डाला जा सकता है। चेतावनी! यहाँ PHP नहीं डाली जा सकती है!
स्निपेट्स PHP कोड के ब्लॉक हैं जो कुछ डेटा को उस स्थान पर डालते हैं जहां इसे डाला जाता है (MODX मार्कअप का उपयोग करके)। चंक्स की एक तरह की PHP एनालॉग।
प्लग इन PHP कोड के ब्लॉक हैं जिन्हें MODX के अंदर होने वाली कुछ घटनाओं के अनुसार निष्पादित किया जाता है। ड्रुपल हुक जैसा कुछ, शायद।

इस मामले में, हमें स्निपेट्स और प्लगइन्स की आवश्यकता है।
तो, आप अपने स्वयं के URL प्रारूप के साथ MODX में कैसे एकीकृत करते हैं? वास्तव में, यह बहुत ही सरल है - बता दें कि MODX दिए गए URL पर पृष्ठ खोजने की कोशिश करता है, और जब यह नहीं मिलता है - नियंत्रण और पार्स करें, जिसके बाद MODX भेजें जहां यह होना चाहिए। ऐसा करने के लिए, OnPageNotFound इवेंट के लिए प्लगइन का उपयोग करें।

उन्नत सीएनसी के लिए प्लगइन कोड

 <?php if($modx->request->getResourceMethod()!="alias") return; $uri = $modx->resourceIdentifier; $uriChunks = explode("/", $uri); $paramNum=0; $uriChunksCount = count($uriChunks); $paramDelimiter="-"; //DO NOT use "/"! Set the desired delimiter here. for($i=$uriChunksCount-1;$i>0;$i--) { $parameter=explode($paramDelimiter, $uriChunks[$i], 2); if(count($parameter)!=2) return; $modx->request->parameters['GET'][$parameter[0]]=$parameter[1]; if(empty($modx->request->parameters['POST'][$parameter[0]])) $modx->request->parameters['REQUEST'][$parameter[0]]=$parameter[1]; $paramNum++; unset($uriChunks[$i]); $uri = implode("/", $uriChunks); if (array_key_exists($uri, $modx->aliasMap)) { $modx->sendForward($modx->aliasMap[$uri]); } } if($paramNum==($uriChunksCount-1)) { $parameter=explode($paramDelimiter, $uriChunks[0], 2); if(count($parameter)!=2) return; $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->sendForward($modx->getOption('site_start', null, 1)); }

दरअसल, यहाँ शायद यह निम्नलिखित चीजों पर रोक के लायक है:

 $modx->request->getResourceMethod()

जाँच करता है कि क्या सीएनसी बिल्कुल चालू है।

 $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]); }

और यह वास्तव में वांछित संसाधन के लिए एक अनुप्रेषित है। संपूर्ण सीएनसी तालिका को $ modx-> उपनाम में संग्रहीत किया गया है, और हम यह पता लगाने के लिए इसे जांचते हैं कि क्या हमारे लिए वांछित संसाधन पर जाने का समय है, या यदि हमारे अंडररेटेड यूरी की सामग्री में अभी भी पैरामीटर शामिल हैं। $ modx-> भेजने और इस पुनर्निर्देशन करता है।

हालाँकि, मैं संभवत: तुरंत लिंक देना चाहता हूं, उदाहरण के लिए, इस 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 बनाता है। संदर्भ के लिए - यह संदर्भ के सापेक्ष बनाता है - दूसरा पैरामीटर केवल संदर्भ सेट करता है।

MODX में मल्टीसाइट

एक ही MODX के साथ विभिन्न संदर्भों में कई डोमेन संसाधित करना

दरअसल, यह विषय पहले से ही उठाया गया है, उदाहरण के लिए, इस विषय में और इंटरनेट पर । मैं अपना निर्णय प्रस्तुत करना चाहूंगा, यह मुझे बहुत सरल लगता है। लेकिन पहले, मैं इस समस्या को हल करने के मुख्य तरीकों की सूची दूंगा:

संपादन index.php। Index.php स्पष्ट रूप से इंगित करता है कि किस संदर्भ को स्टार्टअप पर लोड किया गया है। इसे पूरी तरह से सुधारा जा सकता है, और अपनी शर्तों को अपनी संदर्भ की पसंद से स्थानापन्न कर सकते हैं। मुझे यह तरीका पसंद क्यों नहीं है: मूल modx फ़ाइलों का संपादन। मुझे यह तथ्य क्यों पसंद नहीं है? अपडेट के साथ कठिनाई। जो मुझे बहुत पसंद है (और एसएमएफ फोरम इंजन की तरह मुझे पसंद नहीं है) वह यह है कि इसमें किसी भी मूल MODX फाइल को बदलने की आवश्यकता नहीं है, जो इंजन को यथासंभव आसान बनाता है।
OnHandleRequest इवेंट (एक सामान्य दोष: थोड़ा और अधिक संसाधनों का उपयोग करने के लिए एक प्लगइन बनाना - वेब संदर्भ हमेशा पहले लोड किया जाता है, और उसके बाद ही आवश्यक संदर्भ लोड होता है):
1. संपादन index.php के समान, लेकिन इसे संपादित किए बिना। सब कुछ लगभग समान है - उन डोमेन की एक सूची जो संदर्भों की एक कठोर परिभाषित सूची द्वारा संसाधित होती है, हार्ड-कोडित होती है। वैकल्पिक रूप से, संदर्भ नाम में डोमेन नाम (मंच के लिए मंच संदर्भ ।example.com उपडोमेन, उदाहरण के लिए) शामिल है, जिसके आधार पर आवश्यक संदर्भ की खोज की जाती है।
2. सही खोजने के लिए संदर्भ सेटिंग्स स्कैन करें। अधिकतम लचीलापन, संदर्भों का ऑटो-निर्माण, इसके निर्माण के बाद प्लगइन को संपादित करने की कोई आवश्यकता नहीं है।

मैं यहाँ केवल अंतिम विकल्प का वर्णन करने जा रहा हूँ। मेरा प्लगइन पाठ (याद करें, OnHandleRequest घटना):

गेटवे प्लगइन

 <?php if($modx->context->key!="mgr") { $object = $modx->getObject('modContextSetting', array('key' => 'multisite_http_host', 'value' => $modx->getOption('http_host'))); if($object) $modx->switchContext($object->get('context_key')); }

उपयोग के लिए, संदर्भ गुण में पैरामीटर "multisite_http_host" को सेट करने के लिए आवश्यक है, जिसके मूल्य के साथ डोमेन प्रक्रिया होती है। यदि प्लगइन को कोई उपयुक्त संदर्भ नहीं मिलता है, तो वह डिफ़ॉल्ट रूप से वेब संदर्भ का उपयोग करता है।
यहां मैं दो बातों पर ध्यान देना चाहता हूं।
सबसे पहले, 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 कॉन्फ़िगरेशन कुंजी)। जिसके बाद हमें संदर्भ कुंजी मिलती है, जिसे हमें लोड करने की आवश्यकता होती है, पहले से ही प्राप्त वस्तु ($ ऑब्जेक्ट-> मिलता है ("संदर्भ_की"))।
दूसरे, हैबेरसर XanderBass ने सही सवाल पूछा, जिसका जवाब मैं यहां नकल करना चाहूंगा। तो मैं पैरामीटर नाम का उपयोग क्यों कर रहा हूँ "multisite_http_host" और न केवल "http_host"?
सब कुछ बहुत सरल है, यह सिस्टम सेटिंग्स, संदर्भ और उपयोगकर्ता के संयोजन के तंत्र से निम्नानुसार है। तथ्य यह है कि सिस्टम सेटिंग्स को संदर्भ सेटिंग्स द्वारा अधिलेखित किया जाता है, और जो बदले में, उपयोगकर्ता सेटिंग्स हैं।
इस स्थिति में, http_host सिस्टम सेटिंग है। यदि मैंने संदर्भ सेटिंग में multisite_http_host के बजाय http_host का उपयोग किया है, तो इसे संदर्भ सेटिंग द्वारा मिटा दिया जाएगा। बेशक, इस विशेष उदाहरण में, यह इतना डरावना नहीं है। लेकिन एक संदर्भ में किसी दिए गए डोमेन के सभी उप-डोमेन को संसाधित करने के लिए बस इस प्लगइन को फिर से लिखें! या, कई अलग-अलग डोमेन के एक संदर्भ में प्रसंस्करण करें (उदाहरण के लिए, लगभग इस प्रारूप में एक पैरामीटर में ड्राइविंग: सब 1 .example.com; सब 2.example.com; सब 3.example.com, आदि)। इस मामले में, http_host में यह अनुरोध के लिए उपयोग की जाने वाली http_host नहीं होगी, लेकिन यह बहुत ही सेटिंग है, लेकिन आप कभी नहीं जानते हैं, शायद हमें मूल http_host की आवश्यकता कहीं और है ...

एकाधिक संदर्भ

कभी-कभी आप एक उपयोगकर्ता को एक साथ कई संदर्भों में प्रमाणित करना चाहते हैं। डिफ़ॉल्ट रूप से, एक उपयोगकर्ता जो सिस्टम में लॉग इन करता है (उदाहरण के लिए, लॉगिन मॉड का उपयोग करके) केवल एक ही संदर्भ में सिस्टम में लॉग करता है। निम्नलिखित प्लगइन स्वचालित रूप से प्राधिकरण के दौरान कई संदर्भों में लॉग ऑन करता है ( OnWebLogin और OnWebLogout ईवेंट्स ):

Multiautentifikatsiya

 <?php $currentSiteGroup = $modx->getOption("multisite_site_group"); if(empty($currentSiteGroup)) return; $currentContext = $modx->context->get("key"); $currentContextSettings = $modx->getCollection('modContextSetting', array('key' => "multisite_site_group", "value" => $currentSiteGroup)); foreach($currentContextSettings as $currentContextSetting) { $contextKey = $currentContextSetting->get('context_key'); if($contextKey!="mgr" && $contextKey!=$currentContext) { if($user) { if($modx->event->name=="OnWebLogout") { $modx->user->removeSessionContext($contextKey); } else if($modx->event->name=="OnWebLogin") { $modx->user->addSessionContext($contextKey); $_SESSION['modx.'.$contextKey.'.session.cookie.lifetime']=$attributes["lifetime"]; } } } }

उपयोग के लिए, सभी संदर्भों के लिए सभी आवश्यक संदर्भों के लिए एक ही मान के साथ पैरामीटर "multisite_site_group" सेट करना आवश्यक है जो आप चाहते हैं कि उपयोगकर्ता एक ही समय में लॉग इन करें।
बस कुछ टिप्पणियाँ:
यहां, आवश्यक संदर्भों की खोज बहुत ही समान है कि हमने उन्हें पिछले प्लगइन में कैसे लागू किया, एकमात्र अंतर getObject के बजाय getCollection का उपयोग है। ऐसा करने से, हमें एक ऑब्जेक्ट मिलता है जो निर्दिष्ट शर्तों का पालन करता है।

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

और

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

बस इस या उस संदर्भ में उपयोगकर्ता के प्राधिकरण को पूरा करें।

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

अन्य सभी संदर्भों के लिए प्राधिकार के "आजीवन" को वर्तमान के लिए समान रूप से प्रस्तुत करता है।

फिलहाल, यह सब कुछ ऐसा लगता है जो मैं बताना चाहता था। स्विचिंग भाषाओं के साथ विकास शायद बाद में होगा, जब मैं उन्हें कुछ हद तक संशोधित करूंगा। आपका ध्यान देने के लिए आप सभी का धन्यवाद!