Controlling the Publishing Workflow

A typical requirement for a publishing application (newspapers, journals, etc.), is the support for a publication workflow, that should include - at the very least - the possibility to "publish" and "unpublish" content.

More complex workflows normally include other statuses such as "draft" and "needs review", that can be changed by users having specific roles.


Node Statuses in Quanta

In Quanta, statuses are just standard nodes, placed in the _statuses folder.

By default, Quanta offers these statuses:

Where each status is a node, contained in the _statuses folder.

📂  _statuses
  • 📁  node-status-unpublished
    • 📁  node-status-published
      • 📁  node-status-draft


        Changing a Node's Status

        In Quanta, when editing a node, a document's status can be set in the "manage status" tab (assuming you are showing that tab in your Shadow form).

        quanta node status

        Example of Node status form displayed in a Shadow form.


        Working with Statuses

        How you deal with statuses, is up to you. We decided not to enforce a default behavior (i.e. "anonymous can't see draft pages" or "user can publish pages that he owns"), simply because we believe such criterias are specific and different  in each application, and it wouldn't make sense to decide that for you.

        Using custom hooks, you will be able to decide how to deal with statuses, once they are set.   

        The following example, shows how a simple hook can be created into a custom module, to limit Anonymous user's access to an unpublished node.


        Creating new Statuses

        How you deal with statuses in your Application, is completely up to you.

        We decided not to enforce a default behavior (i.e. "anonymous can't see draft pages" or "user can publish pages that he owns"), simply because we believe such criterias are specific and different  in each application, and it wouldn't make sense to decide that for you.

        Using custom hooks, you will be able to decide how to deal with statuses, once they are set.   

        The following example, shows how a simple hook can be created into a custom module, to limit Anonymous user's access to an unpublished node.

        If you decide that a behavior such as the above should be default for all of your applications, just include it into a module, and make it part of one of your profiles.