Front End Attribute Editor provides three new blocks:

  • Front End Attribute Edit - Page
  • Front End Attribute Edit - User
  • Front End Attribute Edit - Product (requires eCommerce to be installed)

These blocks are very similar, so the details below apply to all the above blocks.

Any single block can be used to edit an attribute for the current page, current user or for the product on a product page. You cannot edit a page or product attribute from another page, or any other user's attributes than the current user. For pages and products, many page or product properties can also be edited.

To allow front end editing of multiple attributes, simply add multiple blocks to the page.


Front End AttributeEditor enables selected users to edit attributes with no further permissions settings to configure. The user(s) enabled to edit an attribute can be selected from:

  • The owner of the page
  • A single user
  • A group of users
  • Any registered user

Users that don't have access simply don't get to see the block. If you also have Magic Data, you can use a Magic Data expression to determine who has access.


This tab simply presents a list of attributes and properties available for editing, one of which may be selected. In the case of properties, this is limited to properties that are directly associated with a page or product and have a single value (for example, tiered pricing cannot currently be edited). Please check the screenshots for details.

A consequence of the perversity of some complex marketplace attributes is that they may not be editable through this block. If in doubt, please ask before purchasing.


Edit dialog

The edit dialog shown to edit file properties or attributes can be configured to use jQuery.ui, as per concrete5 core dialogs, or Fancybox.

In both cases, form element styling can be selected to follow concrete5 dashboard styling as per or to be unstyled.

For safety and security the default setting is that html tags should be stripped from all edited properties and attributes.


Additional Assets

The assets needed for the editable attributes should be loaded automatically. However, attributes can be strange things and there is no standardised method of loading some obscure attribute assets. Is such cases you may need to manually select for specific object/attribute assets to be loaded using the assets tab of the edit dialog.


Theming and templates

The HTML structure of Front End Attribute Editor is generated through a view, a library and a series of elements. However, all items are marked with css classes that can be used to manipulate the layout of items within the block.

For most theming requirements I recommend simply copying the view.php to a new template and the appearance can be substantially changed using the new template's view.css. The name of a template will be automatically inserted as a class in the outermost wrapping element of the block and dialogs, so can be easily used to scope and differentiate block themes.

The color and opacity of the Fancybox lightbox modal overlay may be adjusted using the site constants:


Alternatively, the overlay color and opacity may be hard coded into a view template.

When additional notifications are enabled, the default time the notification is shown is 3000ms. This may be adjusted by the site constant:




Advanced configuration and concrete5 version compatibility

Attribute compatibility

For concrete5 versions before, select attributes may not save or validate.

For concrete5 versions +, all core attributes can be edited and saved for pages and users.

For attribute types other than core attributes, compatibility is not guaranteed, but may be possible either by default or by adjusting site configuration constants as below.

Saving attributes

Inside Front End Attribute Editor, attributes are saved by one of two methods:

  1. Using Page or User object's setAttribute() method
  2. Through simulating the request post values passed to an attribute's saveForm() method

From concrete5.6.3.1 onward, method (1) is used by default for all attribute types. Before concrete5.6.3.1, method 2 is used by default.

To change this behaviour, the constant FRONT_END_ATTRIBUTE_SIMULATE_FORM_FOR_TYPES can be set as a comma separated list of attribute type handles or attribute handles, an empty string or as 'ALL_ATTRIBUTE_TYPES'.


The conatsnt FRONT_END_ATTRIBUTE_SKIP_VALIDATIOIN_FOR_TYPES can have similar values to FRONT_END_ATTRIBUTE_SIMULATE_FORM_FOR_TYPES. By default this is 'boolean'. If you have issues with specific attribute types or attributes, you can list them with this constant and the attribute's validateForm method will not be called.

Flattening Multi Dimensional Arrays

The conatsnt FRONT_END_ATTRIBUTE_FLATTEN_DATA_FOR_TYPES defaults to just 'select'. When enabled for an attribute, the form data is flattened to a plain list and any select option ids are converted to their respective values.

The only use I can see for this option other than the default is for third party attribute types that extend the select attribute type. However, it may also be relevant to other third party attribute types.