date element use-case that no longer works (back button to form)

[skyrun]

i have a form that has a date on it. the form has an php plugin that 'on after process' does something with the date (like create a csv file or pdf file or display pdf report for some examples). you can simulate by putting a php plugin on the form that just has in the php code box

echo 'hello world'; exit;

used to be that you could look at whatever the results were (pdf report in my use-case) and then press 'back' on the browser and the form was there intact with the 'sticky' values and you could change the date and run the report again with the new date.

with the new date element plugin, the values on the form except for the date are still sticky, however the date values change (no matter what format you choose) to be format yyyy-mm-dd hh:mm:ss. the yyyy-mm-dd is the correct date, but wrong format. meaning if the date in m/d/y format was 02/10/16, it will be 2016-02-10 00:00:00 after you press back. (i'm using chrome in case that matters)

now when you press the calendar button (which is expecting m/d/y as the element says) it looks at the mis-formatted date and sets some seemingly random date hundreds of years in the future or past.

 

[troester]

Did you try with a date format without / (e.g. m-d-y)?
It seems in some situations there are issues with / in the format.

 

[skyrun]

that didn't work either. i have also tried the 'advanced date formatting=y'. that causes other issues like dates switching from d/m to m/d every other time you click it. not sure if advanced date formatting should even be an option any longer.

 

[troester]

Yes, it's replicatable, not depending on the format (may be any format but SQL).
You don't need a php plugin, just display list, edit form, save, then click browser back in list view.
But I assume this is the "expected" behaviour - browser back is no Fabrik function.

It's ok if you are reloading the form.
What do you mean with "no longer works"? Where was is working?

 

[skyrun]

Worked in fabrik 2. I'm migrating my app and this is one of the differences. Thanks for the quick responses!

 

[cheesegrits]

It's the same issue we discussed with the "today +4 days" thing.

We now do the conversion of the date into MySQL format on the form prior to submitting. So the submit JS sets the date element field's value to the standard format. When you go "back" the form has that date in the underlying element value, it buggers up because it tries to display it as if it was supplied in the "form format" that the form was initially loaded with.

It might be fixable, but not something I can do on a subscription basis. If it's a "must have", find me on Skype and I'll quote you on doing it on an hourly basis. If I can do it - can't promise anything, but I may be able to add some JS that detects if a form is being loaded into a page after a "back" button click, and convert the date back to the form format. If it's possible (and I just googled around a bit, and I think it is), I could prolly do it in an hour.

-- hugh

 

[skyrun]

ok. seems more like a bug that should be fixed than a custom programming job. we all regularly use the back button. i'll think about it.

 

[cheesegrits]

We have never said we support using the "back" button to go back to a form. In fact, quite the opposite, our stance has always been that we cannot properly support use of the browser back button for either lists or forms. That it has ever worked for you is a happy coincidence, and I can think of a dozen examples off the top of my head of form and element setups where it wouldn't work. So this is a case where a happy coincidence is no longer working, not a bug.

Either way, it would require more time to "fix" than I can devote to a corner case issue which only one person is reporting as a problem. Fabrik is open source software. "No guarantee expressed or implied". It has bugs and "undocumented features". And we simply cannot afford to fix every single reported issue on an "all you can eat" subscription basis. I know, because we've been trying, and as we speak I'm eating Ramen Noodles with Cheeze Wiz for dinner. So I am attempting to set expectations at a more realistic level, and be more definitive about what I can and can't do and still put palatable and nutritious food on my table.

Apologies if I seem defensive, but it's not like I don't provide good value for money. You have us on Skype speed dial, and I respond pretty much 24*7 if I'm alive. That's a level of service many organizations would charge four figures a month for, for mission critical software support.

-- hugh

 

[skyrun]

i see. you have put me in my place.

thanks for your support over the years in any case.

 

[cheesegrits]

Apologies for my tone, but I'm having a real problem trying to manage people's expectations. In some ways it's my own fault, as I enjoy my work, and I enjoy helping people, so in the past I've tended to just say "OK" and fix whatever needs fixing, and that has led to an expectation that a support sub is literally "all you can eat", and we'll fix anything for $20 or $70 a month.

But that's just not working. As Fabrik has matured, most of the low hanging fruit, "feature" wise, has been plucked. The remaining issues tend to be corner case, not affecting many people, and much harder to fix. So where in the past we could maintain enough subscription support to pay the bills, and most issues affected most people and fixing them was a definite, quantifiable community benefit. These days I'm down to less than minimum wage, when I average out the hours spent fixing the increasingly difficult issues, which affect a disproportionately small number of people.

This is of course not a unique problem in open source software, and we simply need to come up with a fairer / more realistic model than subscription support to fund Fabrik.

-- hugh

 

[skyrun]

same date formatting error on the corner case of putting a date element on a multi-page form.

press next, then prev buttons on the fabrik form using the fabrik buttons and the dates are formatted like sql date/time when you get back.

i'll hire someone to modify the date element so that works for my use-cases. i'm happy to contribute it back here when i get it done.

 

[cheesegrits]

So you are happy to pay someone else to do it, but not us?

SMH.

-- hugh

 

[skyrun]

yes, that's right. catch me on skype hugh if you would like to discuss why real time. i'm gone until monday, but we can catch up then.

 

[skyrun]

i have a new date_enh plugin that i'm working on packaging up and will post here if anyone else wants to use it. it works with back-button, and also supports typing things like 'today' and 'yesterday +3 weeks'. i am also adding a better-looking uikit calendar option to choose vs. the std joomla one.

meanwhile if you want to fix the back button on the current date plugin, i THINK this will work.

modify date.js to include these 4 lines after setUp: funtion () (line 62)

of course the code that is used is acutally date-min.js, so changing date.js without minimizing won't work.

    setUp: function () {
// ADD CODE
        var date_str = this.getDateField().value;
        if (date_str.length > 8) {  // detect whether date is in mysql format
            var d = new Date(Date.parse(date_str.replace('-', '/', 'g')));  // convert to js date format.
            this.setTimeFromField(d);
        }
// END ADD CODE

        // Was also test on && !options.hidden but that stopped hidden elements from being saved correctly
        // @see http://fabrikar.com/forums/showthread.php?t=27992
        if (this.options.editable) {
....

then about line 120, add one line:

            this.makeCalendar();
// ADD CODE
            this.update(d);
// END ADD CODE
            // Chrome wierdness where we need to delay the hiding if the date picker is hidden

of course as with any 'fix', this one could cause other issues... but i don't see any so far. it's just reformatting the date upon initialization to undo the change made when the form exits to change to sql formatted dates.