गतिशील जावास्क्रिप्ट / सीएसएस उत्पन्न करने के लिए समाधान

Question

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

उदाहरण के लिए, आपके पास होमपेज पर एक फॉर्म है जो सबमिट पर एक अजाक्स अनुरोध, और एकल पृष्ठ पर एक अलग फॉर्म है। या सीएसएस के मामले में, आप एक ऐसा विषय बनाना चाहते हैं जो अपने उपयोगकर्ताओं को अपना लेआउट बनाने, रंग बदलने आदि की अनुमति देता है।

मेरे द्वारा देखे गए समाधान:

1. दस्तावेज़ के मुख्य भाग में कोड शामिल करें (या JS के मामले में अंत में)

2. एक विशेष अनुरोध करें जो साइट को आउटपुट करता है, जैसे site.com?get_assets । यह धीमा है क्योंकि WP दो बार लोड हो जाता है।

3. इसे एक निश्चित समय के लिए अस्थायी फ़ाइलों में संग्रहीत करें, और इसे वहां से लोड करें। सार्वजनिक थीम या प्लगइन्स के लिए बहुत विश्वसनीय नहीं है।

4. जावास्क्रिप्ट केवल - इसे एक सामान्य फ़ाइल में रखकर स्थिर करें जो हर बार लोड हो जाती है। इस स्थिति में आपको अपना कोड किसी भी स्थिति को संभालना होगा

क्या आप दूसरों को जानते हैं? आप किस रास्ते पर जाएंगे?

Comments

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

— अरोविराट

Answer 1

एक अतिरिक्त विकल्प, जिस तरह के मापदंडों के आधार पर आपको अंदर जाने की जरूरत है। आइए इसे (2 ए) कहते हैं। आप PHP स्क्रिप्ट भी बना सकते हैं, जो गतिशील रूप से उत्पन्न text/cssया text/javascriptइसके बजाय उत्पादन text/htmlकरते हैं, और उन्हें डेटा प्रदान करते हैं जो उन्हें वर्डप्रेस को लोड करने के बजाय जीईटी मापदंडों का उपयोग करने की आवश्यकता होती है। बेशक यह केवल तभी काम करता है जब आपको अपेक्षाकृत कम संख्या में अपेक्षाकृत कॉम्पैक्ट मापदंडों को पारित करने की आवश्यकता होती है। उदाहरण के लिए, मान लें कि आपको केवल किसी पोस्ट के URL या किसी फ़ाइल या इसी तरह की निर्देशिका में पास होने की आवश्यकता है, आप इसे निम्न प्रकार से कर सकते हैं:

शीर्ष लेख में।

 <script type="text/javascript" src="<?php print get_stylesheet_directory_uri(); 
 ?>/fancy-js.php?foo=bar&amp;url=<?php print urlencode(get_permalink($post->ID)); ?>"></script>

फैंसी- js.php में:

 <?php
 header("Content-type: text/javascript");
 ?>
 foo = <?php print json_encode($_GET['foo']); ?>;
 url = <?php print json_encode($_GET['url']); ?>;

आदि।

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

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

यदि आकार आपके एक पृष्ठ के वजन के मामले में समस्या पैदा करने के लिए पर्याप्त बड़ा हो जाता है, तो आप (2) या (2%) को आज़मा सकते हैं।

या फिर - यह शायद बेहतर विचार है - आप स्क्रिप्ट के उन हिस्सों या स्टाइलशीट को अलग करने की कोशिश कर सकते हैं जो वास्तव में उन हिस्सों से गतिशील डेटा का उपयोग करते हैं जो सांख्यिकीय रूप से निर्दिष्ट किए जा सकते हैं। Ssay आपके पास एक स्टाइलशीट है जिसे # my-फैंसी तत्व के लिए एक पृष्ठभूमि पैरामीटर सेट करने के लिए वर्डप्रेस से एक निर्देशिका पारित करने की आवश्यकता है। आप इस सभी को मुख्य तत्व में रख सकते हैं:

 <style type="text/css">
 #my-fancy-element {
      background-image: url(<?php print get_stylesheet_directory_uri(); ?>images/fancy.png);
      padding: 20px;
      margin: 20px;
      font-weight: bold;
      text-transform: uppercase;
      font-size: 12pt;
      /* ... KB and KB of additional styles ... */
 }
 #another-fancy-element {
     /* ... KB and KB of additional styles ... */
 }
 /* ... KB and KB of additional styles ... */
 </style>

लेकिन आपको ऐसा करने की आवश्यकता क्यों होगी? यहाँ केवल एक लाइन है जो वर्डप्रेस के डेटा पर निर्भर करती है। वर्डप्रेस पर निर्भर केवल लाइनों को विभाजित करने के लिए बेहतर है:

 <style type="text/css">
 #my-fancy-element {
      background-image: url(<?php print get_stylesheet_directory_uri(); ?>images/fancy.png);
 }
 </style>

एक स्टैटिक स्टाइलशीट में बाकी सब कुछ डालें जिसे आप एक मानक लिंक तत्व (style.css या जो भी हो) के साथ लोड करते हैं:

 #my-fancy-element {
      /* background-image provided dynamically */
      padding: 20px;
      margin: 20px;
      font-weight: bold;
      text-transform: uppercase;
      font-size: 12pt;
      /* ... KB and KB of additional styles ... */
 }
 #another-fancy-element {
     /* ... KB and KB of additional styles ... */
 }
 /* ... KB and KB of additional styles ... */

और कैस्केड काम करते हैं।

वही जावास्क्रिप्ट के लिए जाता है: ऐसा करने के बजाय:

 <script type="text/javascript">
 // Here comes a huge function that uses WordPress data:
 function my_huge_function () {
     // Do a million things ...

     jQuery('#my-fancy').append('<a href="'+<?php json_encode(get_permalink($GLOBALS['post']->ID)); ?>+'">foo</a>);

     // Do a million more things ...

     my_other_function(<?php print json_encode(get_userdata($GLOBALS['post']->post_author); ?>);
 }

 function my_other_function (user) {
     // Do a million things ...
 }
 </script>

इसके बजाय सिर तत्व में कुछ इस तरह से डाल:

 <script type="text/javascript">
 var WordPressPostData = {
 url: <?php print json_encode(get_permalink($GLOBALS['post']->ID)); ?>,
 author: <?php print json_encode(get_userdata($GLOBALS['post']->post_author)); ?>
 }
 </script>

और फिर ग्लोबल्स वर्डप्रेसपोस्टडाटा.उर्ल और वर्डप्रेसपोस्टडाटा.ओथोर का उपयोग करने के लिए my_huge_function () और my_other_function () को फिर से लिखना, एक स्थिर जावास्क्रिप्ट फ़ाइल में बाकी को छोड़ दें।

CSS के 40K या JS के 40K को लगभग हमेशा <1K में विभाजित किया जा सकता है जो वास्तव में डायनेमिक डेटा पर निर्भर करता है, और बाकी, जो एक स्थिर बाहरी फ़ाइल में निर्दिष्ट किया जा सकता है और फिर कैस्केड (सीएसएस के लिए) या वैश्विक रूप से सुलभ का उपयोग करके पुनर्संयोजित किया जा सकता है चर (ग्लोबल्स, डोम तत्व, या जो भी अन्य क्यूबी-छेद आप पसंद करते हैं, जेएस के लिए)।

Comments

शानदार जवाब!

— scribu

बस एक छोटा सा जोड़: जेएस के मामले में, हम उपयोग कर सकते हैं डायनामिक चर जोड़ने के wp_localize_sciprt का ।

— अनह त्रान

Answer 2

गतिशील सीएसएस मामला काफी सरल है।

बस एक फ़ंक्शन बनाएं जो <style type="text/css"></style>टैग के अंदर गतिशील सीएसएस परिभाषाओं को आउटपुट करता है , और फिर उस फ़ंक्शन को हुक करता है wp_print_styles। जैसे

<?php
function mytheme_dynamic_css() {
    $options = get_option( 'mytheme_options' );
    ?>
    <style type="text/css">
    /* Dynamic H1 font family */
    h1 { font-family: <?php echo $options['h1_font_family']; ?>;
    </style>
    <?php
}
add_action( 'wp_print_styles', 'mytheme_dynamic_css' );
?>

या, मान लें कि आपके पास पूर्व-कॉन्फ़िगर की गई रंग योजनाएं हैं; आप वर्तमान उपयोगकर्ता सेटिंग के अनुसार उपयुक्त स्टाइलशीट को संलग्न कर सकते हैं:

<?php
function mytheme_enqueue_colorscheme_stylesheet() {
    $options = get_option( 'mytheme_options' );
    $color_scheme = $options['color_scheme'];
    wp_enqueue_style( $colorscheme, get_template_directory_uri() . '/css/' . $color_scheme . '.css' );
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_colorscheme_stylesheet' );
?>

ध्यान दें, इस मामले में, फ़ंक्शन हुक wp_enqueue_scriptsकरता है, क्योंकि वर्डप्रेस में wp_enqueue_stylesएक्शन हुक नहीं है ।

Comments

समान 1)। यह वही है जो मैं अभी कर रहा हूं, लेकिन अगर आपको सीएसएस के 40K पसंद है तो आपको एक भारी HTML दस्तावेज़ मिलेगा

— onetrickpony

लेकिन सीएसएस के उन 40K का उत्पादन कहीं न कहीं होना चाहिए , है ना? और, निश्चित रूप से # 1 जैसा ही है, लेकिन वर्डप्रेस में गतिशील सीएसएस को इंजेक्ट करने का सही तरीका है। :)

— चिप बेनेट

Answer 3

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

अगर मैं javascript / css फाइल को php के माध्यम से लिखूं जब एडमिन डाटा को सेव कर रहा है। यह एक बार लिखा जाएगा जब तक उपयोगकर्ता लेआउट को फिर से नहीं बदलता (जो उपयोगकर्ता बहुत बार नहीं कर सकता है)। इस तरह हम उपयोगकर्ता डेटा की बचत करते समय केवल एक बार उपयोगकर्ता सेटिंग्स के लिए डेटाबेस तक पहुँच रहे हैं।

फाइल लिखने के बाद यह एक नियमित जावास्क्रिप्ट / सीएसएस फाइलें होगी ताकि हमें डेटाबेस को हर बार थीम लोड करने के लिए कॉल न करना पड़े।

एक प्रश्न जिसका उत्तर दिया जाना आवश्यक है: क्या होगा जब कोई आगंतुक फ़ाइल को लिखते समय तत्काल साइट तक पहुँचने का प्रयास करे?

आप क्या सोचते हैं मुझे बताओ।

Comments

यदि आप उन फ़ाइलों को उत्पन्न करते हैं wp-content/uploads(केवल निर्देशिका WP कोड से लिखने योग्य होने की गारंटी देता है), तो यह एक व्यवहार्य दृष्टिकोण हो सकता है। मुझे लगता है कि यहां तक ​​कि WP कोर एक जेएस फ़ाइल के लिए इस तकनीक का उपयोग करता है।

— scribu

दोष यह है कि यह वास्तव में गतिशील नहीं है, अर्थात यह सभी पृष्ठों पर सभी के लिए समान है। प्रत्येक भिन्नता के लिए, आपको एक नई फ़ाइल बनानी होगी। यह अभी भी विषय / प्लगइन विकल्पों के लिए एक अच्छा तरीका है, जैसा कि आपने उल्लेख किया है।

— scribu

@ स्क्रिपु: हाँ यह सच है। यह किसी चीज़ के लिए गड़बड़ हो सकता है। अगर हम उपयोगकर्ताओं को एक अनुकूलित प्रोफ़ाइल पृष्ठ देते हैं और उनमें से हर एक को फाइल लिखना है। लेकिन यह कुछ के लिए एक अच्छा तरीका हो सकता है जैसे अगर हम एक विज़ुअल वेबसाइट निर्माता (ड्रैग एंड ड्रॉप) करते हैं जहां उपयोगकर्ता रंगों को बदलता है और विभिन्न प्रभावों को जोड़ता है (इस प्रश्न के अनुसार) आदि .. और WPMU के साथ जोड़ा जा सकता है;)

— सिसिर

Answer 4

स्क्रिप्ट के छोटे टुकड़ों के लिए, जिन्हें आप अलग फाइल में शामिल नहीं करना चाहते हैं, उदाहरण के लिए क्योंकि वे गतिशील रूप से उत्पन्न होते हैं, वर्डप्रेस 4.5 और आगे की पेशकश wp_add_inline_script। यह फ़ंक्शन मूल रूप से स्क्रिप्ट को किसी अन्य स्क्रिप्ट पर ले जाता है। उदाहरण के लिए, मान लीजिए कि आप एक थीम विकसित कर रहे हैं और चाहते हैं कि आपका ग्राहक विकल्प पृष्ठ के माध्यम से अपनी स्वयं की स्क्रिप्ट (जैसे Google Analytics या AddThis) सम्मिलित कर सके। उदाहरण है ।

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

if (!empty($all_mods)) wp_add_inline_style ('main-style', $all_mods);

Answer 5

एक गतिशील JS.php फ़ाइल बनाएँ और इसे महत्वपूर्ण क्वेरी_वर खिलाएँ। उन चर में $_GETफ़ाइल को संदर्भ निर्धारित करने में मदद मिलेगी और इसमें आप readfile()भविष्य के अनुरोधों को कैश और उपयोग कर सकते हैं ... जो भी करें।

बस यह सुनिश्चित करें कि फ़ाइल wp-load.phpकिसी और चीज़ से पहले लोड हो, इसलिए आपके पास WP फ़ंक्शन तक पहुंच है। वर्तमान फ़ोल्डर के सापेक्ष पथ का उपयोग करें (dirname(__FILE__))या wp-load.phpप्लगइन प्लेसमेंट की परवाह किए बिना केवल फ़ोल्डर संरचना में उतरते हुए खुदाई करें।

कहीं से भी wp-load.php लेने का कोड

// Ensure single declaration of function!
if(!function_exists('wp_locate_loader')):
    /**
     * Locates wp-load.php looking backwards on the directory structure.
     * It start from this file's folder.
     * Returns NULL on failure or wp-load.php path if found.
     * 
     * @author EarnestoDev
     * @return string|null
     */
    function wp_locate_loader(){
        $increments = preg_split('~[\\\\/]+~', dirname(__FILE__));
        $increments_paths = array();
        foreach($increments as $increments_offset => $increments_slice){
            $increments_chunk = array_slice($increments, 0, $increments_offset + 1);
            $increments_paths[] = implode(DIRECTORY_SEPARATOR, $increments_chunk);
        }
        $increments_paths = array_reverse($increments_paths);
        foreach($increments_paths as $increments_path){
            if(is_file($wp_load = $increments_path.DIRECTORY_SEPARATOR.'wp-load.php')){
                return $wp_load;
            }
        }
        return null;
    }
endif;
// Now try to load wp-load.php and pull it in
$mt = microtime(true);
if(!is_file($wp_loader = wp_locate_loader())){
    header("{$_SERVER['SERVER_PROTOCOL']} 403 Forbidden");
    header("Status: 403 Forbidden");
    echo 'Access denied!'; // Or whatever
    die;
}
require_once($wp_loader); // Pull it in
unset($wp_loader); // Cleanup variables

चीयर्स, स्क्रिबू!

पुनश्च : जटिल संरचनाओं के लिए जहां फ़ोल्डर्स सामान्य WP डिक्रीमेंटल संरचना का पालन नहीं करते हैं, माता-पिता प्लगइन्स सीधे पहुंच योग्य फ़ाइलों के साथ informations साझा कर सकते हैं। एक पेरेंट प्लगिन जो डायनेमिक PHP फाइल के साथ आता है जो CSS / JS को रेंडर realpath()करता है wp-load.phpऔर की फाइल में लिख सकता है और स्टैंडअलोन फाइल का उपयोग कर सकता है। यह WP उपयोगकर्ताओं के 0.1% के लिए एक मुद्दा होगा। मुझे लगता है कि जो लोग फ़ोल्डर्स को स्थानांतरित करते हैं और सामान्य संरचना का पालन नहीं करते हैं वे जानते हैं कि वे क्या कर रहे हैं और शायद PIMP प्लगइन्स को wp-load.phpसीधे लोड करने की आवश्यकता है ।

Comments

प्यारा! Haters, स्पष्टीकरण स्पष्ट करें। मुझे सूचित करो। धन्यवाद;) xoxo

— अर्नस्टोदेव

यह wp-load.phpएक थीम या प्लगइन फ़ाइल से शामिल करने के लिए बुरा व्यवहार है , क्योंकि wp-content/ और plugins निर्देशिका रूट WP dir के सापेक्ष कहीं भी हो सकती है। WP_CONTENT_DIR और WP_PLUGINS_DIR याद रखें।

— scribu

@scribu और स्टैंडअलोन फ़ाइल पैरेंट प्लगइन के साथ सहयोग कर सकती है। पैरेंट प्लगइन wp-load.php को उस फोल्डर में स्टोर कर सकता है जहाँ यह स्थित है और डायनेमिक js जनरेटर इसे वहां से पढ़ सकता है। सिंपल ...

— अर्नस्टोदेव

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

— स्क्राइब

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

— रास्त