400 Content Bin Basics

In a layout-driven channel, the exploitation of content is conditioned by the medium. This one is not intended to have its own dedicated contents: usually, it will exploit group content coming from of a referential.

The notion of content bin is applicable only to this type of channel: it is an automated management of project variations in the system allowing to make this exploitation of content fluid and flexible.

We will see that it obeys specific rules in terms of updating and duplication of content.

Project’s content bin: principle of operation

Naming conventions

Group referential

Contains all the contents that must be shared between several projects of the same group. This group repository is also called media library. It can be an internal object in Wedia (instances of galleryelement) or a connection to a third party service.

Project repository

Contains the contents specific to my project, not shared with other projects.
This project repository is called project content bin.

Contents of the project content-bin

The content elements in a project content bin can have several origins:

• declination of an element of the group repository

• direct import (page and emailing editor): for example, when I import an image file from my hard drive to a block of my document print (monodoc)

• import from the Digital Asset Management repository (DAM)

Import kinematics

When content A stored in the project repository is imported into a project:

1. it is duplicated once (A1) in the project content bin (project version),

2. if the user imports it in several blocks: no duplication (a single A1 instance is used),

3. if the user imports it into a block and then edits the element for modifications: creation of a variant of the A1' image, which then appears in the content bin and is specific to this block.

The principle of the single master and variants has been retained to link the blocks to a single instance, making it easier to synchronize and improves performance.

Unused elements of the content bin

If image A1' is deleted from the block and replaced by an image B1, it will remain in the content log. There is no automatic deletion of the variants called orphan.
This purge operation must be carried out by hand, by removing the elements concerned from the datalist.

Synchronizations - updates of the different elements

By multiplying versions of the same content on a medium, several processes have been put in place to synchronize the various elements (A to An or An').

Reminder:

• If the project version A1 is modified directly in a block of project support. (for example, item checkout or editing from the editor), we create a new local variant of A1' to the project, it is this element which is then referenced in the block.
  The A1 version remains unchanged and potentially referenced on other blocks.

• If variant A1' is modified from the content bin (from the "content" tab of the project dataview), a new specific variation A1'' is created.
  All blocks using A1' remain unchanged. The previous variants are kept in the content bin.

If A, the reference version, is changed, there are two separate mechanisms allow you to update your elements.

manually

by re-depositing the element from the repository on an element project (or variation), the project version A1 will be automatically synchronized with this one and referenced; the previous version of A1 will be converted into a variant and freely reusable.
All of the blocks referencing A1 will therefore be updated with the updated version of the element.

via the external synchronization mechanism

which allows you to view the list of projects using an instance of element A to decide on a global or case-by-case synchronization.

Technical requirements

The notion of a logger is managed by the support editor itself. It is he who, today, implements the logger using the tools and actions provided by the WXM_MediaCore plugin.

This functionality therefore requires the same prerequisites as the content declination and:

• a functional page editor (WXM_DTP_Manager for print for example, with all its prerequisites)

• creation of multiple declinations within the same project (variations) requires the present of a variation field (type integer) on the object of content to be used in the editor.

Easily parameterize the operation of the content bin

In the plugin parameters, you can intervene on the granularities of the projects content bin. For example, you can do this for particular object elements:

compofileedit_disable_project_version_on_objects

Deactivate the project version creation. It is the instance of the referential of the group that will be used and modified (if you edit it from the page editor).

compofileedit_disable_project_variations_on_objects

disable creation of n variations within the project. You will have only the project version and it is this one that will be modified when you edit the page.

compofileedit_project_project_version_keep_version_keep_asyncs_for_objects

disable the updating of the project version with an impact on all documents.
In this case, the project version will become a n variation. (used potentially several times in the project) and a new project version will be created.
You will keep your content history within the project.