This is a work in progress and may not be finished for some time.
However what I have is working – see the demo page. Still some stuff to do though.
This plugin might not be published until the upcoming jQuery UI 1.13.x release that fixes the deprecation warning when used in combination with jQuery 3.5.0+.
Why I Am Providing This
It is my opinion that a major failing with jQuery UI is that it is too complex to use, especially within the context of a CMS like WordPress. This plugin will aim to greatly reduce that complexity.
The custom feature sounds attractive, it means code a webmaster does not intend to use is not served from the website, but it breaks the ability to efficiently use a Public CDN and thus may actually slow down the loading of a page for a first-time visitor who will not have the website specific customized jQuery UI cached.
Also, what then happens three months later when the webmaster wants to use a library not in their customized version? They have to create a new customized version, meaning those who have the old customized version cached now are just like a first-time visitor because the version they have is no longer what the web application is using. And hopefully when creating the new customized version, they do not accidentally leave out something they do need but forgot they need.
Some developers, including WordPress, sort of solve this problem by having a ton of individual scripts (over 35 at last count) for the various jQuery UI features. Use more than a handful of the features and your web application becomes bloated with
<script src=""></script> nodes. And they still are not Public CDN friendly.
The same issues with the jQuery UI themes exist that exists with customized versions of the library.
In the context of a CMS like WordPress that allows plugins it is even worse because which style sheets to load should not be determined by plugin developers but rather by WordPress theme developers. However when writing a plugin that uses jQuery UI the plugin authoe does not even know if the WordPress theme will load any style sheets appropriate for the jQuery UI features their plugin uses.
WordPress Plugin Developers
What my WordPress plugin will do, it will detect when jQuery UI is being used by a page and at a minimum, it will load a default jQuery UI theme. That way WordPress plugin developers can use jQuery UI in their plugins and know that a CSS file is being loaded.
WordPress Theme Developers
Theme developers who are fine with letting the WordPress admin choose a default jQuery UI theme do not have to do anything. They can use jQuery UI (or not) without needing to worry about the CSS aspect, it will ‘just work’ and an appropriate CSS file will be loaded if any jQuery UI features are used.
For WordPress Theme developers who want to use a specific jQuery UI theme as part of their WordPress theme branding, two functions are provided:
If the WordPress Theme developer wants to use one of the many standard themes for jQuery UI they can call the
pipjqui_load_alternate_theme( $theme ) function.
In the event the WordPress host is using a CDN to load the jQuery UI theme, the jQuery UI base theme will still be loaded locally as a fallback in case CDN loading fails, but the jQuery UI theme from the CDN will be referenced after the base theme to override what is defined in it.
In the event the WordPress host is not using a CDN to load jQuery UI themes, then the standard theme specified by a WordPress theme will replace the jQuery UI base theme as a fallback for CDN failure is not needed.
Custom jQuery UI Theme
If the WordPress Theme developer has their own jQuery UI theme there will be a (not yet written) function that allows the WordPress Theme to specify the handle for the custom jQuery UI theme, the path to the CSS file with the theme, and what (if any) jQuery UI standard theme it has as a dependency that should be loaded first.
If I can not programmatically find a way to detect the version number associated with the current running theme, specifying that may be required too.
This WordPress plugin will only load the included jQuery UI on front-end pages. For administrative pages, the jQuery UI bundled with WordPress is used. This is intentional to avoid possible breakage of administrative pages. As such, any jQuery UI features you use for your plugin or theme administration will not make use of the jQuery UI provided by my plugin.
For WordPress plugin developers, I recommend that you write your plugins to work whether or not my unfinished Pipfrosch jQuery UI plugin is installed.
If your plugin requires this plugin then your plugin will not be compatible with themes that do jQuery UI themselves and confict with my plugin.
I recommend against loading any jQuery UI specific CSS, let that be for theme developers or for the site administrator to load if they are not using my plugin. You can recommend my plugin, but it would be a bad idea to require it.
When you register your plugin scripts that use jQuery UI, register them to depend upon the WordPress equivalent component that they use. That will work with or without this plugin.
For WordPress Theme developers that use jQuery UI, I do recommend you require my plugin.
I also recommend that part of your theme configuration allows the WordPress administrator to select from a list of jQuery UI themes that work well (or at least do not visually clash) with your WordPress theme, and load the WordPress administrator selected jQuery UI theme to replace the jQuery UI base theme CSS definitions.
If your WordPress Theme depends upon my plugin, then when you register any scripts that use jQuery UI you can just register them to require
jquery-ui but if your WordPress Theme does not require my plugin, then you have to have your scripts require the individual components and make sure the proper CSS files are loaded if the WordPress admin has not installed my plugin. A lot more work. Just have your WordPress themes require this plugin. Well, when it is finished.