Exactly my thought. I’m looking for a way as well to not load it.
EDIT: think i got it:
function dequeue_my_css() {
wp_dequeue_style('wptoolset-field-datepicker');
wp_deregister_style('wptoolset-field-datepicker');
}
add_action('wp_enqueue_scripts','dequeue_my_css',100);
It prevents from loading datepicker.css in the front-end. I’m not using any datepicker at all in the site, but be sure to double check the front-end and back-end if you do use them.
I’m also looking for a way now to not load jquery ui and datepicker javascript files. Pretty weird all those files being loaded in the front-end.
There was some talk about this in this other thread.
http://ww.wp.xz.cn/support/topic/bug-in-16-jquery-is-loaded-in-frontend?replies=9
Bottom line, at this time the datepicker css is still loading in the front end. The is_admin() conditional could be used to fix the problem. It’s not a critical bug I’m sure the authors will address it at some point.
Loading unnecessary backend files in frontend is actually a pretty serious bug.
Especially in this case where other theme- and/or plugin-css is messed up and loading times are slowed down.
This should be fixed asap.
Same problem here, hope the Types developer should fix it soon!
A small fix for a major problem. Not sure why it is taking so long for the Types authors to fix this issue.
At times like this I wish WordPress extend had all the robust functionality of Github including forks and pull requests.