Create Component Schemas

Embedded component schemas are required to create component content units.

• See Creating Component Schemas for details.
• See Component Content Units for details about the relationship between component schemas and content units.

Create Content Units

Field and component content units serve as building blocks that you add to Page Builder layouts. By default, Page Builder provides basic form content units. For CMS 10.6 Page Builder forms, see CMS 10.6 Forms in Page Builder. For CMS 10.0–10.5, see CMS 10.0–10.5 Forms in Page Builder for details.

To build other content units, users must have administrative rights to Administration > Presentation Content Units. If a non-administrative user will create content units, refer to Setting Content Unit Permissions below.

Develop Views

Before content units can be applied in Page Builder presentations, ASP.NET developers must create views (for some organizations, developers may need to extend legacy XSLT stylesheets for page type and content unit presentations.). In most cases, the content unit views are similar to their schema type counterparts. Developers can use the views of the embedded schemas as a foundation when building content unit views.

While schema type views and their content unit counterparts have inherent similarities, it's a best practice not to use schema type views for the dual purpose of styling content units. A change to the schema type view may affect the styling of the content view, inadvertently. For this reason, even when the code for a content unit view is exactly the same as its schema type counterpart, the field name of the content unit should be different than the tag name of the embedded schema. If you follow this practice, the code for these respective views reside in separate files.

Complete the following tasks:

• Insert content container @id attributes within page views used by Page Builder. Developers contribute to Page Builder by inserting @id attributes within the layout of ASP.NET views. When working with @id attributes, we strongly recommend the following.

  • Add at least one HTML @id attribute within the HTML of each page view.
  • Place the HTML @id attributes on a primary container, such as a <div> element that wraps around an area of the page design (e.g., the main content container).
  • Ensure that each container for the various discrete parts of the view layout (e.g., left,right, and center columns) has a unique HTML @id attribute value added to their markup in the view.

  After adding an @id in the HTML of the view, these <div> elements become selectable within the Page Builder design workspace (i.e., Site > Design tab) to create a presentation for that area.

• Add Razor's Helpers directive (RenderICEAttribute) to content unit views. This allows content contributors to use In-Context Editing (ICE) of Page Builder fields.
  • For CMS 10.6, see CMS 10.6 Configuring the ICE Helper for details.
  • For CMS 10.0–10.5, see CMS 10.0–10.5 Rendering In-Context Editing (ICE) Content for details.
• Develop views for Page Builder content units as a developer or user. Choose one of the following steps.
  • As a developer, save views to the Views/Shared/Editable folder in the DSS project. See Adding MVC Views in VS Project for details.
    Note

    If you are new to ASP.NET MVC development, see Building an MVC Website as a starting point.
  • As a user, save views to the Views/Shared/Editable folder in the Assets Manager. See MVC Views as Managed Assets for details.
    Version Notes: CMS 10.6 vs. CMS 10.0–10.5

    For CMS 10.6, see CMS 10.6 Creating Content Unit Views for details.

    For CMS 10.0–10.5, see CMS 10.0–10.5 Creating Content Unit Views for details.

Enable Presentations Formatter (Optional)

In order for Page Builder pages to be styled with CSS at runtime, you must apply a formatter. By default, Ingeniux CMS provides the Bootstrap v3.0 framework. If you require Bootstrap 2.33 or either of the two custom formatters, see Presentations Formatter.

You can access the Page Builder Presentation Formatter sets in Administration > Publishing System > Publishing Targets > [choose appropriate publishing target] > Info > Page Builder Settings.

Set Content Unit Permissions

Usually CMS administrators create content units; however, any CMS user group can be given permission to do so. To set these group permissions, administrators navigate to the appropriate group(s) in Administration > Users/Groups > Groups > Info.

For details about how administrators set permissions on groups, see Creating Groups.

Required

Users must have these permissions to access Administration > Presentation Content Units. Select the following permissions:

• Allowed to manage presentation content units: Users can work with content units. Usually, this right is given to administrators, who retain this permission by default, and developers.
  Tip

  Navigate to the Permissions on page presentations designing block.
• Allowed to manage schemas: Enables group members to access Schema Designer in the Administration pane.
  Tip

  Navigate to the Miscellaneous block.

Optional

Users may benefit from having other permissions in addition to required PCU permissions. For example, to enable users to complete related tasks, you can assign permissions that expand the user's toolset and flexibility (e.g., access built-in views in the Assets Tree). If you wish to assign responsibilities to respective users, you can designate specific permissions to a user group for managing presentation content units, another group for managing content unit built-in views, etc. Administrators can establish a workflow to process work between these groups.

See List of Group Permissions for details about all permissions. Choose permissions that best meet your team's needs.

Recommended permissions include:

Permissions on asset manipulations: Assigns or removes the following block of permissions related to asset manipulations.

• Allowed to work with asset system: When selected, group members can access the Assets Manager.
• Allowed to edit asset metadata: When selected, group members can edit metadata in the Assets Manager.
• Allowed to delete assets: When selected, group members can delete assets from the Assets Manager.
• Allowed to check in assets and asset folders assigned to others: When selected, group members can check in assets and asset folders that are assigned to other users.
• Allowed to rollback assets: When selected, group members can rollback assets.
• Allowed to assign assets and asset folders assigned to others: When selected, group members can assign assets and asset folders to other users.
• Allowed to create assets: When selected, group members can create new assets.
• Allowed to check in/check out assets and asset folders: When selected, group members can check in and check out assets and folders.

Permissions on Assets Tree manipulations: Assigns or removes the following block of permissions related to modifying objects in the Assets Tree.

• Allowed to see the Assets Tree: Enables group members to view the Assets Tree in the CMS.
• Allowed to manage asset folders: When selected, group members can execute tasks, such as moving an asset folder within the Assets Tree.
• Allowed to reorder assets and folders in the assets tree that are assigned to others: Enables group members to relocate assets assigned to other users. If group members with this permission have full access to the start and end location of a given asset, they can move another user's asset to a new location in the Assets Tree.

Set Design Permissions

As an administrator, ensure that Page Builder designers and content contributors have adequate access to their respective work areas. To set group permissions, navigate to the appropriate group(s) in Administration > Users/Groups > Groups > Info.

For details about how administrators set permissions on groups, see Creating Groups.

Required

Users must have these permissions to access ICE and Page Builder in the Design tab. Select the following permissions:

Permissions on page manipulations: Assigns or removes the following block of permissions related to modifying pages.

• Allowed to edit pages: Enables group members to edit existing pages assigned to the current user.
• Allowed to delete pages: Enables group members to delete pages.
• Allowed to check-in pages assigned to others: Enables group members to check in pages that are currently assigned to another user.
• Allowed to rollback changes: Enables group members to rollback to a prior version of the page.
• Allowed to assign pages not assigned to them to others: Enables group members to assign pages to other users, even though these pages are not currently assigned to the group members.
• Allowed to create pages: Enables group members to create a new page via page creation rules or page types depending upon which additional permissions are selected.
• Allowed to create new pages using page types: Enables group members to create pages by specifying the page type (as opposed to using page creation rules).
• Allowed to check-in and check-out pages outside of workflow: Enables group members to check in or check out pages part or not part of a workflow.

Permissions on page presentations designing: Assigns or removes the following block of permissions related to designing page presentations.

• Allowed to manage presentation content units: Users can work with content units. Usually, this right is given to administrators, who retain this permission by default, and developers.
• Allowed to work with presentations on pages: Enables group members to access page presentations.
• Allowed to change layout in presentation: Enables group members to access page presentations to add, delete, or modify layouts.
• Allowed to place content units and remove placed content units: Enables the group to modify content units in page presentations.
• Allowed to move placed content units to different locations: Enables the group to modify already-placed content units in page presentations.
• Allowed to create and manage presentations on pages: Enables the group to create page presentations.

Optional

Users may benefit from having other permissions in addition to required permissions for Page Builder. For example, to enable users to complete related tasks, you can assign permissions that expand the user's toolset and flexibility (e.g., enable access to Site Tree, page history, publishing options). If you wish to assign responsibilities to respective users, you can designate specific permissions to a user group for designing Page Builder presentations, another group for editing content inside designed presentations, etc. Administrators can establish a workflow to process work between these groups.

See List of Group Permissions for details about all permissions. Choose permissions that best suit you and your users' needs.

Recommended permissions include:

Permissions on page content viewing and manipulations: Assigns or removes the following block of permissions related to viewing and modifying page content.

• Allowed to edit the layout attribute on pages: Enables group members to change the default stylesheet applied to the current page.
• Permission to edit password elements: Enables group members to edit password elements.
• Allowed to view elements marked as "hidden" in Edit form: Enables group members to view hidden elements in the Edit form.
• Allowed to add words to dictionary during spellcheck: Enables group members to add words to the default dictionary during a spellcheck.
• Allowed to see Edit Form for page edit: Enables group members to access the edit form.
• Allowed to see page history: Enables group members to see the page's workflow history information.
• Allowed to view XML tab: Enables group members to access the XML tab to review XML for a specific page or component.
• Allowed to embed/unembed component fields: Enables group members to embed components within components.

Permissions on site tree manipulations: Assigns or removes the following block of permissions related to modifying objects in the Site Tree.

• Allowed to reorder pages in the site tree: Enables group members to move pages assigned to them, provided that the group has full access to the start and end locations of Site Tree pages.
• Allowed to see the tree: Enables group members to view the Site Tree in the CMS.
• Allowed to reorder pages in the tree that are assigned to others: Enables group members to relocate pages assigned to other users. If group members with this permission have full access to the beginning and ending location of a given page in the Site Tree, they can move another user's page to a new location in the Site Tree.

Permissions on publishing: Assigns or removes the following block of permissions related to publishing site content.

• Allowed to mark and unmark pages for publishing: Enables group members to mark and unmark pages to publish.
• Allowed to execute a full publish: Enables group members to execute full publishes, including a site publish.
• Allowed to execute an incremental publish: Enables group members to execute incremental publishes.
• Allowed to repeat a publish to the same root page and publishing target: Enables group members to repeat a publish request before a previous, identical publish completes.