Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I don't think we have designs for this yet.
However, it's totally possible to trigger a validation error while inline editing (for example, set the username to "booger" or something that doesn't exist). What happens to the user is nothing at all. It doesn't let you save, but it doesn't tell you why. If you reload the page, you get the validation error.
We should come up with something a bit nicer than this. :)
Comments
Comment #1
Wim LeersYes, I've already talked to Kevin about this at some point, but we had more pressing matters to fix first. This is definitely a major IA/UX thing we still have to deal with.
Comment #2
Wim LeersWe should seriously consider leveraging the http://drupal.org/project/clientside_validation module for this.
Please see #1564920-37: Explore existing UX-enhancing solutions in Drupal to #1564920-40: Explore existing UX-enhancing solutions in Drupal for details.
Comment #3
webchickSlotting in for this sprint, and moving to the Spark issue queue as a result.
Comment #4
tkoleary CreditAttribution: tkoleary commentedThis is a really good point. I will install clientside_validation on my local and explore design options.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commented@tkoleary - I'm available to help as needed on this. I really want this for D8.
Comment #6
Wim Leers@moshe: you really want client-side validation?
Comment #7
attiks CreditAttribution: attiks commented@moshe I'm available as well, and I don't even mind that we have a 'proper' validation in core ;-)
Comment #8
webchickAdded to this sprint, and moving to new "Design" component.
Comment #9
Wim LeersComment #10
Wim LeersComment #11
Wim Leersd.o fail.
Comment #12
webchickWim, Kevin, and I had a call to discuss this today, here was the summary:
- Continue to save per-field, as you tab out of it (rather than explicit "save" button)
- Saving invokes a "throbber" visualization to indicate saving
- If a validation error is hit, form will be returned w/ red outline and error message(s) below
- The "tab out" save creates a new unpublished revision, and these form into a "stack" that you can see in a drop-down in the toolbar, and move back/forth to undo/redo edits.
- Clicking Save / Publish in the toolbar will "smoosh" this stack down to a single revision.
- If there are multiple fields part of a single field, only the one with the problem should be highlighted. The error message(s) will appear under the "field collection," though.
Designs for this coming soon!
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedI have some concerns about that approach. First, I'm not so sure about squashing revisions. Once the webserver saves a revision, it could be considered public and thus rebasing is not a good idea (borrowing git language here). We don't offer clones of our repo, so maybe it is OK. if we don't allow squashing, then the concerns are:
one is approving is not 100% clear.
One alternative is to use standard Ajax forms to build up a series of edits. Then the form gets Submitted when user clicks Publish. At that time, we perform validation (for the first time) and show errors as best we can. I think we could associate errors back to the parts of the entity that are invalid. i guess this has been explored?
The other wrinkle is that we will soon have TempStore API but thats not needed for the technique I propose above.
Comment #14
webchickHere's the TempStore issue for D8 btw: #1642062: Add TempStore for persistent, limited-term storage of non-cache data Right now this seems to be blocked on a discussion about whether it conflicts with #1175054: Add a storage (API) for persistent non-configuration state Until/Unless this gets worked out between the VDC/CMI teams, I'm not sure I'd feel comfortable recommending us to pull that in as a dependency and layer on top of it. I'd prefer us to instead just node_save() to a single Draft revision as we've talked about doing in the past, and forgo the undo + multiple "revisions" functionality to a later patch.
Comment #15
Wim Leers#13: The revisions would be marked as being "in-place editing revisions" (terminology TBD). They'd be squashed to form a coherent changeset, which would then also make sense in the context of workflows.
Sounds okay or not?
A series of edits by building up state in an AJAX form doesn't work because AFAICT that prevents us from re-rendering the field as it will eventually look.
Comment #16
moshe weitzman CreditAttribution: moshe weitzman commentedLets see what others think of squashing. I'm on the fence. I guess Rules module would ignore such revisions when it does stuff like send email notifications. Also, we need to avoid cache clears for transient revisions.
Yeah, re-render based on not yet submitted values sounds messy. In order to get AJAX proposal to work, we'd need to accept a limitation where your "TRUE WYSIWYG" fields always show latest value but taxonomy and similar fields just have a 'Changed' highlight or something like that. They would not actually show the new value(s). We could possibly work around this for core field types but that is getting messy.
Comment #17
attiks CreditAttribution: attiks commentedI have one (minor) other concern, what if 2 related fields need to be validated together, will that be possible?
This is minor, the only time we used such things is on intranet applications, not a really good fit for inline editing, but I'm just curious.
I think that if you do a node_save rules will kick in, and starts doing his things.
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedWhat if someone posted a revision in between all the ones you wish to squash? That would really complicate the squash, no?
Comment #19
Wim Leers@attiks: That would be near impossible to support, yes.
@moshe: we'd only squash specially tagged revisions by the same author, not simply "every revision since X".
Comment #20
attiks CreditAttribution: attiks commentedSo client side validation is out of the picture?
Comment #21
Bojhan CreditAttribution: Bojhan commentedDo we really think that users understand, that although in front of them in the actual site they see the text changed. They still have to click "Save" for others to see it? We have this same issue with reordering items in a table, all to often people forget to actually click "Save". I imagine since this is in the actual front-end it would be even more so. Although, this issue is not necessarily related to this thread, I never really understood how we think this actually ends up working for our users.
I think the interaction proposed where tabbing out of the field triggers validation, sounds good to me (almost sounds like client side validation, heh). Although I am sure, just using a red line around it is not enough signaling to pass accessibility team review. Having the changes all squashed in the end sounds fine.
Comment #22
Everett Zufelt CreditAttribution: Everett Zufelt commented- If a validation error is hit, form will be returned w/ red outline and error message(s) below
If this is being performed without user initiation, then we need a live region to read the errors.
We likely need an abstracted method of providing visual / live region updates. A couple of other issues that highlight this are #1272990: Make tabledrag warning message show when row weights are enabled, and add WAI-ARIA live region and #1333292: Screen-reader users receive information if file upload was successful.
Comment #23
moshe weitzman CreditAttribution: moshe weitzman commentedTempstore has been committed. Seems like we should use it. See #1642062: Add TempStore for persistent, limited-term storage of non-cache data
Comment #24
webchickDamn it, this time it's really gonna happen. ;)
Comment #25
webchickWe ended up fixing this quite awhile back. Basically it just shows the validation error above the field.
Comment #26
Wim LeersOr below the field, if it's using the "direct" in-place editor.