Pretty cool slider, themable and it worked right out of the box for me!
On the technical side, I noticed that you don't register a version when enqueuing the style & the script for the front-end, in the file inc/class-cyclon-slider.php (you don't pass the version argument at all to the enqueuing functions).
So WordPress appends by default a query string at the end of the URL, with its own version. Query strings hurt GTmetrix Pagespeed ratings, so since you don't use the version anyway, you could pass it as null, thus forcing WP to not append a query string at all...
/*** Styles ***/ wp_register_style( 'cyclone-slider-plugin-styles', $cyclone_css, //contains our combined css from ALL templates array(), // dependencies (line added by me) null // '1.3.4' (line added by me) ); wp_enqueue_style( 'cyclone-slider-plugin-styles' ); /*** Scripts ***/ wp_register_script( 'cycle', $this->plugin_url . 'js/jquery.cycle.all.min.js', array('jquery'),// dependencies (line added by me) null, // '1.3.4' (line added by me) false // in footer? (line added by me) ); wp_enqueue_script( 'cycle' );
I was also wondering if it is worth it to come up with a different template structure, allowing cycle.js to be loaded at the bottom of the page, in an effort to improve the loading times of the page.
As it is right now, if we change false to true in the above code, the page containing the slider breaks (at least in my case). I guess that happens because you have combined all scripts into one file, in an effort to save some HTTP requests.
But frequent scripts are cached by the browser, so often we gain more speed if we split' em up and load as many of them as we can to the bottom of the page (and let the cache take care of the next requests).