Joomla-cms: [3.7] calendar field, bug when clearing value manually ?

[fuscage]

Hello,

With joomla 3.7, the value of the calendar field can't be clear manually...

It's normal I have to push on the "clear" button (of the calendar) to delete the value? (It's not userfriendly)

Steps to reproduce the issue

1) create new article with a date on the calendar field ("end of publication" and "creation date")
2) save
3) delete manualy the dates (select the value and clic on the [del] key on the keyboard)
4) save

Expected result

empty values on the calendar fields

Actual result

old values on the calendar fields

System information (as much as possible)

joomla 3.7

Additional comments

I have seen when I clear manually the date, the "cleared value" reappear when I click on the "save" button... and finaly the value is not cleared...

[dgrammatiko]

Which field are you testing this on?
There are some fields that cannot be empty ( php side, e.g. Start publishing)

[fevangelou]

Duplicate of this? https://github.com/joomla/joomla-cms/issues/15569

[fuscage]

The fields are "end of publication" and "creation date"

When I click on the "clear" button that's work (it's to check that the fields can be empty) but when I delete manually the value that doesn't work :-(

It's not a duplicate of the #15569

Thanks

[ghost]

@fuscage maybe this helps: after del at Keyboard hit Tab at Keyboard, than click on Save.

[fuscage]

@franz-wohlkoenig thanks for the tips, but It's not a normal behavior....
With the others fields (text, textarea, etc.) you have not to click on "tab" (after "del") to delete the value...
I hope that will be corrected...

[ghost]

@fuscage you're right, its not expected behaviour, was a Tip until Issue is solved (me too like Work with Keyboard more than Mouse).

[Bakual]

@dgt41 Can we trigger the field update also when saving without "leaving" the field? Or maybe even using "onchange"?

[dgrammatiko]

@Bakual the update is triggered on blur, what is weird is that in order to click the save button the focus should shift from the calendar to the button, which obviously is not the case for BS 2.3. Is there a role="button" to the toolbar buttons?

[ghost]

@dgt41 is #15661 similar?

[dgrammatiko]

@franz-wohlkoenig no, in that one is the language that has the error

[Bakual]

Is there a role="button" to the toolbar buttons?

No, it's just a <button>.

[dgrammatiko]

@Bakual so it's the event.preventDefault(); on the validation script that bypasses the button focus on click... Let me see what I can come up with here

[Bakual]

To much JS magic for me 😆

[Ruud68]

Hi, I think this is related:
in com_content > article > manually change one of the dates manually e.g. publish down (change the month by typing the new month number over the old month number). Press [save] > the change is not saved and the old month is still visible.

This happens both on the front-end and the back-end.

Only way to change the date filed is via the calendar.

This is not good :(

The calendar doesn't work properly on mobile: in portrait mode it covers the whole screen, in landscape mode the calendar doesn't show > the only way to change the dates is via the keyboard... which doesn't work...

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15568.}

[Ruud68]

now with screenshots :)

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15568.}

[infograf768]

@Ruud68
Could this be related to your template?
This is what I get with Protostar:

[Ruud68]

Thnx @infograf768 , the layout of the calendar was indeed a template css issue. Was able to fix that for one site... many more to go :S

Still remaining the issue that you cannot change the date/time via text in both front-end and back-end. Only way to change is via the actual calendar, not via the text field.

[Bakual]

@Ruud68 You can manually change it. The issue is that you need to shift the focus away to another input element using tab or the mouse. Then it updates fine.
The issue is that when you change the date and then directly press the save button, the focus isn't changed due to some JS voodoo involved with the save button.

[Ruud68]

Thnx @Bakual , this will work for me, not sure for other users :)
I hope @dgt41 can come up with something, to much js magic for me as well :)

[ethernidee]

I approve, that manual changing of publish_up, publish_down fields has no effect on saving. Only changing via calendar widget and pressing "Save" has effect. Clients report it as "cannot change publish date" bug.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15568.}

[dgrammatiko]

OK, I was looking at this one and the functionality is the same as in tags. When you are doing manual editing you need to press enter to input the data. So it's not exactly wrong or weird behaviour, you have a widget open so you either press enter to accept the changed value or esc to cancel. Now on esc what should actually happen is refill the old value (it happens in the code but is not reflected in the view).

But because all this is based on javascript we can opt for whatever workflow we want, so please let's have some common understanding on how do we expect this to work, then I can come up with some code...

[Bakual]

Imho, whatever is written in the field, should be saved.
Pressing escape to clear/reset the values I entered manually would be quite unexpected to me. I would only expect it to close the popup.
But most importantely, if I go from the input directly to the save button, I expect it to save my values (and not reset or clear them). Be that tags or a date. If it doesn't save, then it needs fixing as this feels very annoying otherwise.

[dgrammatiko]

But most importantely, if I go from the input directly to the save button, I expect it to save my values

Try the same procedure in tags...

The point is that the calendar is doing some validation and that is not called if either enter or save is pressed

[Bakual]

Try the same procedure in tags...

I wouldn't use anything related to tags as a good example :smile:

The point is that the calendar is doing some validation and that is not called if either enter or save is pressed

Then it should call that. Or do you think it's good UX or expected behavior that the value isn't saved in this cases? I certainly don't think this way.

[dgrammatiko]

I wouldn't use anything related to tags as a good example

It's not the tags code in fact it's chosen.js...
Anyways let me see what the script is doing because I hardly remember what's there

[Ruud68]

I would expect that the widget would only show up when pressing the 'calendar button' (next to the field), not by clicking in the field itself. This is from how it was implemented before. For me personally, the current implementation has no added use case over how it was (other then that the calendar widget looks better and is better suited for mobile).
I have no problem with change, but I do have problems with users not understanding how to use it :)
UX is like a 'bad' joke: if you have to explain it, it is not good :)

[dgrammatiko]

@Bakual can you test this code:

    /** Method to listen for the click event on the input button. **/
    JoomlaCalendar.prototype._bindEvents = function () {
        var self = this;
        this.inputField.addEventListener('focus', function() {
            self.show();
        }, true);
        this.inputField.addEventListener('blur', function(event) {
            if (event.relatedTarget != null && (event.relatedTarget.classList.contains('time-hours') || event.relatedTarget.classList.contains('time-minutes') || event.relatedTarget.classList.contains('time-ampm'))) {
                return;
            }
            var elem = event.target;
            while (elem.parentNode) {
                elem = elem.parentNode;
                if (elem.classList.contains('field-calendar')) {
                    if (event.target.value) {
                        elem._joomlaCalendar.checkInputs();
                    } else {
                        event.target.setAttribute('data-alt-value', '0000-00-00 00:00:00');
                        elem._joomlaCalendar.checkInputs();
                    }
                    return;
                }
            }
            self.close();
        }, true);
        this.button.addEventListener('click', function() {
            self.show();
        }, false);
    };

Somewhere around line 994, just replace the whole bind function and let me know if that is what you want (it works for clearing the input and directly pressing save)

[dgrammatiko]

@Ruud68 you're right but these question and many more should have been answered like 6 months ago not after shipping the code...

[Bakual]

@dgt41 This seems to fix the clearing indeed, but not when editing anything manually.

but these question and many more should have been answered like 6 months ago not after shipping the code...

You know how it works in Joomla land. Most tests are done in productive enviroment. While it's true that the calendar PR was around for a long time, same is true for a lot of the other PRs and having 469 open PRs doesn't help finding the one which may impact a user. So please don't blame users for not testing a PR before it was merged. Just acknowledge the valid issue.

[dgrammatiko]

@Bakual something to do with the checkInputs(). Probably removing data-alt-value in the if part will fix that as well: event.target.removeAttribute('data-alt-value');

[Bakual]

Can you do a PR? Because when I mess with JS I always fear I missed something.

[dgrammatiko]

so the code is:

    /** Method to listen for the click event on the input button. **/
    JoomlaCalendar.prototype._bindEvents = function () {
        var self = this;
        this.inputField.addEventListener('focus', function() {
            self.show();
        }, true);
        this.inputField.addEventListener('blur', function(event) {

            var elem = event.target;
            while (elem.parentNode) {
                elem = elem.parentNode;
                if (elem.classList.contains('field-calendar')) {
                    console.log(event.target)
                    console.log(event.target.value)

                    if (event.target.value) {
                        event.target.setAttribute('data-alt-value', event.target.value);
                        elem._joomlaCalendar.checkInputs();
                    } else {
                        event.target.setAttribute('data-alt-value', '0000-00-00 00:00:00');
                        elem._joomlaCalendar.checkInputs();
                    }
                    return;
                }
            }
            self.close();
        }, true);
        this.button.addEventListener('click', function() {
            self.show();
        }, false);
    };

All cases covered

[Ruud68]

@Ruud68 you're right but these question and many more should have been answered like 6 months ago not after shipping the code...

Agree and I did try to keep up with all the changes, this one slipped my attention :S Best test is the actual user using it on production :)
Just as a note: I have contacted several extension developers to notify them of pending issues with their extension and the beta and rc releases: all of them responded 'wait until the final, then we will fix'. That is not good, but I do understand where they come from...
I appreciate all the hard work you put in the Joomla project!

[dgrammatiko]

Please test https://github.com/joomla/joomla-cms/issues/15908

[joomla-cms-bot]

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/15568

[ghost]

closed as having PR #15908

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15568.}

[Ruud68]

Tested both back-end and front-end: works as expected! Top and Thank you!

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15568.}

[zero-24]

@Ruud68 can you please post that here: #15908 so we can move that RTC and merge it for a update?