Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2017-09-13 13:36:18

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 7,682
Website

Re: Expiration datepicker

On a technical note, if we know the language (and hence locale?) in use on the admin side for the current user, can we reliably obtain the “preferred date format” for that locality? If so (e.g. ask PHP and find that dd/mm/yyyy is the preferred order for en-gb) there shouldn’t be any issue swapping the order of the individual date/month/year fields to match. And, if it can’t be obtained, for whatever reason, default to YYYY-MM-DD order like we do today.

That’s fine for multi-input boxes, but single input boxes represent a real headache. I’ve done it before on a separate project and it hurts. The date picker usually needs to be told what format is acceptable, so any existing dates need to be in that format before the picker is invoked. Plus, the input field needs to be told what format to accept. They MUST match. Manually altering the dates can wreak havoc, and I found some annoying corner cases where dates would show as ‘invalid’ or throw yucky PHP errors on submission because they didn’t quite match the format (e.g. omitting the leading 0 on days/months). It’s a minefield and I rather like my legs.

If date pickers can be invoked such that:

  1. they can correctly direct each part of the chosen date into separate boxes based on their name/ID; and
  2. they can read the “currently set” date from separate input boxes via their name/ID and display it in the widget

then that would be my preferred solution. Best of both worlds: unambiguous date display, unambiguous intepretation of incoming date portions, user-friendliness of a single date picker.

Now, as for time pickers…. urgh!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#12 2017-09-13 16:11:52

etc
Developer
Registered: 2010-11-11
Posts: 2,248
Website

Re: Expiration datepicker

Bloke wrote #306981:

If date pickers can be invoked such that:

  1. they can correctly direct each part of the chosen date into separate boxes based on their name/ID; and
  2. they can read the “currently set” date from separate input boxes via their name/ID and display it in the widget

then that would be my preferred solution. Best of both worlds: unambiguous date display, unambiguous intepretation of incoming date portions, user-friendliness of a single date picker.

Yes they can, kinda.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#13 2017-09-13 16:29:11

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 2,755
Website

Re: Expiration datepicker

Thanks for the test plugin Oleg.

If any date picker was going into core itself, I’d prefer it as an icon to the side of the input fields which gives users the option to use it or not.

Small notes: Your example only works if the year field is activated, not the month or day fields. Also seems to not be showing the selected day styling on the date picker either – not sure if it’s my code or something in the above plugin (the selected day should be highlighted in blue on the picker).

Offline

#14 2017-09-13 17:31:20

etc
Developer
Registered: 2010-11-11
Posts: 2,248
Website

Re: Expiration datepicker

philwareham wrote #306983:

If any date picker was going into core itself, I’d prefer it as an icon to the side of the input fields which gives users the option to use it or not.

I’d prefer all UI widgets (datepicker, autoresizer, etc) be either pluggable or even theme features, eventually with configurable options. Anyway, users can still use the keyboard to input dates. As an icon, I would rather add a “no expiry” link; emptying three expiry fields (though one suffices) is boring.

Small notes: Your example only works if the year field is activated, not the month or day fields. Also seems to not be showing the selected day styling on the date picker either – not sure if it’s my code or something in the above plugin (the selected day should be highlighted in blue on the picker).

It’s very easy to extend it to the month/day fields, but three datepickers feel a bit redundant. And the selected day is highlighted in my tests, but very lightly (pale gray).


etc_[ query | search | pagination | date | tree | cache ]

Offline

#15 2017-09-13 23:26:15

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,122
Website

Re: Expiration datepicker

etc wrote #306984:

I’d prefer all UI widgets (datepicker, autoresizer, etc) be either pluggable or even theme features, eventually with configurable options.

Ditto that. For my personal websites (and some of my clients), I have no use for a date picker. it might even get in the way. But it can be very useful for sites that run campaigns (end date) or events. My preference is a plugin for this kind of things.

Anyway, users can still use the keyboard to input dates.

Your v.021 works fairly well for a keyboard user, in that on can now input a date manually. The calendar itself is unreachable – one have to use a mouse/trackpad and move the cursor (but that is probably a limitation of the JQ-UI widget itself – they seem to be aware of it, see link posted by philwareham upthread.

It’s very easy to extend it to the month/day fields, but three datepickers feel a bit redundant.

I don’t think you need 3 datepickers. From my POV that is.

PS – thanks for that plugin – if anything, it allowed me to improve my stylesheet a little :-).

Last edited by phiw13 (2017-09-13 23:35:44)

Offline

#16 2017-09-13 23:34:24

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,122
Website

Re: Expiration datepicker

philwareham wrote #306983:

Small notes: Your example only works if the year field is activated, not the month or day fields. Also seems to not be showing the selected day styling on the date picker either – not sure if it’s my code or something in the above plugin (the selected day should be highlighted in blue on the picker).

When the field is already filled (publish date), and the date is not “today” (e.g. editing an older article), the date of the article is highlighted with a very faint white / lighter grey (Hive). The class applied is a.ui-state-hover, the parent <td /> has a class of .ui-datepicker-days-cell-over.

The thing here, if I move the mouse over the calendar, that highlight immediately disappears. The class a.ui-state-hover is removed from the selected date. The class on the <td /> is kept in place.

It took me a few tries to see it (and more to “see” it in the inspector). With Hive that highlight is very hard to see, with my own Sandspace, it is a bit better – a light grey on smoke-white, although I prolly should improve that highlight a bit.

When the field is blank (Expire date), OR, the publish date for a new article, the date (“today”) is highlighted with the class a.ui-state-active, with Hive: a light blue.

(I would expect both cases to have a class a.ui-state-active, or eventually .ui-selected, but that is a bug / limitation of the JQ-UI code)

Offline

#17 2017-09-14 09:00:22

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 2,755
Website

Re: Expiration datepicker

The date picker in Hive should have blue for a selected date, try it here and select any date and you’ll see what should happen. Not sure why that would differ in Oleg’s implementation since it’s the same jQuery UI code and my styling is based on the vanilla widget behaviour.

Offline

#18 2017-09-14 09:27:41

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,122
Website

Re: Expiration datepicker

philwareham wrote #306988:

The date picker in Hive should have blue for a selected date, try it here and select any date and you’ll see what should happen. Not sure why that would differ in Oleg’s implementation since it’s the same jQuery UI code and my styling is based on the vanilla widget behaviour.

3 screenshots for you
(the file names speak for themselves, I hope)

TXP 4.7-dev up-to-date running on localhost.

edit – What you need:

.ui-datepicker-days-cell-over .ui-state-default,
.ui-datepicker td a.ui-state-active { }

Last edited by phiw13 (2017-09-14 09:29:55)

Offline

#19 2017-09-14 10:09:53

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 2,755
Website

Re: Expiration datepicker

phiw13 wrote #306989:

.ui-datepicker-days-cell-over .ui-state-default,...

Actually no, sorry. There is something amiss with the widget implementation that has been used in this plugin. The td cells in question should have classes as follows (from jQuery UI’s own code)…

.ui-datepicker-today
.ui-datepicker-current-day

…which don’t appear in Oleg’s date picker at all but do appear (correctly) in my demo date picker. Not sure why that would be. I’m not going to hack in some extraneous CSS selectors when my original code is fine.

Offline

#20 2017-09-15 01:57:07

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,122
Website

Re: Expiration datepicker

philwareham wrote #306990:

.ui-datepicker-today...

…which don’t appear in Oleg’s date picker at all but do appear (correctly) in my demo date picker. Not sure why that would be. I’m not going to hack in some extraneous CSS selectors when my original code is fine.

The plugin sets the correct class (.ui-datepicker-today) for “today”, but fails to set the class (.ui-datepicker-current-day) for the currently selected date (in a pre-filled field with a date that is not “today”, e.g the Publish date for an older article). It correctly scrolls to that date, though, but then sets a wrong class(.ui-datepicker-days-cell-over).

(all those classes are applied to <td />s.)

Offline

Board footer

Powered by FluxBB