सीएमएस जूमला के लिए संकुल की स्वचालित विधानसभा!

इससे पहले कि मैं वर्तमान परियोजना पर काम करना शुरू करूं, मैंने नहीं सोचा था कि मुझे कभी भी परियोजनाओं का निर्माण करने के लिए उपकरणों का उपयोग करना होगा। आखिरकार, मैं विशेष रूप से व्याख्या की गई भाषाओं के साथ काम करता हूं जिन्हें संकलन की आवश्यकता नहीं है। हालांकि, जैसा कि यह निकला, वे PHP में विकसित होने पर उपयोगी हो सकते हैं, और विशेष रूप से जूमला के साथ काम करते समय!

पहले, एक वेबसाइट पर काम करते समय, मैंने अपने स्थानीय सर्वर पर फ़ाइलों और डेटाबेस के लिए आवश्यक परिवर्तन किए, जाँच की कि क्या सब कुछ सही ढंग से काम किया है, फिर, ftp क्लाइंट और phpMyAdmin का उपयोग करके, मैंने फ़ाइलों और डेटाबेस परिवर्तनों को कार्य स्थल पर कॉपी किया। यदि मुझे याद नहीं है कि मैं कौन सी फाइल को नियमित करता हूं, और आमतौर पर ऐसा होता है, तो मैंने सब कुछ कॉपी किया।

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

यहाँ मैं स्वत: असेंबली के प्रश्न से हैरान था। उस समय, मैं केवल चींटी के बारे में जानता था। अपनी क्षमताओं का पता लगाने के लिए, मैंने मावेन के बारे में अधिक जानकारी प्राप्त की। लेकिन इसने मुझे उलझन में डाल दिया कि अगर मेरे पास अचानक उपलब्ध क्षमताएं नहीं थीं, तो मुझे जावा में लिखना होगा। इसलिए मैंने पीएचपी के लिए एक प्रोजेक्ट बिल्डर खोज और खोज जारी रखी। अपनी क्षमताओं से परिचित होने के बाद, मुझे जल्दी से एहसास हुआ कि इसमें वह सब कुछ है जो आपको चाहिए:

• फ़ाइलों और निर्देशिकाओं के साथ संचालन;
• अभिलेखागार के साथ काम करना;
• xml फ़ाइलों से पढ़ने के गुण (आप प्रकट से डेटा का उपयोग कर सकते हैं);
• संस्करण नियंत्रण प्रणालियों (cvs, svn, git) के साथ काम करने के लिए संचालन;
• ftp और http प्रोटोकॉल सपोर्ट;
• बाहरी आदेशों का निष्पादन;
• PHP कोड निष्पादन;
• लॉन्च यूनिट परीक्षण;
• डेटाबेस के साथ काम करें;
• कई अन्य सुविधाएँ जो PHP में रेडी-मेड या होम-मेड प्लगइन्स के साथ विस्तारित हैं।

पिंग स्थापना

Phing को स्थापित करने का सबसे आसान तरीका PEAR का उपयोग करना है। ऐसा करने के लिए, बस कंसोल में दो कमांड दर्ज करें:

pear channel-discover pear.phing.info pear install phing/phing 

यदि आप PEAR का उपयोग नहीं करते हैं, तो आधिकारिक वेबसाइट पर निर्देश है कि मैन्युअल रूप से Phing कैसे स्थापित करें।

NetBeans से कनेक्ट करें

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

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

• पसंदीदा - चयनित कार्य;
• सबटार्गेट्स - उप-कार्य (ऐसे कार्य जिनके कार्यान्वयन को अधिक सामान्य कार्य में शामिल किया गया है);
• डिफ़ॉल्ट लक्ष्य - डिफ़ॉल्ट कार्य।

PHP अनुभाग में नेटबीन्स सेटिंग्स में, PhingKing टैब दिखाई देता है जिसमें आपको Phing के लिए पथ निर्दिष्ट करने की आवश्यकता होती है। संबंधित अनुभाग में परियोजना के गुणों में, आपको कार्यों के साथ xml- फ़ाइल का पथ निर्दिष्ट करना होगा (इस पर नीचे)।

कमांड लाइन का उपयोग

कमांड लाइन से Phing का उपयोग करना भी सरल है। बिल्ड.xml फ़ाइल में फ़ंक्शंस रखें और उसी निर्देशिका में फ़िंग स्क्रिप्ट चलाएँ, या -buildfile पैरामीटर में xml फ़ाइल के लिए पथ निर्दिष्ट करें। आप phing -help चलाकर मापदंडों का एक पूरा सेट प्राप्त कर सकते हैं।

निर्माण कार्य

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

सबसे सरल कार्य फ़ाइल इस प्रकार है:

 <?xml version="1.0" encoding="UTF-8"?> <project name="test" default="build"> <target name="task1"> <echo msg="Task 1" /> </target> <target name="task2"> <echo msg="Task 2" /> </target> <target name="build" depends="task1, task2"> <echo msg="Build" /> </target> </project> 

परिणाम प्रदर्शित किया जाएगा:

टास्क 1
टास्क २
बिल्ड

एक्सटेंशन जूमला बनाएँ

अब चलो फ़िंग को कुछ उपयोगी बनाते हैं - जूमला के लिए एक्सटेंशन के साथ एक पैकेज डालें।
प्रारंभिक स्थितियों:

• विकास निर्देशिका / ऑप्ट / लैम्प / htdocs / mysite के तहत है
• तैयार पैकेज को / home / user1 / mysite में डालें
• विस्तार स्रोत फ़ाइलें / घर / user1 / mysite / src में
• / घर / user1 / mysite / ज़िप में संस्करण संख्या के साथ विस्तार स्थापना फ़ाइलें
• संस्करण घर / user1 / mysite / कैश में संस्करण संख्या के बिना विस्तार स्थापना फ़ाइलें

नोट: संस्करण संख्या वाली फाइलें आसानी से स्टैंड-अलोन फ़ाइलों के रूप में उपयोग की जाती हैं, और संख्याओं के बिना पैकेज असेंबली को सरल बनाने के लिए।

 <project name="make_project" default="build"> <!--    ,   --> <property name="src_dir" value="/opt/lampp/htdocs/mysite" /> <property name="res_dir" value="/home/user1/mysite" /> <target name="clear"> <echo>=============    =============</echo> <!--  delete       fileset --> <delete includeemptydirs="true"> <!--  ${res_dir}    res_dir --> <fileset dir="${res_dir}"> <!--    /   --> <include name="**"/> </fileset> </delete> </target> <target name="com_test"> <echo>=============  Test =============</echo> <!--   xml-.     . --> <xmlproperty file="${src_dir}/administrator/components/com_test/test.xml" prefix="com_test." keepRoot="false" /> <!--       → <!--   --> <copy todir="${res_dir}/src/com_test/site" overwrite="true"> <fileset dir="${src_dir}/components/com_test"> <include name="**" /> </fileset> </copy> <!--   --> <copy todir="${res_dir}/src/com_test/admin" overwrite="true"> <fileset dir="${src_dir}/administrator/components/com_test"> <!--  ,    --> <exclude name="${src_dir}/administrator/test.xml" /> </fileset> </copy> <!--        --> <copy file="${src_dir}/administrator/components/com_test/test.xml" tofile="${res_dir}/src/com_test/test.xml" overwrite="true"/> <!--    media --> <copy todir="${res_dir}/src/com_test/media" overwrite="true"> <fileset dir="${src_dir}/media/com_test"> <include name="**" /> </fileset> </copy> <!--     --> <zip destfile="${res_dir}/cache/com_test.zip" basedir="${res_dir}/src/com_test"/> <!--      .    xml- --> <copy file="${res_dir}/cache/com_test.zip" tofile="${res_dir}/zip/com_test-${com_test.version}.zip" overwrite="true"/> </target> <!--    .     --> <target name="mod_test"> <echo>=============  Test =============</echo> <xmlproperty file="${src_dir}/modules/mod_test/mod_test .xml" prefix="mod_test." keepRoot="false"/> <copy todir="${res_dir}/src/mod_test" overwrite="true"> <fileset dir="${src_dir}/modules/mod_test"> <include name="**" /> </fileset> </copy> <zip destfile="${res_dir}/cache/mod_test.zip" basedir="${res_dir}/src/mod_test"/> <copy file="${res_dir}/cache/mod_test .zip" tofile="${res_dir}/zip/mod_test-${mod_calendar.version}.zip" overwrite="true"/> </target> <target name="build" depends="clear, com_test, mod_test"> <echo>=============   =============</echo> <!-- build/pkg_test.xml —     --> <xmlproperty file="${src_dir}/build/pkg_test.xml" prefix="pkg." keepRoot="false" /> <copy file="${src_dir}/build/pkg_test.xml" tofile="${res_dir}/cache/pkg_test.xml" overwrite="true"/> <zip destfile="${res_dir}/pkg_test-${pkg.version}.zip" basedir="${res_dir}/cache"/> </target> </project> 

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

आप प्रत्येक असेंबली के लिए संस्करण संख्याओं में एक स्वचालित वृद्धि जोड़कर प्रक्रिया में और सुधार कर सकते हैं, लेकिन मैंने डेटाबेस माइग्रेशन फ़ाइलों के नामों के साथ संस्करण संख्याओं के मिलान के लिए ऐसा नहीं किया। यदि किसी के पास इस बारे में कोई विचार है, तो टिप्पणियों में लिखें।