http___media-x.hr_woocommerce-ucitavanje-js-i-css-skripti-samo-na-stranicama-shopa__1.xml
1.1 2.1 3.1 4.1 5.1 6.1 6.2 7.1 8.1 9.1 10.1 11.1 12.1 12.2 13.1 13.2 13.3 14.1 14.2 15.1 16.1 16.2 17.1 18.1 19.1 20.1 20.2 20.3 21.1 22.1 23.1 24.1 24.2 24.3 25.1 26.1 27.1 27.2 28.1 28.2 29.1 30.1 31.1 32.1 33.1 33.2 34.1 35.1 36.1 37.1 37.2 37.3 38.1 39.1 40.1 41.1 42.1 43.1 43.2 44.1 45.1 46.1 46.2 47.1 47.2 47.3 48.1 48.2 49.1 51.1 55.1 57.1 59.1 61.1 63.1 96.1 99.1 101.1 103.1 105.1 108.1 110.1 112.1 112.2 115.1 117.1 119.1 121.1
[WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts Updated: August 30th, 2014 Introduction In this tutorial, I am going to introduce a WordPress technique that I believe was unpublished until I raised the question a few days ago on the WordPress forums. In short, the problem I was trying to solve was plugins unnecessarily loading their JavaScript and CSS on *every* page of the blog, even when doing so would achieve absolutely nothing and the plugin wouldn't do any work. I briefly mentioned this approach here but Scribu decided to expand on it by providing a nice Jedi-themed tutorial. It is available here. Let me explain using this example: - a code formatter plugin only does something useful when it sees a [code] shortcode in any post on the page. - most of your posts do not contain the [code] shortcode as you don't include code snippets that often or you only started using this particular plugin recently. - the plugin, however, loads the CSS and JS (which are most likely GeSHi and take up loads of space) on every page. - these CSS and JS do absolutely nothing on most page loads. - bandwidth is wasted, extra DNS and HTTP requests are processed, the browser is slowed down, and for what? For no good reason, other than the plugin author didn't know how to achieve this conditional loading. If you think about it, there are many plugins that only do something once in a blue moon. Table of contents, text manipulators, galleries, sliders, etc, etc. If only they loaded their frontend code strictly when necessary, most page loads would suddenly become much lighter. So what can we do to solve this? Let's look at a few techniques. Loading CSS And JS In Place? Here's one, albeit pretty bad, solution – only print the CSS and JS includes if and when you determine somewhere in the middle of loading the posts that the scripts and styles are indeed needed, then set a flag to avoid printing them again. In our example, that would be when the plugin detects the [code] shortcode. This, however, is a mediocre solution because, while it's not a bad idea to load Javascript in the footer, CSS should be loaded in the header, otherwise the page might look unformatted until the CSS is reached. Additionally, it's not the cleanest and most robust solution because you shouldn't be writing   and   tags manually but rather using wp_enqueue_style() and wp_enqueue_script() functions. What's This About wp_enqueue_FOO? Now, you might say: "What's this about wp_enqueue_style(), wp_enqueue_script(), and then hooking into 'wp_print_scripts', 'wp_print_styles', 'admin_print_scripts', and 'admin_print_styles' hooks"? You know about these, right? Right?? Allow me to explain this, in my opinion, greatest and most underused WordPress paradigm in a short refresher: This queuing system achieves 2 main goals: - the same scripts are not loaded multiple times, such as jQuery, scriptaculous, or any other custom script or style your plugins may share between each other or even other plugins. - it introduces support for establishing dependencies. You can specify that your script or style depends on another script or style, and WordPress will take care of loading them in the right order. Guaranteed. - oh what the hell, here's a 3rd one: elegance. Here is the way this usually works: - in the beginning of your plugin you attach to wp_print_scripts and/or wp_print_styles hooks. For example: What this will do is call the functions in the 2nd parameter when it's time to execute any functions associated with the hooks in the 1st parameter. It is the main principle behind the WordPress plugin architecture. - looking at the script example, in the enqueue_my_scripts() function, you can do something like: which would queue up your script to be printed later but only after jQuery. If you or some other plugin calls wp_enqueue_script() with the same first parameter (unique handle), it will just be ignored, rather than printed to the page twice. - styles are exactly the same, except you use wp_enqueue_style() There is a variation of this functionality for the admin styles and scripts – all you have to do is change the hooks to admin_print_styles and admin_print_scripts. Ozh made a nice post on this topic here – check it out. Enqueuing Alone Is Not Enough Enqueuing is great for loading your JS and CSS but using it alone doesn't achieve the conditional behavior that we are looking for here. This is a classic case of Chicken or the Egg, because WordPress makes only one pass through all of the content. You see, since the header needs to be printed before the content, wp_print_scripts and wp_print_styles hooks are triggered before you even get to the posts. If you enqueue a script or style from within the 'the_content' hook, for example, the queued up scripts and styles will never get printed. It's too late to print them then anyway, as you're already in the middle of printing the posts. The Solution What we need to do is take a step back, before even printing the header, and then peek ahead. Sure, this adds an extra pass over some data, but since no filters are applied during this process and if you avoid regular expressions (using stripos(), for example), this extra pass should be quite negligible. The upside, however, can be potentially very substantial. Credit goes to @white_shadow for the idea. This simple function fires before the header gets printed, as it's attached to the 'the_posts' hook. However, this time it has full access to the posts' content. I have tested this method and it works really well – if you have heavy scripts in your plugin, please do us, users, a favor and incorporate this logic into it. Conclusion In this tutorial, you have seen a method of loading scripts and styles for you plugin conditionally. This technique allows for less bloated pages and faster page loads. Plugin developers, what is your take on this solution? Do you use another method? Please share in the comments. Artem Russakovskii is a San Francisco programmer, blogger, and future millionaire (that last part is in the works). Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed. In the meantime, if you found this article useful, feel free to buy me a cup of coffee below. http://mfields.org/ http://lesterchan.net http://www.jlapitan.com http://ottodestruct.com http://contentsynergy.com http://iluni.org http://religionatthemargins.com/ Pingback: Add custom javascript files to the wordpress site | PHP SNIPPETS Pingback: How to create plugin in WordPress http://www.quangcaomedia.com Pingback: Basic WordPress Pligin | Knowledge Base Pingback: Create a Plugins | For Web Development and designer Experience Pingback: پیشنهاداتی برای توسعه و بهبود پلاگین | طراحی پوسته وردپرس، طراحی قالب وردپرس،طراحی سایت، طراحی وب سایت Pingback: What is the preferred way to add custom javascript files to the site? | CL-UAT Pingback: The Java Script Test | Andrew's Blog Pingback: Writing a Plugin « WordPress Codex | Erotica Magazine: Secret Confessions Pingback: » Just another Erotica site » Writing a Plugin « WordPress Codex Pingback: » WebDev -> WordPress -> Plugin Development Suggestions | dwaves.de
1.1 1.2 2.1 2.2 3.1 4.1 5.1 6.1 7.1 7.2 8.1 9.1 9.2 9.3 10.1 11.1 11.2 11.3 12.1 13.1 14.1 15.1 16.1 17.1 18.1 19.1 20.1 21.1 22.1 22.2 23.1 23.2 24.1 25.1 26.1 26.2 27.1 27.2 28.1 29.1 29.2 30.1 30.2 31.1 32.1 33.1 33.2 33.3 33.4 33.5 34.1 34.2 34.3 35.1 36.1 37.1 38.1 38.2 39.1 40.1 41.1 41.2 41.3 42.1 43.1 44.1 44.2 45.1 46.1 46.2 47.1 48.1 49.1 50.1 51.1 51.2 52.1 53.1 54.1 55.1 55.2 55.3 56.1
Najpopularniji plugin za e-commerce baziran na WordPressu je WooCommerce – excelling eCommerce plugin. Robustan, pouzdan, proširiv (uz more besplatnih i premium ekstenzija), aktivan na preko milijun instalacija. Nakon instalacije i osnovnog podešavanja postavki WooCommerca, kreirali ste pojedinačne stranice shopa (ili dopustili da ih plugin sam kreira). Po defaultu, kreiraju se slijedeće stranice: Osnova trgovine: /shop/ Košarica: /shop/cart/ Naplata: /shop/checkout/ Moj račun: /shop/my-account/ “Problem” je to što WooCommerce učitava svoje JavaScript i CSS datoteke na SVIM postojećim stranicama. Ukoliko to želite spriječiti i želite pozivati skripte i stilove samo na onim stranicama na kojima se one koriste te na taj način ubrzati svoj web i smanjiti broj requestova, čitajte dalje. Kako provjeriti koje se skripte učitavaju na mojem webu? U web pregledniku (browseru) otvorite stranicu. Možete istovremeno pritisnuti tipke CTRL i U ili desni klik i izaberete “View page source”. U novootvorenom tabu vidjet ćete kod stranice. Koje i koliko skripti učitava WooCommerce? Na čistoj, testnoj instalaciji WordPressa (4.2.2), instalirao sam WooCommerce (inačica 2.3.11). Koristio sam defaultnu temu, TwentyFifteen. Po defaultu, WooCommerce učitava: Stilovi - – woocommerce-layout.css - – woocommerce-smallscreen.css - – woocommerce.css Skripte - – woocommerce.min.js - – add-to-cart.min.js - – jquery.cookie.min,js - – cart-fragments.min.js - – jquery.blockUI.min.js Kao što vidite, učitava se podosta skripti. Svaka od njih je jedan HTTP request i zajedno s drugim skriptama koje pokreće vaša tema i dodatni pluginovi može značajno utjecati na brzinu učitavanja vaše stranice. Testirajmo koliko ove skripte utječu na naš web. Koristit ćemo dva online alata, Google Page Speed i WebPageTest. Prije optimizacije WooCommerce skripti Rezultati na webpagetest.org otkrivaju da je za učitavanje stranice potrebno malo manje od dvije sekunde te da na webu imamo 28 requestova. Google page speed: “Vaša stranica ima ovoliko resursa blokirajućih skripti: 10 i ovoliko blokirajućih CSS resursa: 5. To dovodi do kašnjenja u generiranju vaše stranice.” Od deset skripti, pet ih je ubacio WooCommerce. Od pet blokirajućih CSS resursa, WooCommerce je zaslužan za dva (jedan dodatno smeta na mobilnim uređajima). Nakon optimizacije WooCommerce skripti Rezultati na webpagetest.org otkrivaju da smo učitavanje stranice skratili na 1.6 sekundi a broj requestova smanjili na 19. Također, smanjila se i veličina stranice s 326KB na 307KB. Google page speed: “Vaša stranica ima ovoliko resursa blokirajućih skripti: 5 i ovoliko blokirajućih CSS resursa: 3. To dovodi do kašnjenja u generiranju vaše stranice”. Kod za učitavanje JS i CSS datoteka samo na stranicama WooCommerce shopa U functions.php datoteku aktivne teme dodajte slijedeći kod: function mx_woocommerce_script_cleaner() { //prvo provjeri da li je WooCommerce aktiviran if ( function_exists( 'is_woocommerce' ) ) { // Ukloni skripte i stilove (osim na stranicama shopa) if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() && ! is_account_page() ) { wp_dequeue_style( 'woocommerce-general'); wp_dequeue_style( 'woocommerce-layout' ); wp_dequeue_style( 'woocommerce-smallscreen' ); wp_dequeue_script( 'wc-add-to-cart' ); wp_dequeue_script( 'wc-cart-fragments' ); wp_dequeue_script( 'woocommerce' ); wp_dequeue_script( 'jquery-blockui' ); } } } add_action( 'wp_enqueue_scripts', 'mx_woocommerce_script_cleaner', 99 ); Znači, kreirali smo funkciju koja je prvo provjerila da li je WooCommerce aktivan, kako bi spriječili fatal error poruke. Zatim smo odredili da se skripte i stilovi ne koriste osim ako nismo na stranicama shopa. Ovisno o vašoj temi i postavkama weba, možda ćete imati potrebu pozivati WooCommerce skripte i stilove na još nekim stranicama. Na primjer, koristite li WooCommerce na naslovnici, u kod ćete dodati još !is_home. Koristite li ga na nakoj određenoj stranici, trebate dodati is_single( '22' ) , gdje broj 22 označava ID stranice. Kako doznati ID stranice, pročitajte ovdje. Ako želite dodati više stranica, koristite array : is_single( array( 17, 19, 1, 11 ) ). Drugim riječima, koristite tzv. Conditional tags. Više o tome na codex.wordpress.org/Conditional_Tags. Ako želite koristiti WooCommerce conditional tagove, službeni izvor je na docs.woothemes.com/document/conditional-tags Kako koristiti svoja CSS pravila za WooCommerce? Spomenuo sam ranije da WooCommerce po defaultu učitava tri stylesheet-a (CSS datoteke). Sve ih možete onemogućiti dodavanjem slijedećeg koda u functions.php teme: add_filter( 'woocommerce_enqueue_styles', '__return_empty_array' ); Ako radite custom temu i želite pisati svoja CSS pravila, na ovaj način možete ukloniti defaultne stilove i koristiti svoje. Također, nećete morati brinuti o gubitku podataka (čitaj: svojih css pravila) prilikom nadogradnje WooCommerce plugina. Ako želite onemogućiti samo određene stylesheetove, npr. za mobilne uređaje, dodajte slijedeći kod u functions.php datoteku teme : // Remove each style one by one add_filter( 'woocommerce_enqueue_styles', 'jk_dequeue_styles' ); function jk_dequeue_styles( $enqueue_styles ) { unset( $enqueue_styles['woocommerce-general'] ); // Remove the gloss unset( $enqueue_styles['woocommerce-layout'] ); // Remove the layout unset( $enqueue_styles['woocommerce-smallscreen'] ); // Remove the smallscreen optimisation return $enqueue_styles; } // Or just remove them all in one line add_filter( 'woocommerce_enqueue_styles', '__return_false' ); Konkretno, za mobilne uređaje je zaslužan woocommerce-smallscreen stylesheet. Za kraj, kako bi počeli koristiti svoja CSS pravila, potreban vam je slijedeći kod: function wp_enqueue_woocommerce_style(){ wp_register_style( 'mytheme-woocommerce', get_template_directory_uri() . '/css/woocommerce.css' ); if ( class_exists( 'woocommerce' ) ) { wp_enqueue_style( 'mytheme-woocommerce' ); } } add_action( 'wp_enqueue_scripts', 'wp_enqueue_woocommerce_style' ); Ovaj kod podrazumijeva da ćete, ukoliko ne postoji, u folderu aktivne teme kreirati folder css i u njega smjestiti woocommerce.css datoteku s vašim CSS pravilima. Izvor: Woothemes Docs Zaključak Dequeue skripti i stilova koje koristi WooCommerce samo je jedan mali korak prema bržoj i manjoj web stranici. Sličan postupak možete ponoviti za sve pluginove/funkcionalnosti koje koristite samo na određenim stranicama a ne sitewide. Na primjer, kontakt forme, galerije slika, slideri i slično. Možda podaci koji ilustriraju koliko smo ubrzali i smanjili naš web na prvu ne djeluju impresivno, no optimizacija weba je proces od mnogo sitnih koraka koji na kraju rezultiraju optimalnom brzinom učitavanja i , shodno tome, boljem korisničkom iskustvu posjetitelja ali i rankingu u rezultatima pretrage.