कहाँ प्लगइन / विषयों द्वारा बनाई गई PHP फ़ाइलों को स्टोर करने के लिए


12

ऐसे मामले हैं जिनमें एक प्लगइन या थीम को कहीं न कहीं एक php फ़ाइल बनाने की आवश्यकता होती है जो बाद में इसे शामिल कर सकती है। उदाहरण के लिए एक कैप्चा प्लगइन, या टहनी / चालाकी जैसी किसी तरह की एक टेंपलेटिंग प्रणाली (मेरी स्थिति में यह विजेट्स के संग्रह के लिए सरल टेम्पलेट इंजन है)।

यह फ़ाइल कहाँ बनाई जानी चाहिए?

केवल वही जगह है जिसके बारे में मैं सोच सकता हूँ wp-content/uploads/, लेकिन यह सिर्फ सही नहीं लगता है :)

तो क्या कोई सुरक्षित जगह है जहाँ आप फ़ाइलें बना सकते हैं, और उनके बारे में चिंता न करें कि उन्हें वर्डप्रेस / प्लगइन / थीम अपडेट पर हटा दिया जाए?

एक समाधान विषयों / प्लगइन्स निर्देशिका में एक बच्चा विषय / निर्देशिका बनाने के लिए हो सकता है ...

जवाबों:



5

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


हां, यह चर को बदलने के लिए अच्छा है (मेरे पास अब ऐसा कुछ है)। लेकिन अगर आप उपयोगकर्ता को IF या लूप ऑब्जेक्ट जैसे सशर्त टैग का उपयोग करने की अनुमति देना चाहते हैं, तो आपको php कोड लिखना होगा ...
onetrickpony

5

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

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


3

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

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

ग्रेविटी फॉर्म्स अपलोड की गई फ़ाइलों को अपने ही फोल्डर में अपलोड करते हैं। W3 कुल कैश wp-content का उपयोग करता है, लॉगिन रीडायरेक्ट मेरे द्वारा वर्णित विधि का उपयोग करता है।


1

यदि आपको फ़ाइलें (जैसे कि कैप्चा प्लगइन के लिए अस्थायी फ़ाइलें) बनाना चाहिए, तो आपको निश्चित रूप से \wp-content\uploads\(या एक कस्टम निर्देशिका जैसे \wp-content\plugin-slug-files\) का उपयोग करना चाहिए ।

अधिकांश अन्य कस्टम कोड को वास्तव में डेटाबेस में संग्रहीत किया जाना चाहिए।


1
और eval()यह? कोई रास्ता नहीं ...
onetrickpony

आपको क्या करने की आवश्यकता है eval()?
चिप बेनेट

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

यह विजेट / विजेट विकल्प के उपयोग के लिए पर्याप्त खिंचाव की तरह लगता है ...
चिप बेनेट

1
हरगिज नहीं। लेकिन IMHO अगर उपयोगकर्ता को कस्टम विजेट बनाने में अधिक लचीलेपन की आवश्यकता है, तो उपयोगकर्ता को कस्टम प्लगइन लिखना चाहिए, या कस्टम विजेट कोड को अपने थीम के फंक्शन्स.php फ़ाइल में जोड़ना चाहिए। क्यों एक प्लगइन है, जो विजेट बनाता है, जो उपयोगकर्ताओं को अन्य विजेट बनाने में सक्षम बनाता है?
चिप बेनेट

1

मैं हमेशा PSR-0 संगत ऑटोलैडर और एक पुस्तकालय फ़ोल्डर का सुझाव देता हूं जो बस काम करता है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.