Weston Ruter

what is exactly the plan for staged, scheduled and batched? Are you going to prevent posting new content, or do theme/plugin/core updates until the changeset is applied? because each of those may negate the impact of the changeset.

Batched changes are just an aspect of how the customizer publishes changes to start with, where you can make X changes in a customizer session and publishing them makes them all go live together. Changesets then extends this to allow those pending changes to persist in a custom post type, which then allows for those changes to be drafted, scheduled, and published later.

There is no content freeze to site changes when there is a pending changeset. There can be any number of changesets worked on concurrently. When you make a change in the customizer, only the modified (dirty) settings get included among the customized state and only these values get saved into the changeset. So if someone creates a changeset and schedules it for publishing in a week, other changes that are made to the site aren’t going to be overridden by the scheduled changeset unless they’re the same specific settings that were modified.

The Customize Posts plugin makes use of auto-draft posts to reserve post IDs for a customizer session, and this ensures that IDs for posts specifically don’t conflict. Creation of new widgets in core is not resilient to concurrent user sessions, either in the admin or in the customizer. See #35669 for work being done in that area. There is also a feature plugin that addresses the problem of concurrent widget creation in the customizer. Nav menus need to be looked at for issues related to concurrent editing. See also #31436 for general concurrency improvements in the customizer, but concurrent editing is a general problem in WordPress not just the customizer.

staging is a solved problem in web development, you just need a different staging site to work on, and you make your changes in code so you can track them on GIT/SVN. The changeset feature is just a bloat for most people that don’t do any long customization sessions, and it is just not good enough and can never be made good enough for people that actually need staging.

Staging is a solved problem in web development for code not for content. There are many efforts underway right now to try to find the best solution for that, including VersionPress and Mergebot by Delicious Brains. The customizer has always been the WordPress interface for live previewing changes, that is, for staging changes to go live within a (short) user session. Even so changesets have immediate value for these users since they allow for the customized data to persist when switching themes in that same session and for recovering the pre-published changes after a browser crash. But changesets also open the door for staging content for longer periods. Users can (even now in 4.7) send the customizer URL to someone else so they can make additional changes to the same changeset. Changesets could go through editorial review and get stakeholder sign off while also being scheduled for publishing.

It’s true that changeset conflicts will arise in such usages. So that is partly why there no UI exposed in core for long-term staging. The Customize Snapshots plugin is where we’re actively working on keeping track of conflicts and presenting UIs for drafting, scheduling, and publishing changes while considering presenting UIs for letting users resolve conflicts. Once the features are developed in the plugin, then they’ll be proposed for core inclusion.

Name *

Email *

Website:

Topic Title (Maximum Length: 80):

Forum:
— No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor