Contrib.social

[Meta] Selective Publishing and Reverting

Open on Drupal.org →
Created on 31 March 2025, about 1 month ago

Overview

Currently the user can only click "Publish all" to publish changes. There is no way for user to select a subset of changes to publish and there is no method to revert changes

Proposed resolution

Provide the ability for a user with the correct permissions to

  1. Select a subset of changes to publish. They will only be able select changes on the entity level, they will for example not be able to select individual field changes.
  2. Select a subset of changes to discard. Changes that are discarded will not be revertable

Out of scope for 1.0

  1. Complex multi-user editorial workflows (e.g., branching or merging separate edits). Users need to manage branching manually.
  2. Complex editorial review flows (e.g., needs review, approved): Users need to manage reviews manually.
  3. Being able to automatically publish only changes that are ready, i.e automatically select only changes that have no conflicts or validation errors. Users must manually select only changes that have no errors.

    If they choose a entity that has validation error it will be reported in the UI. The user can either fix the error or select not to publish the change

  4. Previewing Landing Page with only changes that will be published

    When Landing Pages contain edited Code Components these Code Components may or may not be published at the same time as the page. Published pages may appear with older versions of Code Components than in XB editor if those components are not selected to be published

Remaining questions

  1. Should the system enforce that client has the latest list of all the changes, regardless whether they select to publish all the changes?

    Currently client must send all keys for all the entities and a data hash that matches the latest auto-save state for each entity (see \Drupal\experience_builder\Controller\ApiAutoSaveController::validateExpectedAutoSaves).

    here are the options for what we could do:

    1. Keep current enforcement

      We may want to keep enforcing this to ensure that user who is selecting to publish some or all of the changes is at least aware of all the changes in XB regardless whether they want to publish all the changes or just a subset.

    2. only enforce the hashes match for selected changes

      In sites that have a lot of users using XB then requiring all the same enforcement we do now could make it difficult to publish a subset of changes if users are working on other changes that will not be published.

      For instance if there are 10 pages and user wants to publish 9 of those while 1 user is actively editing the 10th page then the user who is publishing may keep getting a validation error if the 10th page's auto-save state is updating frequently and therefore the hash for the 10th page that the client has stored is likely not to match the auto-save state

      They would also get a validation error if new pages were added since their list of changes was refreshed if we required all the entity keys be provided by the client.

    3. Enforce hashes for selected changes match and all entity keys are provided

      This would allow changes to be made to entities that are not going to be published but it would require the client to have the complete list of entities that will be published

      This should cause fewer validation errors because new entities are created less often then the auto-save state for entities would change

User interface changes

The "Review X changes" dialog would have the ablity to select changes to publish or revert.

🐛 Bug report
Status

Active

Version

0.0

Component

Page builder

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @tedbow
  • Comment about 1 month ago →
    🇺🇸United States tedbow Ithaca, NY, USA

    Before we can start doing the back-end changes for this, will to decide on the 1 current item in "Remaining questions"

    This is really a product question so assigning to Lauri

    My vote would be option 3. We require the client to list of all entity keys regardless of whether they will be published but all have to match the auto-save has for changes that will be published.

    This seems like a good balance of making sure the user is aware changes but also not stopping publishing of some items if another item is actively being edited in XB

  • Comment about 1 month ago →
    🇺🇸United States tedbow Ithaca, NY, USA
  • Comment about 1 month ago →
    🇺🇸United States tedbow Ithaca, NY, USA

    I chatted with @laurii and we agreed that for "Remaining questions 1" option 2 is best.

    this means the client will only has to send the information for the changes it wants to publish.

    This will mean even if there "Review X changes" list does not have the most recent entries or isn't aware that some entities might have been deleted that is ok because we poll the server every 10 seconds. But we will also create a child issue here to ensure that "Review X changes" list request has been made in the last 10 seconds. This way if gets bunch of network errors and their "Review X changes" is very old they will a new successful request before they can publish. This will ensure they should have nearly up-to-date list

  • Comment about 1 month ago →
    🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    FYI in testing 📌 Add e2e tests for moderation state in page data form Active I found that the moderation state takes precedence over the setPublished call in the auto save controller.

    i.e. With content moderation enabled for a node if the user selects 'Draft' in the page data form and then hits 'publish all changes' their wish to keep something as a draft is respected

    Might be something worth taking into account here.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024