Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-28959

Prevent publishing errors on pre-existing, undefined custom tags

    XMLWordPrintable

Details

    • [2.2] Sprint 1

    Description

      It was possible to render custom tags, with attributes, before custom tags support was added to the OE. The OE integration adds validation of parameters, and fails on undefined tags or attributes. In the current state, publishing will be blocked by the custom tags validator if such content is edited. This is a BC break.

      In addition, we need to check how the OE reacts to such a case. We should also check how v1.0 reacted to that case: how were the tags displayed, and what could you do with them ?

      Validation

      Solution 1: allow to disable validation for this major version

      It can be prevented by making custom tags validation opt-in. We can add an option to richtext that toggles the feature on/off, and make it disabled by default. Having it disabled should trigger a deprecation warning, and explain that having it disabled will be removed in the next major version.

      ezpublish:
        ezrichtext:
          features:
            enable_validation: false
      

      Technically speaking, the parameter should be processed in a Container Extension, and disable validation at the lowest level, either by removing the injected service or replacing it with a null service.

      Solution 2: decorate the validator to ignore those errors and notify

      An alternative is to handle this by decorating the validator and catching validation errors, and change them to warnings.

      Solution 3: mix of the above

      We could add an option, enabled by default, that ignores validation errors. If enabled, it decorates the validator (at container level), and changes the error to a deprecation notice, reminding that this behaviour will be removed in the next major version.

      Online Editor

      The minimum is that the OE doesn't crash when encountering an undefined tag, as it did not crash before we added the feature.

      We may want to add a message on the tag's rendered view (in the OE) when this happens, and inform that the tag needs to be defined to be editable. Another option would be to guess the type of each attribute, but I think we would be overdoing it, as they were not editable before.

      Attachments

        Activity

          People

            Unassigned Unassigned
            bertrand.dunogier@ibexa.co Bertrand Dunogier
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: