Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/29/2012 in all areas

  1. The current core date/time fieldtype/inputfield in ProcessWire has been a little weak, and there are some issues when it comes to using the datepicker. I've been working on fixing all of these and really upgrading the datetime fieldtype and inputfield to be much stronger. However, I need some help testing before a commit to the core source. I would just put it on a dev branch, but know that not many people will try it that way, so figured this would be better to post here. The file is attached. To install, you'd replace the existing files... /wire/modules/Fieldtype/FieldtypeDatetime.module /wire/modules/Inputfield/InputfieldDatetime/ (entire directory) ...with the new ones here: <attachment removed> Here's what's new: You can now select from predefined date and/or time formats, rather than having to manually construct a PHP date format (though you can still do that too if you want to). It converts your date format to the equivalent javascript format, so when you select a date from the datepicker, it stays in the right format rather than changing to a YYYY-MM-DD format like that old one did. No more conversion issues with day-first vs. month-first dates and the datepicker. There is now a time picker too! If you opt to include a time component, the datepicker will include a timepicker. You can now choose when you want your datepicker to appear: on click (as before), on focus (new), or inline (new, always visible). You can now optionally specify alternate date/time output and input formats on a per-language basis. So if you need month-first dates for US users, and day-first dates for European users, no problem. For the date output format, you can use PHP strftime() codes if you want to. This enables you to have one date format that outputs language-specific/localized month or day names. Though if you don't need to output localized month/day names, then it's better to stick with the default date formats. If anyone gets a chance to try it, please let me know how it works for you and if you run into any issues. There is a lot of new and somewhat complex code in here, so it needs a good testing. I've been testing here, but know with something like this there are some scenarios I could miss. Once we've confirmed all is stable, I'll commit this to the core. Thanks, Ryan Date/time picker example: Fieldtype configuration example: Inputfield configuration example:
    2 points
  2. This looks interesting for a FieldType http://filepicker.io/
    1 point
  3. Hi Ryan, I'm trying this out now and it looks nice -- thank you! I've created a date of birth field using this field-type and added it to a template, setting it up to show on button press. However, I've hit a few issues with it so far... The year shown in the picker seems to be limited to this year +/- 10 years -- which is way too limited for a d.o.b field. I can't see any way to change that range, nor can I change it from the pop-up picker. I can change it by editing the date manually but that kind of negates the use of the picker. Attempting to save dates on, or prior to, the Unix epoch (01/01/70) fail silently when using the 04/08/12 input format and lead to a blank value in the field. As this doesn't happen in some of the other formats it doesn't seem to be a limit of the storage. If this is a consequence of a limit on the two-digit year input then this probably needs to raise a warning in the UI. The list of choices for the input and output date format currently use April 8th (in whatever format.) I'd suggest using an example date with a day number > 12 so that it is immediately obvious in the list which part of the date is the day. Using April 8th (04/08) is still ambiguous in some of those formats. Using something like April 24th would remove the ambiguity (04/24 or 24/04). More to come as I find it. Once again, thank you for working on this. Edited to add: Just a thought, but having this as a dev/experimental/nv branch would actually be useful (for me, at least, and maybe for other git users here too.)
    1 point
  4. The form builder probably won't be part of it, but the history module will (and already a good start with that). For the form builder, I've either got to wait till I get a bunch of time off work to do it, a client wants it and is willing to subsidize it, or we get a sponsor for it. So it's something I definitely see us getting eventually, but probably shouldn't nail it down to a version. I'm also really interested to see where Netcarver's form builder is going and see if there's collaboration potential there. I've wanted to wait to officially announce 2.2 till language and repeater functions were bulletproof. But I've been fixing minor issues in both as recently as this week, so feel like I need to have at least a week of no issues coming up before we'd consider 2.2 ready for announcement. I still also need to resolve the repeater / page clone issue. 2.3 will likely follow 2.2's announcement by 2 months, so likely sometime this summer.
    1 point
×
×
  • Create New...