18 replies to this topic

[onjegolders]

Not sure whether this is a known bug or something else is causing the problem.

Basically my custom date field is being wiped when I resave the page.

So on first adding the date and saving all is well, or if the date is added last thing before clicking save then no problems but otherwise the datefield just empties.

I am also using the datepicker (not sure if this has any bearing on it)

[formmailer]

Check out this topic: http://processwire.c...th-date-format/

As for the date picker populating the format Y-m-d, it does that because javascript (jQuery) and PHP don't use the same date format strings, so we have to use an ISO-standard date format for something that is automatically populated from a date picker.

You are probably using the d-m-Y format in your date field.

/Jasper

[onjegolders]

Thanks Jasper for your help. I've switched it to dashes and it all works now. Unfortunately the datepicker reverts it to YYYY-MM-DD but I understand there's no real way around that and it's not too big a deal!

[ryan]

There actually is a way around that, but it was a lot more complex than you'd think. Had to setup a translation table between PHP date(), PHP strftime(), Javascript/jQuery and regular expressions. But the result is that your date format will be retained without limitation. Grab the file from here, and you should have a lot more options for the datetime fields too:
http://processwire.c...tfielddatetime/

I'll be committing this to the core soon.

[onjegolders]

Thanks Ryan, I have actually already installed this version, will have to double check whether it works as am pretty sure it still defaults to YYYY

[apeisa]

Browser cache maybe?

[ryan]

It's got to be browser cache like Antti said. Hit reload a couple of times in your browser while on a page with the datepicker.

Also, you'll be glad to know I've got an update just about ready that should prevent this particular browser cache issue that comes up regularly. Basically, the admin template will append the module version numbers to the CSS and JS files, i.e. "module.js?v=102", hopefully communicating to the browser that something has changed.

[apeisa]

That means we module developers need to update version numbers...

[ryan]

I've not been good at updating module version numbers. But this seems like it'll be a good reason for me to start doing it.

[onjegolders]

Thanks for the replies, think I may have just misunderstood, when I select with the datepicker it displays YYYY but when saved it reverts to desired input.

[ryan]

Thanks for the replies, think I may have just misunderstood, when I select with the datepicker it displays YYYY but when saved it reverts to desired input.

With the new datepicker, the only time you should see the YYYY-MM-DD input is if that what you have selected as your input format. If you have selected some other input format, then the datepicker should use only the format you selected. This is one of the main differences between the new datepicker and the old one. The behavior you are describing sounds to me like you may still have the old datepicker. The new one has been stable for me all week, so I will go ahead and commit the new one to the source this weekend or early next week.

[yellowled]

Ryan, just to make sure: did you commit this to the core so that your datetime patch is no longer require in current PW versions?

[apeisa]

Ryan, just to make sure: did you commit this to the core so that your datetime patch is no longer require in current PW versions?

Yep, the new datefield is on the core already.

[yellowled]

Hmmm.

In the "live version" on the server, I can't select "unix timestamp" as an output format in datetime fields. On my local dev server (with patch applied) I can. Live version is today's github snapshot. Is this related to that or am I missing something here?

[apeisa]

Not sure if Ryan dropped that option. You should get timestamp by setting $page->of(false) before outputting the date field. Then turn it back to true right after.

[yellowled]

Seems like he dropped it. I was worried it could be the server since I have to work on a server by a German webhoster which is known to be quirky, but I don't get the unix timestamp option on my local server with the new version, either.

[Soma]

yellowled is right, Ryan commented it out in implemented version.
https://github.com/r...time.module#L76

"Timestamp" was in the patch Ryan provided as download.

[ryan]

It was dropped before going into the core just because timestamp is already the native storage state of all date fields. When output formatting is off, date fields are always timestamps. When output formatting is on, you can get the timestamp of any date field like this: $page->getUnformatted ('field_name'); So I figured that having an output formatter that returns an unformatted state probably wasn't worthwhile.

[yellowled]

Hey, it got me (who never got his mind around PHP in various attempts), into learning about strftime, strtotime, date and all that stuff this morning. So thanks PW for teaching me yet another lesson in PHP. Watch your backs, I might take the whole thing over some time.