उद्देश्य प्लगइन विकास के लिए सबसे अच्छा अभ्यास? [बन्द है]


135

प्लगइन विकास के लिए उद्देश्य सर्वोत्तम प्रथाओं को इकट्ठा करने के लिए एक सामुदायिक विकि शुरू करना । यह प्रश्न @ EAMann की wp-hackers की टिप्पणियों से प्रेरित था ।

विचार इस बात पर सहयोग करने के लिए है कि कौन से उद्देश्य सर्वोत्तम अभ्यास हो सकते हैं ताकि हम अंततः कुछ सामुदायिक सहयोग समीक्षा प्रक्रिया में उनका उपयोग कर सकें।

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


मैं वास्तव में यह नहीं समझता कि एसई के साथ समुदाय विकी को इस (और अन्य) पर कैसे काम करना चाहिए, लेकिन शायद यह मेटा पर एक सवाल है। यह केवल उत्तरों में अधिकांशतः नकल करता है।
हकर्रे

@ खाक: ग्रेट पॉइंट। इस बात को देखने के बाद मैं इस विवरण में जोड़ने जा रहा हूं कि लोगों को "उत्तर" के अनुसार केवल एक विचार जोड़ना चाहिए और मैं अपने मौजूदा उत्तर को कई उत्तरों में बदलने जा रहा हूं।
माइकस्किंकेल

जवाबों:


72

क्रिया और फ़िल्टर का उपयोग करें

अगर आपको लगता है कि लोग कुछ डेटा जोड़ना या बदलना चाहेंगे: लौटने से पहले apply_filters () प्रदान करें

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

शायद चीजें अलग होती अगर वर्डप्रेस में प्लग-इन करने की क्षमता होती, जिस पर अन्य प्लगइन्स निर्भर होते? जैसा कि यह है कि मुझे आम तौर पर स्क्रैच से बहुत अधिक कार्यक्षमता लिखनी होती है क्योंकि ग्राहक चीजों को एक निश्चित तरीके और उपलब्ध प्लगइन्स के लिए चाहते हैं, जबकि 90%, मुझे शेष 10% को अपडेट करने की अनुमति नहीं देते हैं।

मैं वास्तव में चाहता हूं कि वर्डप्रेस समुदाय का नेतृत्व करने वाले लोग यह सुनिश्चित करने के लिए एक तरीका की पहचान करेंगे कि प्लगइन्स को सर्वोत्तम प्रथाओं का पालन करने के लिए पुरस्कृत किया जाता है (जैसे कि अन्य डेवलपर्स के लिए हुक में जोड़ना) बहुत अच्छे जवाब जैसे कि StackExchange साइट पर पुरस्कृत किए जाते हैं।

आइए एक और प्रश्न से एक उदाहरण लेते हैं :

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

सम्बंधित


55

लोड लिपियों / सीएसएस के साथ wp_enqueue_scriptऔरwp_enqueue_style

प्लगइन्स को जेएस / सीएसएस फ़ाइलों के डुप्लिकेट संस्करणों को लोड करने / लोड करने का प्रयास नहीं करना चाहिए, विशेष रूप से jQuery और अन्य जेएस फाइलें WP कोर में शामिल हैं।

प्लगइन्स हमेशा का उपयोग करना चाहिए wp_enqueue_scriptऔर wp_enqueue_styleके माध्यम से लिंक करते समय जे एस और सीएसएस फ़ाइलें और कभी नहीं सीधे <script>टैग।

सम्बंधित


1
सुझाव : इसमें निर्भरता का उपयोग करने के बारे में एक छोटा सा नोट चिपकाने लायक हो सकता है (क्योंकि यह एन्क्यू सिस्टम का हिस्सा है)।
t31os

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

2
प्लस, जहां आवश्यक हो वहां पृष्ठों और शैलियों को लोड करें। scribu.net/wordpress/optimal-script-loading.html
MR

49

I18n समर्थन करते हैं

सभी आउटपुट स्ट्रिंग्स को एक उपयुक्त टेक्स्ट डोमेन से जोड़ा जाना चाहिए ताकि इच्छुक पार्टियों द्वारा अंतर्राष्ट्रीयकरण की अनुमति दी जा सके, भले ही डेवलपर को अपने प्लग-इन का अनुवाद करने में कोई रुचि न हो।

ध्यान दें कि initकार्रवाई के दौरान भाषा फ़ाइलों को लोड करना बहुत महत्वपूर्ण है ताकि उपयोगकर्ता कार्रवाई में हुक कर सके।

वर्डप्रेस डेवलपर्स के लिए कोडेक्स: I18n देखें

और यह लेख भी: लोडिंग WP भाषा सही ढंग से फाइल करती है

चूंकि वर्डप्रेस 4.6+

WP 4.6 ने लोड ऑर्डर और चेक किए गए स्थानों को बदल दिया, इसने डेवलपर्स और उपयोगकर्ताओं के लिए बहुत आसान बना दिया है।

टेक्सटोमैन 'माय-प्लगइन' के साथ एक प्लगइन को ध्यान में रखते हुए, वर्डप्रेस अब एक अनुवाद फाइल के लिए एफआईआरएसटी देखेगा :
/wp-content/languages/plugins/my-plugin-en_US.mo

अगर यह एक को खोजने में विफल रहता है तो यह एक के लिए दिखेगा जहां प्लगइन इसे देखने के लिए कहता है (कोडेक्स का पालन करते हुए pluigns की भाषा में फ़ोल्डर में सामान्य रूप से):
/ wp-content / plugins / my-plugin / languages ​​/ my- plugin-en_US.mo

अंत में अगर कोई भाषा फ़ाइल नहीं मिली है तो यह डिफ़ॉल्ट स्थान की जाँच करेगा:
/wp-content/languages/my-plugin-en_US.mo

पहले चेक 4.6 में जोड़ा गया था और उपयोगकर्ताओं को एक भाषा फ़ाइल जोड़ने के लिए एक परिभाषित स्थान देता है, क्योंकि इससे पहले उन्हें यह जानना होगा कि डेवलपर ने भाषा फ़ाइल कहाँ जोड़ी है, अब उपयोगकर्ता को बस प्लगइन के टेक्सटोमेन को जानना होगा: / wp-content / भाषाओं / plugins / TEXTDOMAIN-LOCAL.mo


नीचे पुराना तरीका है (WP 4.6+ के बाद से प्रासंगिक नहीं)

[...]
अंत में, मैं यह इंगित करना चाहूंगा कि प्लगइन के साथ जहाज भेजने वाली भाषा फ़ाइलों को लोड करने से पहले WP_LANG_DIR से कस्टम उपयोगकर्ता भाषा फ़ाइलों को लोड करना महत्वपूर्ण है । जब एक ही डोमेन के लिए कई मो-फाइल्स लोड की जाती हैं, तो पहले पाए गए अनुवाद का उपयोग किया जाएगा। इस तरह प्लगइन द्वारा प्रदान की गई भाषा की फाइलें उपयोगकर्ता द्वारा अनुवादित नहीं किए गए स्ट्रिंग्स के लिए एक कमबैक के रूप में काम करेंगी।

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain( 
            $domain, 
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo' 
    );
    load_plugin_textdomain( 
            $domain, 
            FALSE, 
            dirname( plugin_basename(__FILE__) ) . '/languages/' 
    );
}

मेरे लिए सबसे महत्वपूर्ण है। यह करने के लिए बहुत अधिक अतिरिक्त काम नहीं है, लेकिन उन चीजों में से एक जो आप अपने प्लगइन को उन लाखों उपयोगकर्ताओं के लिए अधिक उपयोगी बना सकते हैं जो अंग्रेजी को अपनी पहली भाषा के रूप में नहीं बोलते हैं। आपको किसी भी शब्द का स्वयं अनुवाद करने की आवश्यकता नहीं है, लेकिन अनुवाद करने के लिए सब कुछ तैयार करें।
2ndkauboy

यह इतना मूल्यवान, अभी तक आसान काम है, बस मैं कहना चाहता था कि सहमत हूं और प्रत्येक प्लगइन लेखक को ऐसा करना चाहिए।
t31os

48

सुनिश्चित करें कि प्लगइन्स WP_DEBUG के साथ कोई त्रुटि उत्पन्न न करें

हमेशा अपने प्लगइन्स का परीक्षण WP_DEBUGचालू रखें और आदर्श रूप से यह आपकी संपूर्ण विकास प्रक्रिया को चालू कर देता है। एक प्लगइन को किसी भी त्रुटि WP_DEBUGपर नहीं फेंकना चाहिए । इसमें पदावनत नोटिस और अनियंत्रित सूचकांक शामिल हैं।

डिबगिंग चालू करने के लिए, अपनी wp-config.phpफ़ाइल को संपादित करें ताकि WP_DEBUGनिरंतर सेट हो true। देखें डीबग पर कोडेक्स अधिक जानकारी के लिए।


कृपया प्रति उत्तर केवल सबसे अच्छा अभ्यास करने के बारे में अद्यतन देखें; क्या आप कई उत्तरों में विभाजित हो सकते हैं?
माइकस्किंकेल

बिलकुल कोई परेशानी नही। उसके लिए माफ़ करना।
जॉन पी बलोच

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

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

42

वर्डप्रेस कोर में पहली बार मौजूदा फ़ंक्शंस का उपयोग करें

यदि आप कर सकते हैं: अपने स्वयं के लिखने के बजाय वर्डप्रेस कोर में शामिल मौजूदा कार्यों का उपयोग करें। वर्डप्रेस कोर में एक उपयुक्त पूर्व-मौजूदा फ़ंक्शन नहीं होने पर केवल कस्टम PHP फ़ंक्शन विकसित करें।

एक लाभ यह है कि आप आसानी से प्रतिस्थापित किए जाने वाले कार्यों की निगरानी करने के लिए "लॉग अपग्रेड किए गए नोटिस" का उपयोग कर सकते हैं । एक अन्य लाभ उपयोगकर्ता कोडेक्स में फ़ंक्शन प्रलेखन को देख सकते हैं और बेहतर समझ सकते हैं कि एक अनुभवी PHP डेवलपर नहीं होने पर भी प्लगइन क्या करता है।

सम्बंधित


यहां एक सबसे बड़ी समस्या यह है कि एक उपयुक्त मौजूदा फ़ंक्शन मौजूद है। क्या उपयोगी होगा कोड को पोस्ट करने के लिए एक जगह होगी और / या कार्यक्षमता को समुदाय को सक्षम करने की आवश्यकता है कि वह किस फ़ंक्शन का सबसे अच्छा उपयोग कर सके। शायद इसके लिए StackExchange का उपयोग किया जा सकता है?
माइकस्किंकेल

Puh। यह बहुत कठिन होगा और मुझे लगता है कि अंतहीन कार्य के कुछ प्रकार। मुझे लगता है कि कोडेक्स का इस तरह से विस्तार करना सबसे अच्छा होगा, क्योंकि यह पहले से मौजूद है।
kaiser

मुझे लगता है कि कोडेक्स का विस्तार करना और शायद वहां से संबंधित स्टॉकएक्सचेंज थ्रेड्स को जोड़ना काफी अच्छा होगा।
kaiser

4
इसके साथ एक समस्या यह है कि बहुत सारे कोर वास्तव में संरचनात्मक रूप से पुन: प्रयोज्य के लिए डिज़ाइन नहीं किए गए हैं। मुझे केवल अपनी छवि बनाने के लिए आधी छवि हेरफेर / मेटाडेटा फ़ंक्शन को कॉपी और थोड़ा संशोधित करना पड़ा, जैसे कि पोस्ट-प्रकार का व्यवहार करना, सिर्फ इसलिए कि डाउनसेज़ जैसा फ़ंक्शन () कुछ फ़ंक्शन को कॉल करता है जिसमें पोस्ट-टाइप = अनुलग्नक के लिए हार्डकोड चेक शामिल है '। वहाँ बहुत है कि अनम्य wp_count_posts () की तरह एक और उदाहरण है। इससे पहले कि आप वास्तव में कोर WP का पुन: उपयोग कर सकें, एक पूर्ण रीफैक्टरिंग की आवश्यकता होती है।
wyrfel

इस पर पूरी तरह से सहमत हैं। मेरा सर्वकालिक पसंदीदा उदाहरण wp-login.php:। तो, "अगर आप कर सकते हैं" जवाब के लिए एक अच्छा स्टार्टर था ...
kaiser

35

अनइंस्टॉल करना एक प्लगइन के सभी डेटा को हटा देना चाहिए

एक वर्डप्रेस इंस्टॉलेशन से हटाए जाने पर, एक प्लगइन को सभी फ़ाइलों, फ़ोल्डरों, डेटाबेस प्रविष्टियों और तालिकाओं को हटाना चाहिए जो इसे बनाया और साथ ही साथ बनाए गए विकल्प मानों को बनाया है।

प्लगइन्स सेटिंग्स को निर्यात / आयात करने का विकल्प प्रदान कर सकते हैं, ताकि हटाने से पहले सेटिंग्स को वर्डप्रेस के बाहर सहेजा जा सके।

सम्बंधित


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

1
मैं केवल उस बारे में बात कर रहा हूं जब कोई प्लगइन पूरी तरह से हटा दिया जाता है, तब नहीं जब इसे निष्क्रिय किया जाता है।
ट्रैविस नॉर्थकट

2
मैं समझता हूं कि ... लेकिन कभी-कभी मैं प्लग-इन को हटा देता हूं इसलिए मैं मैन्युअल रूप से उन्हें बैकअप या बीटा संस्करण से फिर से जोड़ सकता हूं जो अभी तक रिपॉजिटरी में होस्ट नहीं किया गया है ...
EAMann

4
@ ईमैन: उसके लिए और प्लगइन्स को किसी अन्य सर्वर पर स्थानांतरित करने के लिए, एक प्लगइन को सेटिंग्स को निर्यात और आयात करने के लिए एक तंत्र प्रदान करना चाहिए।
हैकर

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

34

इनपुट डेटा के साथ SQL इंजेक्शन को रोकें

MySQL डेटाबेस को क्वेरी करने के लिए इनपुट मानों का उपयोग करने से पहले एक प्लगइन को सभी उपयोगकर्ता इनपुट को प्रत्यक्ष या अप्रत्यक्ष रूप से (जैसे के माध्यम $_POSTसे$_GET ) पुनः प्राप्त करना चाहिए

देखें: एसक्यूएल स्टेटमेंट्स को फॉर्मेट करना


5
आपको डेटाबेस से बाहर आने वाले डेटा को भी साफ करना चाहिए । मूल रूप से, कभी भी किसी भी डेटा पर भरोसा न करें जो हार्डकोड नहीं है। codex.wordpress.org/Data_Validation एक अच्छा संदर्भ भी है।
इयान दून

31

सभी वैश्विक नामस्थान आइटम उपसर्ग

एक प्लगइन को सभी वैश्विक नेमस्पेस आइटम (स्थिरांक, फ़ंक्शंस, क्लासेस, वैरिएबल, यहां तक ​​कि कस्टम टैक्सोनॉमी, पोस्ट प्रकार, विगेट्स, इत्यादि जैसी चीजें) को ठीक से उपसर्ग करना चाहिए। उदाहरण के लिए, एक फ़ंक्शन का निर्माण न करें जिसे कहा जाता है init(); इसके बजाय, इसे कुछ नाम दें jpb_init()

इसके आम को नामों के सामने तीन या चार अक्षरों के उपसर्ग का उपयोग करना चाहिए या PHP नेमस्पेस फ़ीचर का उपयोग करना चाहिए । तुलना करें: PHP वर्ग के स्थिरांक के लिए एकल-अक्षर उपसर्ग?

सम्बंधित


31

एक वर्ग और ऑब्जेक्ट का उपयोग PHP5 कोड को केंद्रित किया

स्वच्छ, ऑब्जेक्ट-ओरिएंटेड PHP5 कोड लिखने का कोई कारण नहीं है। PHP4 समर्थन अगले रिलीज़ (WP 3.1) के बाद समाप्त हो जाएगा। बेशक, आप अपने सभी फंक्शन नामों को एंडलेस_ लॉन्ग_फंक्शन_नम्स_विथ_लॉट्स_ऑफ_संडर्सकोर्स के साथ प्रीफ़िक्स कर सकते हैं, लेकिन सिर्फ एक साधारण वर्ग लिखना और उसमें सब कुछ बंडल करना बहुत आसान है। इसके अलावा, अपनी कक्षा को एक अलग फाइल में रखें और उसके अनुसार नाम दें ताकि आप आसानी से इसे बढ़ा और बनाए रख सकें:

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP 
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions 
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

नए MyCoolPlugin () का उपयोग न करें; मुझे लगता है कि बेहतर है कि आप WP में हुक के माध्यम से हुक करें: plugins_loaded
bueltge करें

उस पर यकीन नहीं है। कोडेक्स प्लगइन्स के अनुसार_लोडेड बहुत पहले लोड की गई चीजों में से एक है, इसलिए मुझे लगता है कि यह इस तरह से एक निर्माण करने के लिए बहुत कम फर्क पड़ता है, या इसे एक कार्रवाई के रूप में जोड़ें।
कर्कश

5
यह उन सर्वोत्तम प्रथाओं में से एक है जो इसे सभी के लिए अच्छा बनाते हैं।
अर्लेन बीइलर

1
जहाँ तक मैं प्लगइन्स में एक हुक जोड़ते हुए देख सकता हूँ_ लोड किया गया शून्य सुधार करता है, और सबसे अच्छा अभ्यास नहीं होगा क्योंकि कोई सुधार नहीं है, अगर कुछ भी मेमोरी के उपयोग में वृद्धि हुई है, तो गति में कमी आई क्योंकि इसे एक कार्रवाई से गुजरना पड़ता है क्रियाओं के बजाय बस जोड़ा जा रहा है। इसके अलावा OO का उपयोग करना एक सर्वोत्तम अभ्यास नहीं माना जाना चाहिए।
बैकी

4
@IanDunn: यदि आप PHP4 समर्थन चाहते हैं, लेकिन PHP4 समर्थन 4 साल पहले 2008 से हटा दिया गया है। PHP4- विशिष्ट चेक का उपयोग करने का कोई कारण नहीं है।
हुस्की

26

निष्क्रियता को डेटा-लॉस को उत्तेजित नहीं करना चाहिए

एक प्लगइन को निष्क्रिय होने पर अपना कोई डेटा नहीं हटाना चाहिए

सम्बंधित


23

केवल उन फ़ाइलों को शामिल करें जिनकी आपको आवश्यकता है ...

यदि आप सामने के छोर पर हैं, तो उस कोड को शामिल न करें जो व्यवस्थापक क्षेत्र से संबंधित है।


21

प्लगइन स्थापना पर डेटा-हानि की घोषणा करें

अनइंस्टॉल करने पर एक प्लगइन को एक उपयोगकर्ता को संकेत देना चाहिए कि यह डेटा को डिलीट कर देगा और एक पुष्टिकरण प्राप्त करेगा कि उपयोगकर्ता ऐसा करने से पहले डेटा को हटाने के साथ ठीक है और एक प्लगइन को उपयोगकर्ता को अनइंस्टॉल करने पर विकल्प को रखने की अनुमति भी देनी चाहिए । (यह विचार @ ईमन्न से।)

सम्बंधित


3
Wordpress व्यवस्थापक में एक चेतावनी संदेश प्रदर्शित करता है, कि ऐसा होता है (कम से कम अभी ट्रंक में)।
हकर्रे

वर्डप्रेस द्वारा प्रदर्शित चेतावनी संदेश के अलावा, उपयोगकर्ता के लिए संकेत देना असंभव है, क्योंकि स्थापना रद्द होने के समय यह पहले से ही निष्क्रिय है। लेकिन टिकट # 20578 देखें ।
JD

19

प्लगइन के फ़ोल्डर का नाम बदल दिया जाए

/ Plugins / pluginname / {} विभिन्न

फ़ोल्डर के लिए उपयोग किया जाने वाला "प्लगइननाम" हमेशा परिवर्तनशील होना चाहिए।

यह सामान्य रूप से स्थिरांक को परिभाषित करने और पूरे प्लगइन में उनका उपयोग करके नियंत्रित किया जाता है।

कई लोकप्रिय प्लगइन्स पापी हैं कहने की आवश्यकता नहीं है।

सम्बंधित:

  • plugins_url() प्लगइन के साथ शामिल संसाधनों के लिए आसान जोड़ने के लिए।

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

आपको वैसे भी परिवर्तन करने के बाद प्लगइन को फिर से सक्षम करना होगा (नाम परिवर्तन प्लगइन निष्क्रियता में परिणाम होगा), जिस बिंदु पर WP प्लगइन्स से संबंधित उचित DB प्रविष्टियों को फिर से बनाएगा या अपडेट करेगा (इसलिए यह नहीं होगा) सभी पर अद्यतन तोड़)।
t31os

एक निरंतर का उपयोग plugin_basename(__FILE__)करने के बजाय, प्लगइन के स्थानीय नाम का पता लगाने के लिए उपयोग करें। यह एक ही प्लगइन की प्रतियां (परीक्षण, कहीं और कई खातों लेकिन केवल एक प्रति प्लगइन, ...), की प्रतियां होने के लिए उपयोगी है।
राफेल

19

वर्डप्रेस (अंतर्निहित) त्रुटि हैंडलिंग का उपयोग करें

return;अगर कुछ उपयोगकर्ता इनपुट गलत था तो बस मत करो । उनके बारे में कुछ जानकारी गलत दी गई थी।

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

सभी के लिए एक त्रुटि (वस्तु)

आप बूटस्ट्रैप के दौरान अपने विषय या प्लगइन के लिए एक वैश्विक त्रुटि ऑब्जेक्ट सेट कर सकते हैं:

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

बाद में आप मांग पर असीमित त्रुटियां जोड़ सकते हैं:

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

फिर आप अपने विषय के अंत में उन सभी को ला सकते हैं। इस तरह से आप पेज रेंडर करने में बाधा नहीं डालते हैं और अभी भी विकास के लिए अपनी सभी त्रुटियों को आउटपुट कर सकते हैं

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

आप इस Q पर अधिक जानकारी प्राप्त कर सकते हैं । संबंधित टिकट "एक साथ काम करने" को ठीक करने के लिए WP_Errorऔर wp_die()वहां से जुड़ा हुआ है और एक अन्य टिकट का अनुसरण करेगा। टिप्पणियाँ, आलोचकों और इस तरह की सराहना की है।


यदि आप केवल गुण तक पहुँचते हैं और कभी भी वस्तु के रूप में उदाहरण को पास नहीं करते हैं तो आप WP_Error ऑब्जेक्ट को तुरंत क्यों भेजते हैं?
6

@ProfK मैंने इसे छोटा किया और शीर्षक / सामग्री wp_die();गलत थी (उलट)। आपके प्रश्न के बारे में) मुझे यह पूरी तरह से नहीं मिला। जब आप WP_Error वर्ग का एक उदाहरण की स्थापना आप जैसे कार्यों के माध्यम से अपने डेटा पर पहुंच सकते हैं get_error_code();, get_error_message();, get_error_data();और एकाधिक संस्करणों। आप इसे केवल एक बार अपने विषय या प्लगइन के बूटस्ट्रैप पर इंस्टेंट कर सकते $error->add();हैं और अन्य त्रुटियों को भरने के लिए उपयोग कर सकते हैं और अंत में इसे $error->get_error_messages();उन सभी को पकड़ने के लिए पाद लेख में आउटपुट कर सकते हैं।
कैसर

@ProfK मैं इस Q में भविष्य के अपडेट पोस्ट करूंगा । मैं वर्तमान में wp त्रुटि वर्ग के व्यवहार का निरीक्षण कर रहा हूं और एक सार्वजनिक थीम त्रुटि एपीआई (पहले से किए गए मसौदे) के बारे में एक टिकट लिखना चाहता हूं। आपको क्यू के तल पर एक साथ आने वाले WP_Errorऔर wp_die()पास होने वाले (पहले से ही एक पैच) एक और टिकट का लिंक मिल जाएगा । कोई भी टिप्पणी, सुझाव, आलोचक और अन्य बहुत सराहना की जाती है।
kaiser

18

वैश्विक नामस्थान में नाम जोड़े गए

एक प्लगइन को कम करना चाहिए यह वैश्विक नेमस्पेस में जोड़े जाने वाले नामों की संख्या को कम से कम करके संभव है ।

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

कार्यों और कक्षाओं के आगे, एक प्लगइन को वैश्विक चर का परिचय नहीं देना चाहिए । सामान्य रूप से कक्षाओं का उपयोग करने से उनका पालन होता है और यह प्लगइन रखरखाव को सरल करता है।

सम्बंधित


क्या आप कृपया "वैश्विक वेरिएबल्स का परिचय नहीं देना चाहिए" का जवाब स्वयं दे सकते हैं? यह इस सवाल से अलग से संबंधित है और वास्तव में मैं एक बहस करना चाहता हूं (दोनों क्योंकि मुझे लगता है कि मैं असहमत हूं विशेष मामले हैं और क्योंकि मैं दूसरों की राय से सीखना चाहता हूं।)
माइकस्किंकेल

17

PhpDoc का उपयोग करके टिप्पणी करें

सर्वश्रेष्ठ अभ्यास PhpDoc शैली के करीब है। यदि आप "ग्रहण" जैसी आईडीई का उपयोग नहीं करते हैं, तो आप बस PhpDoc मैनुअल पर एक नज़र डाल सकते हैं

आपको यह जानने की ज़रूरत नहीं है कि यह कैसे काम करता है। प्रोफेशनल डेवलपर्स वैसे भी कोड पढ़ सकते हैं और बस इसे सारांश के रूप में चाहिए। हॉबी कोडर्स और उपयोगकर्ता आपके उसी ज्ञान के स्तर पर इसे समझाने के तरीके की सराहना कर सकते हैं।


17

Add_option से पहले सेटिंग API का उपयोग करें

Add_option फ़ंक्शन के माध्यम से DB में विकल्प जोड़ने के बजाय, आपको सेटिंग्स API का उपयोग करके उन्हें एक सरणी के रूप में संग्रहीत करना चाहिए जो आपके लिए सब कुछ का ख्याल रखता है।

Add_option से पहले थीम मॉडिफिकेशन API का उपयोग करें

संशोधन एपीआई एक बहुत सरल निर्माण और एक सुरक्षित तरीका जोड़ने और विकल्प पुन: प्राप्त करने की अनुमति देता है। सब कुछ आपके डेटाबेस में क्रमबद्ध मान के रूप में सहेजा जाता है। आसान, सुरक्षित और सरल।


1
और इसके अलावा, का उपयोग करें update_optionऔर कभी नहीं add_option, अद्यतन फ़ंक्शन विकल्प मौजूद होगा जब यह मौजूद नहीं है .. :)
t31os

3
मैं यह नहीं कहूंगा कि कभी उपयोग नहीं होगा add_option। एक अच्छा उपयोग मामला है add_optionजहां के लिए यदि विकल्प पहले से ही सेट है, तो इसे परिवर्तित नहीं किया गया है, इसलिए मैं सक्रिय रूप से संभवतः पहले से ही उपयोगकर्ता की प्राथमिकताओं को संरक्षित करने के लिए इसका उपयोग करता हूं।
प्रॉक्ट

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

16

प्लगइन उपयोगकर्ता गोपनीयता की रक्षा करें

(पूर्व में: बेनामी एपीआई संचार)

यदि कोई प्लग-इन किसी बाहरी सिस्टम या एपीआई (जैसे कुछ वेब्स सर्विस) के साथ संचार करता है, तो उसे गुमनाम रूप से ऐसा करना चाहिए या उपयोगकर्ता को एक अनाम विकल्प प्रदान करना चाहिए जो यह सुनिश्चित करता है कि प्लगइन के उपयोगकर्ता से संबंधित कोई डेटा निर्विरोध दूसरी पार्टी को लीक न हो।


15

WordPress.org पर मेजबान प्लगइन्स

WordPress.org पर दिए गए SVN रिपॉजिटरी का उपयोग प्लगइन्स को होस्ट करने के लिए करें। यह एक आसान अपडेट उपयोगकर्ता-अनुभव के लिए बनाता है और यदि आपने पहले कभी एसएनएन का उपयोग नहीं किया है, तो यह आपको इसे एक संदर्भ में उपयोग करके वास्तव में समझने के लिए मिलता है।


15

अनुमतियों का उपयोग करके एक्सेस कंट्रोल प्रदान करें

कई उदाहरणों में, उपयोगकर्ता यह नहीं चाहते हैं कि हर कोई आपके प्लगइन द्वारा बनाए गए क्षेत्रों तक पहुंच प्राप्त कर सकता है, विशेष रूप से प्लगइन्स के साथ जो कई जटिल ऑपरेशन करते हैं, एक एकल हार्डकोड क्षमता की जांच पर्याप्त नहीं हो सकती है।

बहुत कम से कम, सभी प्रकार की प्रक्रियाओं के लिए उपयुक्त क्षमता की जांच करें, जिसके लिए आपके प्लगइन का उपयोग किया जा सकता है।


12

आयात / निर्यात प्लगइन सेटिंग्स

यह प्लगइन्स भर में आम नहीं है, लेकिन अगर आपके प्लगइन में कुछ सेटिंग्स हैं, तो यह कॉन्फ़िगरेशन और उपयोगकर्ता इनपुट जैसे डेटा का आयात / निर्यात प्रदान करना चाहिए

आयात / निर्यात एक प्लगइन की प्रयोज्य में सुधार करता है।

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

सम्बंधित


12

अपना कोड व्यवस्थित करें

यह कोड को पढ़ना मुश्किल है जो उस क्रम में नहीं लिखा गया है जिसे वह निष्पादित करता है। पहले शामिल करें / आवश्यकता, परिभाषित करें, wp_enqueue_style & _script, आदि, फिर फ़ंक्शन जिन्हें प्लगइन / थीम की आवश्यकता है और अंतिम में बिल्डर (उदा। व्यवस्थापक स्क्रीन, सामान जो विषय में एकीकृत होता है, आदि)।

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

यह एक संरचना है जिसे आप अक्सर दोहराते हैं, इसलिए आप हमेशा अपना रास्ता ढूंढते हैं। विभिन्न परियोजनाओं पर एक ज्ञात संरचना में विकसित करने से आपको इसे बेहतर बनाने के लिए समय मिलेगा और यहां तक ​​कि अगर आपका ग्राहक किसी अन्य डेवलपर पर स्विच करता है, तो आप कभी नहीं सुनेंगे "उसने एक अराजकता छोड़ दी"। यह आपकी प्रतिष्ठा बनाता है और एक दीर्घकालिक लक्ष्य होना चाहिए।


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

11

शैली के साथ मरो

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

उपयोग करने से wp_die()यह भी पता चलता है कि आपके प्लगइन्स / थीम वर्डप्रेस टेस्टसुइट के साथ संगत हैं ।

सम्बंधित:

11

उपयोगकर्ताओं के लिए सहायता स्क्रीन प्रदान करें

प्रश्नकाल और समय का उत्तर देने की तुलना में उत्तर के रूप में RTFM (मदद पर क्लिक करना) कहना अच्छा है।

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

अद्यतन / नोट: (केसर से टिप्पणी देखें): उपरोक्त उदाहरण एक कक्षा में उपयोग किया जाना है


हर उपकरण टूलबॉक्स में होना चाहिए (जब तक आपको एक विशिष्ट व्यवस्थापक यूआई स्क्रीन को स्पष्ट करना है)। +1
केसर

Btw: आपको उल्लेख करना चाहिए, कि यह एक वर्ग में निवास करने के लिए है और इस $ के साथ बातचीत कैसे करें -> _ page_id & यह कैसे होगा यदि आप एक फंक्शन से एक्शन हुक जोड़ेंगे। एक क्लास के बिना एक प्लगइन फ़ाइल या एक प्लगइन फ़ाइल ।
कैसर

10

एक्स्टेंसिबल फॉर्म की पेशकश करें

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

देखें: सेटिंग्स एपीआई

सम्बंधित


9

सीधे हुक के माध्यम से फ़ंक्शन शामिल करें, सीधे नहीं।

उदाहरण:

  • बिना हुक के नए के माध्यम से प्लगइन के वर्ग को शामिल न करें

  • हुक plugins_loaded का उपयोग करें

    // add the class to WP                                   
    function my_plugin_start() {                                                               
        new my_plugin();   
    }                                                        
    add_action( 'plugins_loaded', 'my_plugin_start' );

अद्यतन: एक छोटा सा लाइव उदाहरण: प्लग-इन-ट्रंक-पेज और एक छद्म उदाहरण

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

आप बहु-संस्थापन पर mu_plugins_loaded के माध्यम से भी लोड कर सकते हैं, कार्रवाई संदर्भ के लिए कोडेक्स देखें: http://codex.wordpress.org/Plugin_API/Action_Reference यहां भी आप यह देखते हैं, कि कैसे इस हुक के साथ inlcude wP: http: // adambrown। जानकारी / पी / wp_hooks / हुक / plugins_loaded; संस्करण = 2.1 और फ़ाइल = wp-settings.php मैं इसे बहुत बार उपयोग करता हूं और यह इतना कठिन और प्रारंभिक नहीं है, एक कठिन नए वर्ग के रूप में बेहतर है ();


@bueltige --- क्या आप इसे थोड़ा और समझा सकते हैं
NetConstructor.com

3
एक छोटा सा जीवंत उदाहरण: [प्लगइन- एसएनएन -ट्रंक-पेज] svn.wp-plugins.org/filter-rewrite-rules/trunk/… और एक छद्म उदाहरण //avoid direct calls to this file where wp core files not present if (!function_exists ('add_action')) { header('Status: 403 Forbidden'); header('HTTP/1.1 403 Forbidden'); exit(); } if ( !class_exists( 'plugin_class' ) ) { class plugin_class { function __construct() { } } // end class function plugin_start() { new plugin_class(); } add_action( 'plugins_loaded', 'plugin_start' ); } // end class_exists
21

2
@ Netconstructor.co - मैंने थ्रेड को अपडेट किया है, कोड के लिए टिप्पणी ist बदसूरत है
21

8

एक GPL संगत लाइसेंस के तहत लाइसेंस प्लगइन्स

प्लग-इन और थीम को वर्डप्रेस-संगत लाइसेंस के तहत लाइसेंस प्राप्त किया जाना चाहिए। यह उन्हें वर्डप्रेस के साथ "प्रोग्राम" के रूप में फिर से वितरित करने में सक्षम बनाता है। एक अनुशंसित लाइसेंस GPL हैध्यान रखें कि प्लग-इन के साथ शामिल सभी कोड लाइब्रेरी एक ही लाइसेंस के साथ संगत हैं।

(यह अतीत और वर्तमान दोनों में बहस का एक समस्या और गंभीर मुद्दा रहा है ।)


आइए, फिलहाल GPL की अनुकूलता को छोड़ दें: core.trac.wordpress.org/ticket/14685
hakre

8

आपके प्लगइन विवरण को आपके प्लगइन के कार्यों का सटीक विवरण देना चाहिए। 10 विशेष रुप से पोस्ट प्लगिन हैं। उनमें से सभी में विशेष रुप से प्रदर्शित पोस्ट हैं, फिर भी कई में अलग-अलग विशेषताएं हैं। विवरण को पढ़कर अपने प्लगइन की तुलना समान प्लगइन्स से करना आसान होना चाहिए।

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


7

दूरस्थ डेटा स्रोत और वेबसर्विस के साइड-इफेक्ट्स को कम से कम करें

एक प्लगइन को कैशिंग / शील्ड वेब्स सर्विस और / या XMLRPC / SOAP अनुरोधों को कैशिंग / डेटा-प्रोवाइडर लेयर के माध्यम से करना चाहिए यदि आप उनका उपयोग करते हैं तो सामने वाले अनुरोधों को (धीमी) वेबसेवर प्रतिक्रिया की प्रतीक्षा नहीं करते।

जिसमें RSS फ़ीड और अन्य पृष्ठों का डाउनलोड शामिल है। अपने प्लगइन्स को डिज़ाइन करें जो वे पृष्ठभूमि में डेटा का अनुरोध करते हैं।

एक संभावित चरण है

  1. हर बार जब आप ping.fm को अपडेट सबमिट करना चाहते हैं, तो उसे इस तालिका में जोड़ें।
  2. अब, हमें इस डेटा को संभालने के लिए एक प्लगइन बनाने की आवश्यकता है। यह प्लगइन अभी तक सबमिट नहीं किए गए हर अपडेट की जाँच करने के लिए crontab के माध्यम से चलेगा
  3. क्योंकि हमारे पास यह तालिका है, हम ping.fm को भेजे गए प्रत्येक संदेश को सूचीबद्ध कर सकते हैं और प्रत्येक पोस्ट की स्थिति की जांच कर सकते हैं। बस अगर वहाँ समस्या है ping.fm की ओर, हम इसे फिर से प्रस्तुत कर सकते हैं।

मैं वास्तव में यह नहीं समझ पा रहा हूँ कि आप वास्तव में इसके साथ कहाँ हैं। क्या आप सहायक सामग्री के लिए कुछ लिंक प्रदान कर सकते हैं?
माइकस्किंकल

इसके अलावा, मुझे बिल्कुल यकीन नहीं है कि "नेट ओवरहेड" क्या है। क्या कोई बेहतर शब्द नहीं है? यदि यह अधिक स्पष्ट है तो यह एक बेहतर उद्देश्य नियम होगा। और रोकें " ; असंभव है कम से कम" " के बजाय?
MikeSchinkel

शायद तुम सही हो। खराब शब्दांकन और रोकथाम कभी संभव नहीं है, बेहतर फिट को न्यूनतम करें।
हक्रे 20

7

अपने प्लगइन का परीक्षण करें

हम निश्चित रूप से हमारे प्लगइन विकास पर्यावरण पर कुछ परीक्षण उपकरण होना चाहिए।

एथन सेफर्ट द्वारा एक परीक्षण प्रश्न के उत्तर के आधार पर , ये अनुसरण करने के लिए अच्छे व्यवहार हैं:

  • आपकी इकाई परीक्षण को उस छोटी से छोटी मात्रा के व्यवहार का परीक्षण करना चाहिए जो एक वर्ग कर सकता है।
  • जब आप कार्यात्मक परीक्षण के स्तर तक पहुँच जाते हैं, तो यह वह जगह है जहाँ आप वर्डप्रेस निर्भरता के साथ कोड का परीक्षण कर सकते हैं।
  • निर्भर करता है कि आपका प्लगइन क्या करता है - सेलेनियम-आधारित परीक्षणों का उपयोग करने पर विचार करें जो आईडी का उपयोग करके डोम में डेटा की उपस्थिति के लिए परीक्षण करते हैं

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

1
लेकिन पहले सबसे छोटा कवर बुनियादी है, ताकि आप वर्डप्रेस के साथ कार्यात्मक परीक्षण तक पहुंच सकें, जैसा कि उत्तर कहता है, क्या यह सही नहीं है?
फर्नांडो ब्रायनो

1
यह एक प्लगइन है जो एक एप्लिकेशन नहीं है, क्या आप जावा रनटाइम के बिना जावा एप्लिकेशन का परीक्षण कर सकते हैं? हां, जावा को मॉकअप के रूप में लिखकर और फिर अपने प्लगइन का परीक्षण करें। संभावना है कि कीड़े आपके मजाक में हैं। *) अस्वीकरण या देशी कोड के लिए संकलन।
एडेलवाटर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.