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

eZ Flow block items in v1 of content aren't synced correctly

    Details

      Description

      When syncing version 1 of content with an ezpage attribute, no valid nodes will be returned on the target server.

      In the database, the following fields are incorrect:

      • ezm_block.node_id is set to 0, while it should be set to the synced node id
      • ezm_pool.ts_valid is set to 0 as well, while a ts_valid > 0 condition is used in the query that fetches valid nodes.

      The node_id problem occurs because when processing the attributes in models/field.php, the object hasn't been published, and doesn't have a node id: https://github.com/ezsystems/ezcontentstaging/blob/custom-4.7.1/classes/models/field.php#L722.

        Issue Links

          Activity

          Hide
          Eduardo Fernandes (Inactive) added a comment -

          QA Tested and Approved

          Show
          Eduardo Fernandes (Inactive) added a comment - QA Tested and Approved
          Hide
          Bertrand Dunogier added a comment -

          Merged to ezflow/master @ 7d863be.

          Show
          Bertrand Dunogier added a comment - Merged to ezflow/master @ 7d863be .
          Hide
          Bertrand Dunogier added a comment -
          Show
          Bertrand Dunogier added a comment - Pull-request https://github.com/ezsystems/ezflow/pull/63 .
          Hide
          Bertrand Dunogier added a comment -

          This mostly comes from the differences between normal eZPageType and the way staging handles it:

          • eZPageType stores an XML with zone/block/item "action" attributes (add, remove, modify). Those are processes in onPublish to create/modify/remove elements from ezm_block and ezm_pool. It then stores a modified XML to data_text that only contains zone + block, and no item info.
          • Staging builds a custom payload with the list of zones, blocks and itemsn and processes it back when creating content.

          I see two ways to fix this:

          • post process ezpage attributes, and fix invalid ezm_block.node_id fields (ts_valid is probably something else)
          • stop using this custom payload, and re-create an XML that behaves likes the one used by staging. It is identical, except for the list of items and the action attributes. The only thing is that we can probably not re-create the remove/modify actions, but it shouldn't be a problem if we keep erasing the blocks & items on the target server first, like it is currently done.
          Show
          Bertrand Dunogier added a comment - This mostly comes from the differences between normal eZPageType and the way staging handles it: eZPageType stores an XML with zone/block/item "action" attributes (add, remove, modify). Those are processes in onPublish to create/modify/remove elements from ezm_block and ezm_pool . It then stores a modified XML to data_text that only contains zone + block, and no item info. Staging builds a custom payload with the list of zones, blocks and itemsn and processes it back when creating content. I see two ways to fix this: post process ezpage attributes, and fix invalid ezm_block.node_id fields (ts_valid is probably something else) stop using this custom payload, and re-create an XML that behaves likes the one used by staging. It is identical, except for the list of items and the action attributes. The only thing is that we can probably not re-create the remove/modify actions, but it shouldn't be a problem if we keep erasing the blocks & items on the target server first, like it is currently done.

            People

            • Assignee:
              Unassigned
              Reporter:
              Bertrand Dunogier
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: