We recently adopted Directus. We started with v11 and migrated to v12 already. The changes on the editorial workflow seems great but they already disrupted how we’ve setup things.
Now on v12 when versioning is enabled on a collection Draft items that are unpublished from creation are not given an associated item. As such they don’t have an itemId, they do have a versionId.
The lack of an itemId means that we can’t query them from the items API. Up until know I used the items API with a version parameter to get the item with changes applied. This was very convenient.
Now for items that only exist on a Draft version I don’t seem to have a way to pull the whole item from an API, only the changes.
The itemId is assigned only after the “promote” is done.
An effect of this change is that I can’t associate fields that are live only in a Draft version. This means I can’t prepare complex data in preview mode. Items that do not exist in main version can’t be referenced.
All this seems to push me back to a v11 status column, unless I am missing something.
Unfortunately the collection creation UI no longer has support for status, now only archived. Doing this manually still has some paper cuts that users will need to Publish with status=Draft to get a main version.
Is there any recommendation to either fully embrace new v12 ways of doing things or improving the ergonomic to ensure an id is associated and full item to be retrieved/referenced?
FWIW I use UUID always to there is not conflict in assigning an id before hand.
Hey @bcardiff - item-less drafts are a new capability in v12 but do have some limitations. In v11 every version had to run off an existing row; now you can draft genuinely net-new content that has no row yet. That being said the trade-off is exactly what you’re hitting - no itemId until you promote (promotion is what creates the row and back-links the id).
The current architecture does leave gaps (we are well aware):
To fetch the full draft - use the list endpoint, not a single-item GET, i.e.
GET /items/<collection>?version=draft
This returns the whole computed item for each draft (not just the delta), each tagged with $meta.version_id. You can target a specific one by filtering on its fields, e.g. &filter[slug][_eq]=my-post. Note: the primary key comes back null (as the row doesn’t exist yet), so $meta.version_id is the stable handle.
This works for relational/complex data too — which should cover your “prepare complex data in preview mode” case. You must expand the fields explicitly:
GET /items/?version=draft&fields=,tags.tags_id.,author.*
You’ll get the fully-resolved nested content back, not just the changes. One thing to be aware of: any related records you created inline within the draft come back with their data populated but a null id - same reason as above, they don’t exist as rows yet.
Referencing draft-only items from other items - genuinely not possible today. A relation needs a persisted row to point at, and a draft-only item has none until promote (pre-assigning a UUID doesn’t bridge this, since there’s still no row). So the read/preview side is covered, but cross-referencing isn’t.
The best workaround if you absolutely need referenceable ids before publishing: create the real row up front and use an explicit flag - and layer versions/drafts on top of a row that already exists. Appreciate this is not perfect, and as @Beth indicated, we are continuing to invest in the versioning system to close these gaps.
The best I can think of for v12 is to have an active boolean column next to the archived one. To distinguish if the main record should be treated as published or not. This at least requires less clicks than recreating the v11 status dropdown…
Still I would like to know if there is a better alternative currently for v12.
Hey @bcardiff, I believe our team has separately been chatting with you but to also share the reply here:
In v12, we introduced a new approach to content versioning that allows you to save drafts as item-less versions (more about how this works in our Content Versioning Guide).
Currently, these item-less drafts are incompatible with the Live Preview feature. Our product team is aware of this limitation, and we are planning to bring Live Preview support to these drafts in the future. We don’t have a concrete ETA for this improvement at the moment, but it is on our radar as we continue to refine our versioning tools.