कैसे एक प्लगइन संरचना करने के लिए

Question

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

कुछ अन्य प्रोग्रामिंग भाषाओं या पुस्तकालयों में निर्देशिकाओं और फ़ाइलों को व्यवस्थित करने के बहुत नियंत्रित तरीके हैं। कभी-कभी यह कष्टप्रद होता है और PHP द्वारा प्रदान की जाने वाली स्वतंत्रता को उजागर करता है, लेकिन फ्लिप-साइड पर वर्डप्रेस प्लगइन्स को किसी भी फैशन में उनके लेखक द्वारा निर्धारित किया जाता है।

कोई सही उत्तर नहीं है , लेकिन मेरी आशा है कि मैं और अन्य लोगों को कैसे परिष्कृत करें, अन्य डेवलपर्स के लिए उन्हें अधिक अनुकूल बनाने के लिए प्लगइन्स का निर्माण करें, ताकि वे डिसेबल्ड के लिए आसान हो, डिबग करना आसान हो, नेविगेट करने में आसान हो, और संभवतः अधिक कुशल हो।

अंतिम सवाल: क्या है आप लगता है कि एक प्लगइन व्यवस्थित करने के लिए सबसे अच्छा तरीका है?

नीचे कुछ नमूना संरचनाएं हैं, लेकिन किसी भी तरह से एक विस्तृत सूची नहीं है। अपनी खुद की सिफारिशों को जोड़ने के लिए स्वतंत्र महसूस करें।

मान लिया डिफ़ॉल्ट संरचना

• /wp-content
  • /plugins
    • /my-plugin
      • my-plugin.php

मॉडल व्यू कंट्रोलर (MVC) विधि

• /wp-content
  • /plugins
    • /my-plugin
      • /controller
        • Controller.php
      • /model
        • Model.php
      • /view
        • view.php
      • my-plugin.php

MVC के तीन भाग:

• मॉडल डेटाबेस के साथ बातचीत करती, क्वेरी करने और डेटा की बचत, और तर्क होता है।
• नियंत्रक टेम्पलेट टैग्स तथा कार्यों की उस दृश्य का उपयोग होगा होते हैं।
• दृश्य मॉडल के आधार पर उपलब्ध कराए गए आंकड़ों प्रदर्शित करने के लिए जिम्मेदार के रूप में नियंत्रक द्वारा निर्मित है।

प्रकार विधि द्वारा आयोजित

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • admin.php
      • /assets
        • css/
        • images/
      • /classes
        • my-class.php
      • /lang
        • my-es_ES.mo
      • /templates
        • my-template.php
      • /widgets
        • my-widget.php
      • my-plugin.php

वर्डप्रेस प्लगइन बॉयलरप्लेट

गीथूब पर उपलब्ध है

प्लगइन एपीआई , कोडिंग मानकों , और प्रलेखन मानकों के आधार पर ।

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • /css
        • /js
        • /partials
        • my-plugin-admin.php
      • /includes
        • my_plugin_activator.php
        • my_plugin_deactivator.php
        • my_plugin_i18n.php
        • my_plugin_loader.php
        • my_plugin.php
      • /languages
        • my_plugin.pot
      • /public
        • /css
        • /js
        • /partials
        • my-plugin-public.php
      • LICENSE.txt
      • README.txt
      • index.php
      • my-plugin.php
      • uninstall.php

ढीली संगठित विधि

• /wp-content
  • /plugins
    • /my-plugin
      • css/
      • images/
      • js/
      • my-admin.php
      • my-class.php
      • my-template.php
      • my-widget.php
      • my-plugin.php

Comments

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

— kaiser

धन्यवाद, मैं वैसे भी इस समुदाय विकि हो जाएगा। मुझे नहीं लगता कि उस तरह से फ़ाइलों को प्रीफ़िक्स करना बहुत मायने रखता है, लेकिन मैंने इसे बहुत देखा है।

— developdaly

एक अन्य पक्ष बिंदु: शायद फ़ोल्डरों के लिए अधिक शब्दार्थ सही नाम css/, images/है, और js/हो सकता है styles/, images/और scripts/।

— एंड्रयू ओड्री

Answer 1

ध्यान दें कि प्लगइन्स WP मानकों द्वारा सभी "नियंत्रक" हैं।

यह इस बात पर निर्भर करता है कि प्लगइन क्या करना चाहिए, लेकिन सभी मामलों में मैं कोशिश करूंगा कि जितना संभव हो PHP कोड से स्क्रीन आउटपुट को अलग किया जाए।

इसे आसानी से करने का एक तरीका है - पहला, टेम्पलेट को लोड करने वाले फ़ंक्शन को परिभाषित करें:

function my_plugin_load_template(array $_vars){

  // you cannot let locate_template to load your template
  // because WP devs made sure you can't pass
  // variables to your template :(
  $_template = locate_template('my_plugin', false, false);

  // use the default one if the theme doesn't have it
  if(!_$template)
    $_template = 'views/template.php';

  // load it
  extract($_vars);        
  require $template;
}

अब, यदि प्लगइन डेटा प्रदर्शित करने के लिए एक विजेट का उपयोग करता है:

class Your_Widget extends WP_Widget{

  ...      
  public function widget($args, $instance){

    $title = apply_filters('widget_title', $instance['title'], $instance, $this->id_base);

    // this widget shows the last 5 "movies"
    $posts = new WP_Query(array('posts_per_page' => 5, 'post_type' => 'movie')); 

    if($title)
      print $before_title . $title . $after_title;

    // here we rely on the template to display the data on the screen
    my_plugin_load_template(array(

      // variables you wish to expose in the template
     'posts'    => $posts,          
    ));

    print $before_widget;
  }
  ...

}

नमूना:

<?php while($posts->have_posts()): $posts->the_post(); ?>

<p><?php the_title(); ?></p> 

<?php endwhile; ?>

फ़ाइलें:

/plugins/my_plugin/plugin.php           <-- just hooks 
/plugins/my_plugin/widget.php           <-- widget class, if you have a widget
/themes/twentyten/my_plugin.php         <-- template
/plugins/my_plugin/views/template.php   <-- fallback template

आप अपने सीएसएस, जेएस, छवियों को कहां रखते हैं, या आप हुक के लिए कंटेनर को कैसे डिज़ाइन करते हैं, यह कम महत्वपूर्ण नहीं है। मुझे लगता है कि यह व्यक्तिगत पसंद की बात है।

Answer 2

यह प्लगइन पर निर्भर करता है। यह लगभग हर प्लगइन के लिए मेरी मूल संरचना है:

my-plugin/
    inc/
        Any additional plugin-specific PHP files go here
    lib/
        Library classes, css, js, and other files that I use with many
        plugins go here
    css/
    js/
    images/
    lang/
        Translation files
    my-plugin.php
    readme.txt

यह कुछ ऐसा होगा जो libफ़ोल्डर में जाएगा।

यदि यह विशेष रूप से जटिल प्लगइन है, तो बहुत सारे व्यवस्थापक क्षेत्र की कार्यक्षमता के साथ, मैं adminउन सभी PHP फ़ाइलों को शामिल करने के लिए एक फ़ोल्डर जोड़ूंगा। अगर प्लगइन शामिल थीम फ़ाइलों की तरह कुछ करता है , तो शायद एक templateया एक themeफ़ोल्डर भी है।

इसलिए, एक निर्देशिका संरचना इस तरह दिख सकती है:

my-plugin/
    inc/
    lib/
    admin/
    templates/
    css/
    js/
    images/
    lang/
    my-plugin.php
    readme.txt

Comments

क्या आप व्यवस्थापक / css और js फ़ाइलों को / व्यवस्थापक फ़ोल्डर में शामिल करेंगे? इसलिए / व्यवस्थापक के भीतर एक और सीएसएस / और जेएस होने?

— urok93

Answer 3

IMHO, सबसे आसान, सबसे शक्तिशाली और सबसे अधिक रखरखाव योग्य मार्ग MVC संरचना का उपयोग करना है, और WP MVC को लेखन MVC प्लगइन्स को बहुत आसान बनाने के लिए डिज़ाइन किया गया है (मैं थोड़ा पक्षपाती हूं, हालांकि ...)। WP MVC के साथ, आप बस मॉडल, दृश्य और नियंत्रक बनाते हैं, और बाकी सब कुछ आपके लिए पर्दे के पीछे संभाला जाता है।

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

अधिक जानकारी और एक ट्यूटोरियल यहां पाया जा सकता है:

• प्लगइन पेज
• ट्यूटोरियल

Answer 4

हम सभी विधियों के मिश्रण का उपयोग कर रहे हैं। सबसे पहले, हम अपने प्लगइन्स में Zend फ्रेमवर्क 1.11 का उपयोग कर रहे हैं और इसलिए हमें ऑटोलैड मैकेनिक की वजह से क्लास फ़ाइलों के लिए समान संरचना का उपयोग करना पड़ा।

हमारे कोर प्लगइन की संरचना (जो आधार के रूप में हमारे सभी प्लगइन्स द्वारा उपयोग की जाती है) इस तरह दिखाई देती है:

webeo-core/
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Core.php
        Zend/
            /** ZF files **/
        Loader.php
    views/
    readme.txt
    uninstall.php
    webeo-core.php

1. वर्डप्रेस webeo-core.phpफ़ाइल को प्लगइन रूट फ़ोल्डर में बुलाता है ।
2. इस फ़ाइल में हम PHP को सेट करने वाले पथ को शामिल करते हैं और प्लगइन के लिए सक्रियण और निष्क्रियता हुक को पंजीकृत करते हैं।
3. Webeo_CoreLoaderइस फ़ाइल के अंदर हमारे पास एक क्लास भी है , जो कुछ प्लगइन स्थिरांक सेट करता है, क्लास ऑटोलैडर को इनिशियलाइज़ करता है और फोल्डर के Core.phpअंदर क्लास के सेटअप मेथड पर कॉल करता है lib/Webeo। यह plugins_loadedप्राथमिकता के साथ एक्शन हुक पर चलता है 9।
4. Core.phpवर्ग हमारे प्लगइन बूटस्ट्रैप फ़ाइल है। नाम प्लगइन्स नाम पर आधारित है।

जैसा कि आप देख सकते हैं, हमारे पास libहमारे सभी विक्रेता पैकेज ( Webeo, Zend) के लिए फ़ोल्डर के अंदर एक उपनिर्देशिका है । एक विक्रेता के अंदर सभी उप पैकेज मॉड्यूल द्वारा ही संरचना है। एक नए Mail Settingsव्यवस्थापक फॉर्म के लिए, हमारे पास निम्नलिखित संरचना होगी:

webeo-core/
    ...
    lib/
        Webeo/
            Form/
                Admin/
                    MailSettings.php
                Admin.php
            Core.php
            Form.php

हमारे उप-प्लगइन्स में एक अपवाद के साथ एक ही संरचना है। ऑटोलैड घटना के दौरान नामकरण संघर्ष को हल करने के कारण हम विक्रेता के फ़ोल्डर के अंदर एक स्तर गहरा हो जाता है। हम प्लग इन बूस्टर क्लास E.g. Faq.phpको हुक के 10अंदर प्राथमिकता पर भी कहते हैं plugins_loaded।

webeo-faq/ (uses/extends webeo-core)
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Faq/
                Faq.php
                /** all plugin relevant class files **/
    views/
    readme.txt
    uninstall.php
    webeo-faq.php

मैं संभवतः अगले रिलीज़ में नामित फ़ोल्डर में सभी सार्वजनिक फ़ोल्डर (सीएसएस, चित्र, जेएस, भाषा) को फ़ोल्डर में स्थानांतरित libकर दूंगा ।vendorspublic

Answer 5

यहाँ पहले से ही कई उत्तर दिए गए हैं, यह वास्तव में इस बात पर निर्भर करता है कि प्लगइन क्या करने वाला है, लेकिन यहाँ मेरी आधार संरचना है:

my-plugin/
    admin/
        holds all back-end administrative files
        js/
            holds all back-end JavaScript files
        css/                    
            holds all back-end CSS files
        images/
            holds all back-end images
        admin_file_1.php        back-end functionality file
        admin_file_2.php        another back-end functionality file 
    js/
        holds all front end JavaScript files
    css/
        holds all fronted CSS files
    inc/
        holds all helper classes
    lang/                   
        holds all translation files
    images/
        holds all fronted images
    my-plugin.php               main plugin file with plugin meta, mostly includes,action and filter hooks
    readme.txt                  
    changelog.txt
    license.txt

Answer 6

मैं निम्नलिखित प्लगइन लेआउट के लिए आंशिक हूं, हालांकि यह आमतौर पर प्लगइन आवश्यकताओं के आधार पर बदलता है।

wp-content/
    plugins/
        my-plugin/
            inc/
                Specific files for only this plugin
                admin/ 
                    Files for dealing with administrative tasks
            lib/
                Library/helper classes go here
            css/
                CSS files for the plugin
            js/
                JS files
            images/
                Images for my plugin
            lang/
                Translation files
        plugin.php 
            This is the main file that calls/includes other files 
        README 
            I normally put the license details in here in addition to helpful information 

मेरे पास अभी तक एक वर्डप्रेस प्लगइन बनाने की आवश्यकता है जो एमवीसी शैली की वास्तुकला की आवश्यकता है, लेकिन अगर मुझे ऐसा करना था तो मैं इसे एक अलग एमवीसी निर्देशिका के साथ बाहर रखूंगा, जिसमें स्वयं दृश्य / नियंत्रक / मॉडल शामिल हैं।

Answer 7

मेरा तर्क, प्लगइन जितना बड़ा संरचना मैं उपयोग करता हूं।
बड़े प्लगइन्स के लिए मैं MVC का उपयोग करता हूं।
मैं इसे एक शुरुआती बिंदु के रूप में उपयोग करता हूं और जो आवश्यक नहीं है उसे छोड़ देता हूं।

controller/
    frontend.php
    wp-admin.php
    widget1.php
    widget2.php
model/
    standard-wp-tables.php // if needed split it up
    custom-tabel1.php
    custom-tabel2.php
view/
    helper.php
    frontend/
        files...php
    wp-admin/
        files...php
    widget1/
        file...php
    widget2/
        file...php
css/
js/
image/
library/  //php only, mostly for Zend Framework, again if needed
constants.php //tend to use it often
plugin.php //init file
install-unistall.php  //only on big plugins

Answer 8

मेरे सभी प्लगइन्स इस संरचना का अनुसरण करते हैं, जो कि अन्य देवों की तुलना में बहुत कुछ समान प्रतीत होता है:

plugin-folder/
    admin/
        css/
            images/
        js/
    core/
    css/
        images/
    js/
    languages/
    library/
    templates/
    plugin-folder.php
    readme.txt
    changelog.txt
    license.txt

प्लगइन- folder.php आमतौर पर एक ऐसा वर्ग है जो कोर / फ़ोल्डर से सभी आवश्यक फाइलों को लोड करता है। अधिकांश अक्सर init या plugins_loaded हुक पर।

मैं अपनी सभी फ़ाइलों के साथ ही उपसर्ग करता था, लेकिन जैसा कि @kaiser ने उल्लेख किया है, यह वास्तव में बेमानी है और मैंने हाल ही में इसे किसी भी भविष्य के प्लगइन्स से हटाने का फैसला किया है।

लाइब्रेरी / फ़ोल्डर में सभी बाहरी सहायक लाइब्रेरीज़ होती हैं, जो प्लगइन पर निर्भर हो सकती हैं।

प्लगइन के आधार पर, प्लगइन रूट में भी अनइंस्टॉल हो सकता है। हालांकि यह ज्यादातर समय register_uninstall_hook () के माध्यम से संभाला जा रहा है।

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

मेरे पास एक स्टार्टर प्लगइन भी है, जो कि ऊपर की संरचना पर आधारित है जो मैं अपने सभी प्लगइन्स के लिए शुरुआती बिंदु के रूप में उपयोग करता हूं। इसके बाद मुझे बस इतना करना होगा कि मैं फंक्शन / क्लास उपसर्गों के लिए खोज / प्रतिस्थापन करूं और मैं जाऊं। जब मैं अभी भी अपनी फ़ाइलों को प्रीफ़िक्स कर रहा था जो कि एक अतिरिक्त कदम था जो मुझे करना था (और उस पर काफी परेशान था), लेकिन अब मुझे बस प्लगइन फ़ोल्डर और मुख्य प्लगइन फ़ाइल का नाम बदलना होगा।

Answer 9

इसके अलावा, इस महान WP विजेट बॉयलरप्लेट को देखें । यह संरचनाओं के रूप में महान संकेत देता है (भले ही अलग मॉडल के लिए कोई वर्ग न हो और न ही फ़ोल्डर हो)।

Answer 10

एक प्लगइन फ़ाइलों और निर्देशिकाओं को संरचित करने के लिए एक कम सामान्य दृष्टिकोण फ़ाइल प्रकार दृष्टिकोण है। यह पूरी तरह से यहाँ उल्लेख के लायक है:

plugin-name/
    js/
        sparkle.js
        shake.js
    css/
        style.css
    scss/
        header.scss
        footer.scss
    php/
        class.php
        functions.php
    plugin-name.php
    uninstall.php
    readme.txt

प्रत्येक निर्देशिका में केवल उस प्रकार की फाइलें होती हैं। यह ध्यान देने योग्य है कि यह दृष्टिकोण कम हो जाता है जब आपके पास कई फ़ाइल प्रकार होते हैं .png .gif .jpgजो कि images/उदाहरण के लिए , एकल निर्देशिका के तहत अधिक तार्किक रूप से दायर किए जा सकते हैं ।