संगीतकार का उपयोग करके सीएमएस के लिए अपने मॉड्यूल का प्रबंधन करना

नमस्कार दोस्तों! PHP में एक लोकप्रिय निर्भरता प्रबंधक का उद्भव PHP समुदाय के जीवन की सबसे महत्वपूर्ण घटनाओं में से एक है। संगीतकार ने समय को "पहले" में विभाजित किया है - जब हमारे स्व-लिखित पुस्तकालय ज़िप अभिलेखागार में थे या बस फ़ोल्डर्स में बिखरे हुए थे और "पेन" द्वारा कॉपी किए गए थे, केवल दुर्लभ मामलों में ही गिट या पीईआर का उपयोग किया गया था, और "बाद में" जब हमने संगीतकार शुरू किया था। लेकिन क्या होगा यदि आप एक विशिष्ट सीएमएस के साथ काम करते हैं, लेकिन यह "पता नहीं" है कि संगीतकार क्या है?

प्रस्तावना

मैं एक छोटे से वेब-स्टूडियो में एक टीम लीड के रूप में काम करता हूं और लगभग एक साल पहले मुझे अपनी टीम में सर्वश्रेष्ठ प्रथाओं का उपयोग करने के दृष्टिकोण पर पुनर्विचार करना पड़ा। परियोजनाओं के विकास के लिए, 70% से अधिक कार्यक्षमता जिनमें से मानक (वेबसाइट, ऑनलाइन स्टोर) कहा जा सकता है, हम 1C-Bitrix का उपयोग करते हैं। सभी लोकप्रिय सीएमएस की तरह 1C-Bitrix में एक मॉड्यूलर संरचना होती है और तीसरे पक्ष के मॉड्यूल की स्थापना का समर्थन करता है। यह अच्छा लगता है, लेकिन वास्तव में यह थोड़ा अलग है। आप अपने स्वयं के मॉड्यूल को विकसित कर सकते हैं और स्रोत कोड को आवश्यक फ़ोल्डरों में कॉपी करके और कंट्रोल पैनल में एक समय में मॉड्यूल को स्थापित करके संग्रह में संग्रहीत कर सकते हैं, या इसके लिए प्रदान किए गए 1C-Bitrix मार्केटप्लेस साइट पर मॉड्यूल प्रकाशित कर सकते हैं। मॉड्यूल प्रकाशित करने के लिए आपको केवल एक साझेदारी समझौते का समापन करना होगा और एक समझौते पर हस्ताक्षर करना होगा जो आपकी जिम्मेदारी का वर्णन करेगा। और हम मॉड्यूल की किसी भी निर्भरता के बारे में बात नहीं कर रहे हैं और निर्भरता की श्रृंखला स्थापित कर रहे हैं।

एक डिग्री या दूसरे को यह समस्या "पहले" विकसित सभी सीएमएस में निहित है। यह छोटे मॉड्यूल के विकास को ध्वस्त करता है (यह हमें लगता है कि "इस सरल कार्यक्षमता" को मॉड्यूल में नहीं बदलना चाहिए), और अलग-अलग प्रलेखन की आवश्यकता होती है।

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

भाग एक मॉड्यूल का सार्वजनिक स्थान

पहला काम जिसे हल करने की आवश्यकता है, वह मॉड्यूल को स्टोर करना है। मॉड्यूल स्रोत कोड किसी भी git, मर्क्यूरियल या svn रिपॉजिटरी में संग्रहीत किए जा सकते हैं। सार्वजनिक मॉड्यूल के लिए, मैं GitHub की सलाह देता हूं। गिटहब पर, आपके पास आसानी से स्रोत कोड देखने और मार्कडाउन प्रारूप में प्रलेखन बनाए रखने का अवसर होगा। कंपोज़र का उपयोग करने के लिए, आपको कंपोज़र.जॉसन फ़ाइल को बनाना और पॉप्युलेट करना होगा। यह संपादक में, आपके आईडीई में, या संगीतकार इनिट कमांड को कॉल करके किया जा सकता है। इसके बाद, मैं मूल विशेषताओं और संगीतकार आदेशों में नहीं दूंगा, यदि आप संगीतकार के लिए नए हैं, तो इस लेख को पढ़ें।

आपके द्वारा अपना मॉड्यूल बनाने के बाद (उदाहरण के लिए, यह अभी के लिए खाली है) और GitHub पर इसके कोड को पोस्ट करने के बाद, आपको packagist.org पर मॉड्यूल को पंजीकृत करना होगा । Packagist आपको GitHub हुक को कॉन्फ़िगर करने की पेशकश करेगा ताकि जब रिपॉजिटरी में परिवर्तन आए, तो packagist.org पर मॉड्यूल के बारे में जानकारी अपडेट हो जाए।

भाग दो स्थापना। यहां सबसे दिलचस्प है

आप, निश्चित रूप से, सीएमएस से परिचित हैं जिसके साथ आप काम करते हैं, जिसका अर्थ है कि आप इसमें मॉड्यूल स्थापित करने की सभी सूक्ष्मताएं जानते हैं। 1C-Bitrix मॉड्यूल की स्थापना 2 चरणों में होती है:

• मॉड्यूल के स्रोत कोड को एक विशिष्ट निर्देशिका <project_dir>/local/modules/<company_name>.<mod_mame>
• RegisterModule फ़ंक्शन (<company_name> <mod_mame>) को कॉल करें। एक नियम के रूप में, मॉड्यूल को स्थापित करने और हटाने के लिए जिम्मेदार सभी मॉड्यूल स्थापना क्रियाएं वर्ग के DoInstall विधि में वर्णित हैं। <project_dir>/local/modules/<company_name>.<mod_mame>/install/index.php

भाग दो एक है। एक सुरक्षित जगह में पैकेज छुपाएँ

डिफ़ॉल्ट रूप से, संगीतकार <project_dir>/vendor निर्देशिका में सभी पैकेज स्थापित करता है यदि संगीतकार प्रोजेक्ट रूट में स्थित है और आपके पैकेज में किसी भी हुक को निष्पादित नहीं करता है। लेकिन यह बदलना आसान है।

हमें कंपोज़र.जॉन फ़ाइल को प्रोजेक्ट रूट में रखना होगा:

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" } } 

1C-Bitrix में, डेवलपर्स द्वारा लिखा गया कोड आमतौर पर <project_dir>/local निर्देशिका में रखा जाता है। इसलिए, हमने कॉन्फ़िगरेशन अनुभाग में प्रविष्टि द्वारा vendor फ़ोल्डर को वहां स्थानांतरित कर दिया। अब सभी थर्ड-पार्टी पैकेज वहां होस्ट किए जाएंगे। लेकिन हमारे मॉड्यूल को निर्देशिका <project_dir>/local/modules/<company_name>.<mod_mame> में रखा जाना चाहिए, मुझे क्या करना चाहिए?

भाग दो दो। मॉड्यूल स्थापना प्लगइन

संगीतकार के पास कई प्रकार के पैकेज हैं, जिनमें से एक कंपोज़र-प्लगइन , कंपोज़र के लिए ही एक एक्सटेंशन है। हमारे मॉड्यूल को CMS द्वारा आवश्यकतानुसार स्थापित करने के लिए, हमें अपना स्वयं का प्लगइन लिखना होगा। ऐसा करने के लिए, एक अलग प्रोजेक्ट बनाएं और उसकी जड़ में कंपोजर लगाएं ।

 { "name": "<my_name>/installer", "description": "Plugin for custom installing", "type": "composer-plugin", "license": "MIT", "homepage": "<link to homepage github>", "version": "0.0.1", "authors": [ { "name": "<name>", "email": "<email>" } ], "require": { "composer-plugin-api": "^1.0" }, "require-dev": { "composer/composer": "^1.0" }, "autoload": { "psr-4": { "<my_name>\\installer\\": "" } }, "extra": { "class": "<my_name>\\installer\\Plugin" } } 

इस फ़ाइल में 3 मुख्य बिंदु हैं:

• "टाइप": "संगीतकार-प्लगइन" - संगीतकार को बताता है कि यह एक प्लगइन है
• ऑटोलॉड - ऑटोलैड कक्षाओं के लिए नियमों का वर्णन करता है
• अतिरिक्त - इंगित करता है कि कौन सा वर्ग प्लगइन है

प्लगइन दो वर्गों से मिलकर बनेगा:

• प्लगइन ही। वह संगीतकार को अपना इंस्टॉलर जोड़ देगा
• इंस्टॉलर, जो मॉड्यूल की स्थापना में लगे होंगे

प्लगइन बस इंस्टॉलर जोड़ता है (फ़ाइल: Plugin.php )

 namespace company_name\installer; use Composer\Composer; use Composer\EventDispatcher\EventSubscriberInterface; use Composer\IO\IOInterface; use Composer\Plugin\PluginInterface; class Plugin implements PluginInterface { public function activate(Composer $composer, IOInterface $io) { $composer->getInstallationManager()->addInstaller(new Bitrix($io, $composer)); } } 

इसके बाद, इंस्टॉलर खुद ( company_name\installer\Bitrix )। श्रेणी को Composer\Installer\LibraryInstaller से इनहेरिट करना होगा और इसमें निम्नलिखित विधियाँ होनी चाहिए:

• समर्थन करता है - अगर इंस्टॉलर इस प्रकार के पैकेज का समर्थन करता है तो यह सही है
• getInstallPath - वह पथ लौटाता है जहाँ आप पैकेज स्रोत कोड रखना चाहते हैं
• स्थापित / स्थापना रद्द / अद्यतन - पैकेज स्थापित / स्थापना रद्द / अद्यतन हुक

हमारे सभी मॉड्यूल बिट्रिक्स-मॉड्यूल प्रकार के होंगे और इंस्टॉलर को उनके साथ काम करना चाहिए।

 public function supports($packageType) { return $packageType === 'bitrix-module'; } 

मैंने मॉड्यूल नाम की अखंडता को संरक्षित करने का फैसला किया (इसमें company_name और mod_name एक बिंदु द्वारा अलग किए गए हैं) और संकुल का नाम <my_name>/<company_name>.<mod_mame> या <company_name>/<company_name>.<mod_mame> । यदि हम पैकेज का नाम लेते हैं और इसे स्लैश से तोड़ते हैं, तो दूसरा भाग मॉड्यूल का नाम होगा

 public function getInstallPath(PackageInterface $package) { $name = explode("/", $package->getName()); return "local/modules/{$name[1]}/"; } 

InitBitrix और getModule विधियाँ मॉड्यूल को स्थापित करने के लिए 1C-Bitrix API के साथ कार्य को कार्यान्वित करती हैं। आपके पास क्या सीएमएस है और कैसे आप मॉड्यूल अपडेट जारी करते हैं और आप उन्हें कैसे निष्पादित करने की योजना बनाते हैं (फाइल: Bitrix.php ) के आधार पर अपडेट विधि लागू की गई है।

 namespace company_name\installer; use Composer\Installer\LibraryInstaller; use Composer\Package\PackageInterface; use Composer\Repository\InstalledRepositoryInterface; class Bitrix extends LibraryInstaller { public function supports($packageType) { return $packageType === 'bitrix-module'; } public function install(InstalledRepositoryInterface $repo, PackageInterface $package) { parent::install($repo, $package); $name = explode("/", $package->getName()); $this->initBitrix(); $module = $this->getModule($name[1]); $module->DoInstall(); } public function uninstall(InstalledRepositoryInterface $repo, PackageInterface $package) { $name = explode("/", $package->getName()); $this->initBitrix(); $module = $this->getModule($name[1]); $module->DoUninstall(); parent::uninstall($repo, $package); } public function getInstallPath(PackageInterface $package) { $name = explode("/", $package->getName()); return "local/modules/{$name[1]}/"; } protected function initBitrix() { $_SERVER['DOCUMENT_ROOT'] = __DIR__ . "/../../../../"; define('STOP_STATISTICS', true); define("NO_KEEP_STATISTIC", "Y"); define("NO_AGENT_STATISTIC","Y"); define("NOT_CHECK_PERMISSIONS", true); require_once($_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'); $GLOBALS['APPLICATION']->RestartBuffer(); } protected function getModule($module) { include_once $_SERVER['DOCUMENT_ROOT'] . "/local/modules/" . $module . "/install/index.php"; $class = str_replace(".", "_", $module); $module = new $class(); return $module; } } 

प्लगइन को चेक करने के बाद, कोड को GitHub पर अपलोड किया जा सकता है और Packagist के साथ पंजीकृत किया जा सकता है।

भाग दो तीन। मॉड्यूल

आइए हम मॉड्यूल पर वापस जाएं, जिसका हमने पहले भाग में उल्लेख किया है। या बल्कि, उनके संगीतकार.जॉन को ।

 { "name": "<my_name>/<company_name>.<mod_mame>", "type": "bitrix-module", "description": "  ", "version": "1.0.0", "time": "11.09.2018", "minimum-stability": "dev", "license": "MIT", "homepage": "<link to homepage github>", "authors": [ { "name": "<name>", "email": "<email>" } ], "require": { "<my_name>/installer": "*" } } 

मॉड्यूल के नाम को सीएमएस की आवश्यकताओं को पूरा करना चाहिए, प्रकार को निर्दिष्ट करना होगा जिसके साथ इंस्टॉलर काम करता है (हमारे मामले में, बिट्रिक्स-मॉड्यूल ) और निर्भरता में मॉड्यूल में प्लग-इन (अनुभाग की आवश्यकता ) होनी चाहिए। मॉड्यूल को स्वयं बनाने और इसके संचालन की जांच करने के बाद, GitHub पर इसके कोड को भरें और इसे Packagist के साथ पंजीकृत करें।

भाग दो चार। का उपयोग

आपको याद दिला दूं कि प्रोजेक्ट (साइट) में खुद लगभग निम्नलिखित संगीतकार हैं

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" } } 

अब हम आवश्यकता वाले सेक्शन में उन सभी मॉड्यूल्स को सूचीबद्ध कर सकते हैं जिनकी हमें आवश्यकता है या कमांड को कॉल करें

 composer require "<my_name>/<company_name>.<mod_mame>" "*" 

उदाहरण के लिए, यदि आपको एसएमएस में एक पासवर्ड भेजना है, तो आप प्राधिकरण के काम को पूरी तरह से महसूस कर सकते हैं।

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

 composer require "<my_name>/<company_name>.<mod_mame>" "*" 

और क्या और किस क्रम में डाउनलोड और इंस्टॉल करना है, यह संगीतकार तय करते हैं।

भाग तीन निजी मॉड्यूल

दोस्तों, यदि उपरोक्त सभी में आप ऐसा नहीं करते हैं कि आपका मॉड्यूल सार्वजनिक डोमेन में होगा, तो हम जल्दी से इसे ठीक कर देंगे। मॉड्यूल के हैलो भंडारण को व्यवस्थित करने के लिए आपको दो उपकरणों की आवश्यकता होगी:

• GitLab GitHub का एक एनालॉग है जिसे आप अपने सर्वर पर डाउनलोड और इंस्टॉल कर सकते हैं।
• सैटिस एक रिपॉजिटरी जनरेटर है जो संगीतकार के साथ काम कर सकता है।

आरंभ करने के लिए, GitLab को स्थापित करें और अपने मॉड्यूल के स्रोत कोड को इसमें स्थानांतरित करें। तब Satis स्थापित करें और satis.json में अपने सभी मॉड्यूल का वर्णन करें

 { "name": "ropoName", "homepage": "https://composer.<company_name>.ru/", "repositories": [ { "type": "vcs", "url": "https://gitlab.<company_name>.ru/<my_name>/installer" }, { "type": "vcs", "url": "https://gitlab.<company_name>.ru/<my_name>/<company_name>.<mod_name>" } ], "config": { "gitlab-domains": [ "gitlab.<company_name>.ru" ], "gitlab-token": { "gitlab.<company_name>.ru": "GitLab Token" } }, "require-all": true } 

GitLab में, आपको एक टोकन बनाने की आवश्यकता है जो कि api में उपलब्ध होगा और इसे satis.json में निर्दिष्ट करेगा । इन सभी जोड़तोड़ के बाद, कमांड चलाएं:

 php bin/satis build satis.json ./web 

और वेब फ़ोल्डर में, एक स्थिर रिपॉजिटरी प्राप्त करें, जिसे https: // कंपोज़र पर प्रकाशित किया जा सकता है। <company_name> Ph /।

साइट का कंपोज़र.जॉन केवल उसी में अलग होगा जिसमें उसका रिपॉजिटरी सेक्शन होगा

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" }, "repositories": [ { "type": "composer", "url": "https://composer.<company_name>.ru/" } ] } 

अंतभाषण

दोस्तों, मैं वास्तव में आशा करता हूं कि यह लेख आपके लिए उपयोगी रहा है। और इससे कोई फर्क नहीं पड़ता कि आप किस CMS का उपयोग करते हैं, आप अपने कोड के भंडारण को सही ढंग से व्यवस्थित कर पाएंगे, आप इसे सख्ती से दस्तावेज़ित करेंगे, आप "मोटी" मॉड्यूल को कई "पतले" स्वरूपण निर्भरताओं में विभाजित करने में सक्षम होंगे, और आप मॉड्यूल को स्थापित करने या अपडेट करने में कठिनाई नहीं करेंगे। सौभाग्य है।