Add jQuery UI's datepicker() where applicable

[Viper007Bond]

Obviously it'll need some skinning, but it's handy dandy:

​http://jqueryui.com/demos/datepicker/

It'd be slick to have that for choosing dates (for example publish dates). We should still allow manual entry though.

Datepicker linked to dropdowns might be nice. We'd need to massage its i18n to use our gettext.

+1. I'd really like a datepicker.
But themed; the example one on jquery.com is uuuglyyy...

+1, as well.

Hey guys, I know this is a bit early, but I have a pretty good understanding of this, and I'd like to tackle this if nobody else is. :)

Got any ideas on how the skin should look?

No patch.

punting this back pending patch

+1 for a proper date picker, scheduling is incredibly awkward at the moment.

Please merge with #11942

Just updating the link in the description

I'm working on a patch for this.
It should be available by the end of the week, maybe earlier.

Unified diff of the modified files

New files (JavaScript and CSS files)

It would be nice if you could find a way to avoid using date_parse_from_format().

Also, commonL10n.datePicker_month01 etc. is really ugly. Related: #11520

Replying to scribu:

It would be nice if you could find a way to avoid using date_parse_from_format().

Also, commonL10n.datePicker_month01 etc. is really ugly. Related: #11520

I can search a way to avoid using date_parse_from_format() but what is the problem with this function ? Does the problem come from my placeholder implementation of the function ?

Concerning the second point, I may use the official translations provided by jQuery for the date picker but I still need to provide at least translations for the time picker and the firstDay setting for the date picker. Is this OK if I leave those ones inside commonL10n or not ?

New unified diff of the modified files

New attachments include some modifications for the date picker translations by supporting official jQuery translations.

For the PHP side, I still use date_parse_from_format() as I don't find another way to handle dates correctly yet.

Note : replaced tar.gz attachment because a file was missing. Sorry for the typo in the file suffix but it is not possible for me to rename the attachment.

New package of the new files (JavaScript and CSS files)

Closed #18659 as dup.

#17952 / [18757] added jQuery datepicker to WP Core. Now is probably too late to get this ticket resolved in WP3.3, but it is a good candidate for WP3.4 Please make sure that patch is up to date.

Synced-with-lastest-trunk-revision unified diff of the modified files

Latest attachment contains my patch synced against today's latest trunk (WP 3.3 development version - r18813)

Is this patch missing something, or why this is not commited to trunk?

Patch seems awesome and not committing or giving advice how to improve it (so it gets commited) is just rude for the patch-maker. Wasting ones time on upgrading patch against trunk again and again!

Everybody needs this patch (or at least me!)

Is this patch missing something, or why this is not commited to trunk?

​http://wpdevel.wordpress.com/version-3-3-project-schedule/

Everybody needs this patch (or at least me!)

lol

related #18909

I've noticed with the current version of jQuery, and the current version of jQuery UI that the datepicker's events have issues (create, onChangeMonthYear, onSelect don't fire, beforeShowDay gives errors, onClose and beforeShow did work) At least with my tests.

Also, datepicker doesn't support "Theme CSS Scope" (for multiple themes per page).

Please also consider an html5 input[type="date"] with feature detection to fail back onto jQuery UI. Opera is the only decent native datepicker though.

+1 for this; I'd really like to be able to use datepicker() in plugins/themes. I don't see why the entire jQueryUI library wasn't added to core. Just because the WP core doesn't use it doesn't mean that plugins/themes won't, and it's counter-intuitive to have only parts of a library available. If you say that jQueryUI is bundled w/ WP then ALL of it should be bundled, not just certain parts.

I'm not suggesting that it be enqueued by default, of course, just that it should be available so that plugins/themes can enqueue it when needed.

Replying to iandunn:

I don't see why the entire jQueryUI library wasn't added to core.

It was, in WP 3.3.

Replying to scribu:

Replying to iandunn:

I don't see why the entire jQueryUI library wasn't added to core.

It was, in WP 3.3.

Ah, sweet :) I must have missed that.

Replying to scribu:

Replying to iandunn:

I don't see why the entire jQueryUI library wasn't added to core.

It was, in WP 3.3.

I think he meant the css themes...

If he did, there's a ticket for that already: #18909

+Let's do it!

Replying to WraithKenny:

Please also consider an html5 input[type="date"] with feature detection to fail back onto jQuery UI. Opera is the only decent native datepicker though.

This is also something shipping in Chrome since August 2012 and a quick 'looks at the iPhone' check, shows it is well implemented in iOS 5.x, so if this is added I think applying jQuery UI conditionally has to be the best way right?