2 Questions about plugin
-
1. Why is LightSlider needed?
2. Whydoes the plugin load on every page?
-
1. Why is LightSlider needed?
For the slideshow layout. See the example. In case you are not using the slideshow layouts I believe you can disable the LightSlider load via Photonic → Settings → Generic Options → Generic Settings → Don’t include third-party slider scripts.
2. Whydoes the plugin load on every page?
Because the basis for the plugin is a shortcode (or a block), and shortcodes can be included anywhere in your site – in posts, in pages, in pages with multiple posts, in widgets, in your site’s footer, in custom templates etc. This is essentially a chicken-and-egg situation, to not load on every page the plugin has to find out where all it is being used on every page (in case of usage in a widget it is not even possible to do that), but for that it has to be loaded. Just like how WordPress emojis or oEmbeds are included in every page straight out of the box (whether or not you use them), Photonic’s scripts are included on all pages. The same goes for any lightbox plugin.
They don’t get triggered unless they find any matching selector, though.
Hello Sayontan,
2. Why does the plugin load on every page?
You can register the photonic scripts and styles on every page or post. Only if the shortcode for photonic is detected, the scripts and styles should be enqueued.
Or you can have a menu that allows you to select which pages you want to load the scripts on. It can default to all pages so that the plugin stays working for everybody.
You can register the photonic scripts and styles on every page or post. Only if the shortcode for photonic is detected, the scripts and styles should be enqueued.
This has been under consideration for a while, but the only reason it hasn’t been done is due to a couple of caveats:
- The methods to enqueue differ for JS vs CSS – I can conditionally enqueue the JS as required, but CSS enqueueing is a different challenge. Best practices of web-design dictate that CSS should get loaded in the
<head>section of the page (so that the rest of the content is rendered correctly when loaded). However, if you try to load the CSS based on shortcode usage, you end up with one of the following:
- You load it right where the shortcode is invoked – this causes the CSS to repeat each time the shortcode is used
- Or you load it in the footer, which loads it once, but is undesirable from a usability point of view
- Or you parse each post for shortcodes / blocks and load the script in the header if required. This causes a major performance hit as you have to parse each post ahead of time before the post is actually displayed on the page. Also, this doesn’t work for content that is not within a post / page, e.g. something in your footer, or in a widget. And what if you are displaying the posts as excerpts or just with the titles (see below for what I mean)? The plugin will have no way to handle such nuances.
- The second reason this hasn’t been done yet is because Photonic’s JS has been designed (unintentionally, I admit) to run in the header. I have had cases where users have used optimization plugins that pushed Photonic’s scripts to the footer, and the results were erratic. The optimal solutions from the above push the script to the footer, and that would require a whole battery of tests and changes that would require a separate release.
Or you can have a menu that allows you to select which pages you want to load the scripts on. It can default to all pages so that the plugin stays working for everybody.
This wouldn’t work for the widgets and footer. Also, there is a challenge with this sort of a design – it adds a lot more complexity when you get down to thinking about it:
- If you have 5 posts on a page and one of them has Photonic enabled, you have to add the scripts. Note that travel-bloggers use Photonic in posts, not pages. You cannot set this at the page level in such a case, rather you have to consider all posts in a page.
- Now, let’s say you have the above scenario, and your theme shows you post excerpts or just the post titles or post thumbnails on the “Page of Posts” page (i.e. not the HTML content). Do you add Photonic scripts on such a page? You will be reading each post first and determining whether you want to load the script… but then your theme will decide what content to show and Photonic’s decision will be rendered irrelevant! What if you had another plugin that showed you post content, but it stripped out some filters?
I have been systematically reducing the JS footprint of the plugin – I got a 45% reduction in script size in 2.11 in November (this was a major change), and added minification support in 2.19 last week. The next iteration will cover the following:
- The cutting of the cord with some jQuery UI scripts (Dialog and Tooltip), reducing the dependence on a total of 7 jQuery UI files (over 80KB in combined data)
- Rewrites of some of the layouts (primarily justified grid and mosaic) to faster calls, bringing down the rendering to a few milliseconds.
As a part of this process I am also looking at optimizing things at other places as appropriate, and hopefully I will be able to ensure that at least the JS is loaded conditionally in the footer.
Ok, your plugin serves many types of galleries, I don’t know they all.
This is my special case:
- I’m using Google Photos and native WordPress galleries.
- I’m using the custom shortcode “photonic”.
- I’m using “Custom CSS in its own file”.
- I have only one shortcode “photonic” in any post or page.
- I don’t use any caching plugin.
The following code is in my functions.php:
function dequeue_photonic(){ wp_dequeue_script('photonic-slideshow'); wp_dequeue_style('photonic'); wp_dequeue_style('photonic-custom'); wp_dequeue_style('photonic-lightbox'); wp_dequeue_script('photonic'); wp_dequeue_script('photonic-lightbox'); wp_dequeue_style('photonic-slideshow'); } function enqueue_photonic(){ wp_enqueue_script('photonic-slideshow'); wp_enqueue_style('photonic'); wp_enqueue_style('photonic-custom'); wp_enqueue_style('photonic-lightbox'); wp_enqueue_script('photonic'); wp_enqueue_script('photonic-lightbox'); wp_enqueue_style('photonic-slideshow'); } // Dequeue for every page function dequeue_all_photonic(){ dequeue_photonic(); } add_action( 'wp_enqueue_scripts', 'dequeue_all_photonic' , 100); // Enqueue if shortcode exists add_filter('pre_do_shortcode_tag', function ( $output, $shortcode ) { if ( 'photonic' == $shortcode ) { enqueue_photonic(); } return $output; }, 10, 2);Maybe it will help somebody.
Thank you for the plugin, you makes a great job!
@hupe13,
Here is what I would recommend:- Don’t hook this into
pre_do_shortcode_tag– it will not work for Gutenberg blocks. - Don’t couple styles and scripts together. If you use the code above and dequeue style loading from the header, it is likely to cause a pretty bad effect on the rendering of your content (it also violates the W3 Spec for markup). I would say, take the hit in terms of loading the styles, and load the JS in the footer.
- Wait for the next release. There is a lot more optimization there, based on what is running where.
Multiple optimization changes have been made in 2.21 (just released). Bear in mind that the CSS is still loaded in the header, but overall the performance is a lot more spiffy right now.
Very good explanation and answers to my questions, thanks for your continued work on the plugin, it’s really the only one that works for us.
- The methods to enqueue differ for JS vs CSS – I can conditionally enqueue the JS as required, but CSS enqueueing is a different challenge. Best practices of web-design dictate that CSS should get loaded in the
The topic ‘2 Questions about plugin’ is closed to new replies.
