Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation is no longer enforced for inline editable properties #2828

Closed
bwaidelich opened this issue Nov 12, 2020 · 11 comments · Fixed by #2847
Closed

Validation is no longer enforced for inline editable properties #2828

bwaidelich opened this issue Nov 12, 2020 · 11 comments · Fixed by #2847
Assignees
Labels
Bug Label to mark the change as bugfix Editor Ui Regression

Comments

@bwaidelich
Copy link
Member

bwaidelich commented Nov 12, 2020

Description

Since #2538 validation could be activated for inline editable properties.
Due to some regression this no longer works with Neos 5.0+

Steps to Reproduce

Adjust the headline node type definition in the demo site:

'Neos.Demo:Content.Headline':
  properties:
    'title':
      # ...
      validation:
        'Neos.Neos/Validation/StringLengthValidator':
          minimum: 1
          maximum: 5

Open up the homepage (or any other page that contains a headline node) and enter a headline that exceeds 5 characters

Expected behavior

The inline editable should get a red border & display the validation error (see #2538).
It should be impossible to persist / publish the invalid state.

Actual behavior

The validation is completely ignored.

Affected Versions

Neos: 5.0+
UI: 5.1+ (probably also 5.0)

@bwaidelich bwaidelich added Bug Label to mark the change as bugfix Critical Editor Ui Regression labels Nov 12, 2020
@markusguenther markusguenther self-assigned this Nov 12, 2020
@markusguenther
Copy link
Member

markusguenther commented Nov 16, 2020

The neos.ui has a automated test for that and has the nodetype headline.

'Neos.TestNodeTypes:Content.Headline':
  superTypes:
    'Neos.Neos:Content': true
  ui:
    label: Headline_Test
    icon: icon-header
    position: 200
    inlineEditable: true
    help:
      message: 'Markdown **test**.'
  properties:
    title:
      type: string
      defaultValue: '<h1>Enter headline here</h1>'
      ui:
        inlineEditable: true
        inline:
          editorOptions:
            placeholder: '<h2>Enter headline here...</h2>'
            formatting:
              h1: true
              h2: true
              h3: true
              h4: true
              h5: true
              a: true
      validation:
        'Neos.Neos/Validation/NotEmptyValidator': []
        'Neos.Neos/Validation/StringLengthValidator':
          minimum: 1
          maximum: 255

This leads to the following result. So this test never fail because of the additional notEmpty validator.

Screenshot 2020-11-16 at 21 18 05

markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 16, 2020
The StringLength validator will fail when the minimum value is pretty small.
The reason is that the value contains the HTML tags as well. So we now strip the tags from the to be validated value.

Fixes: neos#2828
@markusguenther
Copy link
Member

The issue was bit tricky and the error can have multiple reasons.

  1. The validators are stored for each node so when the Validators has been changed the existing nodes still use the old config.
  2. When you have a validator with just stringLength and expect a minimum of 1 it does not work and you need additionally the NotEmpty validator.
  3. The StringLength validator with a pretty short maximum will often fail because the inline elements have values with markup. So the HTML tags blow that up.

The PR now strips the tags off and that resolves the maximum validation, but for the minimum of 1 we need a NotEmpty validator as well.

@dimaip
Copy link
Contributor

dimaip commented Nov 17, 2020

Thanks so much for digging into this Markus!

markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 17, 2020
The StringLength validator will fail when the minimum value is pretty small.
The reason is that the value contains the HTML tags as well. So we now strip the tags from the to be validated value.

Fixes: neos#2828
@bwaidelich
Copy link
Member Author

bwaidelich commented Nov 17, 2020

Yes, thanks a ton, Marks. But I'm afraid this ain't solve it yet

The validators are stored for each node so when the Validators has been changed the existing nodes still use the old config.

What does that mean? The validation rules are persisted with the node? So I can't change the validators afterwards?

When you have a validator with just stringLength and expect a minimum of 1 it does not work and you need additionally the NotEmpty validator.

I know, that's expected and it works like this in Flow & the Form Framework, too

The StringLength validator with a pretty short maximum will often fail because the inline elements have values with markup. So the HTML tags blow that up.

Right. I had addressed that with neos/flow-development-collection#1849 (see #2579) but that is not related to this bug really (I think at least)

@bwaidelich
Copy link
Member Author

...another heisenbug. I can't reproduce it any longer. At least not with the Neos.Demo site o.O

@markusguenther
Copy link
Member

:)

I could reproduce the HTML thing. But I maybe had a caching issue with the point 1. Checked the nodedata and the local-storage and redux store and did not find the old config.
Added a small video with the neos demo. Yesterday I worked with the testing distribution to be able to run the e2e test locally.

@markusguenther
Copy link
Member

Arg 🤦‍♂️ while checking that the validators are implemented in the ui itself and not using the PHP validator code I saw that the StringLength validator has an option ignoreHtml.

So we don't need the strip html stuff ... you just need to add this config.
Sorrry did not see that before.

@bwaidelich
Copy link
Member Author

I'm really sorry for all the fuss.. It turns out, this was just a bug in a customer project of mine that messed with z-index so that the inlineValidationTooltips were not visible.

I already expected that and reproduced the bug with a clean Neos.Demo installation but apparently I ran into the caching issue @markusguenther mentioned above, so that my new validation rules were not active immediately..

Closing this one.. Thanks for your help, Markus, I owe you some beers <3

@suffle
Copy link
Contributor

suffle commented Nov 18, 2020

There is a subtle change in Neos 5 which changes the behaviour of validation messages though: The <div id="neos-new-backend-container"></div> is rendered as the first element of the body in Neos ~5.0 while it was rendered as the last element in Neos ~4.0 which changes the layering of the elements and makes the described behaviour reproducible in the Neos.Demo Package. When you add a Validator to Neos.Demo:Content.Headline and edit the Headline on the KeyVisual you have the exact same problem and I guess there are more projects with the same issue:

Neos 4:
validation_neos-demo-4

Neos 5:
validation_neos-demo-5

@bwaidelich bwaidelich reopened this Nov 18, 2020
@bwaidelich
Copy link
Member Author

bwaidelich commented Nov 18, 2020

Turns out this was a regression after all:
This line is the culprit:

newNeosBackendWrappingElement.@position = 'after neosBackendContainer'

doesn't work since there is no neosBackendContainer in the original Neos.Neos:Page fusion prototype since neos/neos-development-collection#2672

Maybe we should take the chance and get rid of the "new" and "old" separation at this point. But that's probably something for master while the minimal invasive bugfix would be to change after neosBackendContainer to before closingBodyTag probably. What do you think @markusguenther @dimaip ?

markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 19, 2020
The neosBackendContainer has been removed with the old emberjs content module. Because this container could not be found the container has been added to the beginning of the body tag.

Now we adjust the position to the end of the body section.

Fixes: neos#2828
markusguenther added a commit that referenced this issue Nov 19, 2020
The neosBackendContainer has been removed with the old emberjs content module. Because this container could not be found the container has been added to the beginning of the body tag.

Now we adjust the position to the end of the body section.

Fixes: #2828
@markusguenther
Copy link
Member

The position has been adjusted an will be released for the next ui version for 5.0 and newer.
As the renaming the container is a bit breaking if someone rely on that I will change that only on master for 6.0.

Thanks for the help guys ❤️

markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 19, 2020
Rename the container from neos-new-backend-container to neos-backend-container. The emberjs content module has been removed for 5.0 and now we rename the backend container as we have no old and new one anymore.

The can cause issues when the third party code rely on the neos-new-backend-container id.

Related: neos#2828
markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 19, 2020
Rename the container from neos-new-backend-container to neos-backend-container. The emberjs content module has been removed for 5.0 and now we rename the backend container as we have no old and new one anymore.

The can cause issues when the third party code rely on the neos-new-backend-container id.

Related: neos#2828
markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 19, 2020
Rename the container from neos-new-backend-container to neos-backend-container. The emberjs content module has been removed for 5.0 and now we rename the backend container as we have no old and new one anymore.

The can cause issues when the third party code rely on the neos-new-backend-container id.

Related: neos#2828
markusguenther added a commit to markusguenther/neos-ui that referenced this issue Nov 19, 2020
Rename the container from neos-new-backend-container to neos-backend-container. The emberjs content module has been removed for 5.0 and now we rename the backend container as we have no old and new one anymore.

The can cause issues when the third party code rely on the neos-new-backend-container id.

Related: neos#2828
markusguenther added a commit that referenced this issue Nov 23, 2020
* TASK: Rename neos backend container

Rename the container from neos-new-backend-container to neos-backend-container. The emberjs content module has been removed for 5.0 and now we rename the backend container as we have no old and new one anymore.

The can cause issues when the third party code rely on the neos-new-backend-container id.

Related: #2828

* TASK: Remove conditions of the old emberjs content module
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Label to mark the change as bugfix Editor Ui Regression
Projects
None yet
4 participants