Jump to content

Recommended Posts

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)

Share this post


Link to post
Share on other sites

Check out this topic: http://processwire.com/talk/topic/506-problem-with-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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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:

I'll be committing this to the core soon.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Browser cache maybe?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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. ;)

  • Like 4

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By ICF Church
      Hi 👋
      Anyone else having this problem?
      Requirements:
      - Repeater (matrix & normal) with mutlilanguage fields (text, textarea…) 
      - Backend language set to something other than default (ie. German) 
      Reproduce:
      - Add a new repeater Item (ajax, I found no way to possible to disable it with matrix)

      (Notice how the default language tab is active instead of the backend language…)
      - Write something into the (default language) field
      - Try to save, if field is required, this will not work. If not required, then when reloading, the content will be inside the backend language field, instead of the default language field who was (presumably) active
      Analysis:
      When  loading  a new repeater element with ajax, the default langue tab is active, but the backend language inputfield is visible (with no visual indication). When writing into the field, it will populate the backend language. When manually clicking on the default language tab (which is already active), the field will switch to the actual default language field (which is [now] empty) (that can now be populated…)
      Also Notice, the labels of the elements to be added are in default language as well instead of the translated label (images instead of Bilder)…
      ProcessWire 3.0.148, Profields 0.0.5…
      Is it my system configuration, or does anyone else have the same issue? This is a screen recording of the problem:
      Issue: https://github.com/processwire/processwire-issues/issues/1179

      Screen Recording 2020-02-25 at 14.18.31.mov
    • By humanafterall
      I'm using some Custom fields for images: 
      https://processwire.com/blog/posts/pw-3.0.142/#custom-fields-for-files-images

      When I save the page, and return the fields are blank. When I re-add the text to the fields and save again then the fields save as expected.

      I know this is stated as being quite experimental but it's super useful feature I'd love to get working correctly.
      I have fields that are CKEditor fields but have overidden this on the image specific template. I've also tried it with regular text fields and I get the same bug.
      (currently using Processwire 3.0.155)
      **UPDATE**
      I've found this issue is specific to editing on pages using the PageTable fieldtype. The fields are not saving when I save the page in the PageTable.
    • By Atlasfreeman
      So im doing a website. and i put on multi language on the website and uploaded some new images when i decide to make a new page...
      This i can't do anymore...

      It sais : 
      Add New
      The process returned no content.
      Unknown template.

      Well the website is showing fine, but i can't make new pages 😞

      Do any have any idea what to do?
    • By Guy Incognito
      I added some custom styles to the CKeditor menu bar using the example mystyles.js and the PW tutorial. This worked fine for fields when editing on the frontend. But none of our custom styles showed in the backend editor dropdown unless we edited the core copy of mystyles.js in wire/modules.
      Is this correct behaviour, a bug or a mistake on my part? Tried clearing cache, logging in/out etc but the backend ignores our custom styles in the site/modules path.
    • By karian
      I don't know why multiple instances (repeater_repeat_columns1, repeater_repeat_columns2, ...) of my repeater field are displayed inside Template field (see image).
      Is there a way to clean/reset it ?
       

×
×
  • Create New...