plone.app.contenttypes provides default content types for Plone based on Dexterity. It replaces Products.ATContentTypes and provides the default-types in Plone 5. It can be used as an add-on in Plone 4.x.

It contains the following types:

Collection

Document

Event

File

Folder

Image

Link

News Item

The main difference from a users perspective is that these types are editable and extendable through-the-web. This means you can add or remove fields and behaviors using the control-panel “Dexterity Content Types” (/@@dexterity-types).

Warning: Using plone.app.contenttypes on a site with existing Archetypes-based content requires migrating the sites content. Please see the chapter “Migration”.

To use plone.app.contenttypes in Plone 4.x add this line in the eggs section of your buildout.cfg

eggs=
...
plone.app.contenttypes

If you have a Plone site with mixed Archetypes and Dexterity content use the extra requirement atrefs.

eggs=
...
plone.app.contenttypes [atrefs]

This will also install the package plone.app.referenceablebehavior that allows you to reference dexterity-based content from archetypes-based content. You will have to enable the behavior plone.app.referenceablebehavior.referenceable.IReferenceable for all types that need to be referenced by Archetypes-content.

If you install plone.app.contenttypes in a existing site all Archetypes-based content of the default types still exists and can be viewed but can’t be edited. On installation plone.app.contenttypes removes the type-definitions for the old default-types like this:

<objectname="Document"remove="True"/>

They are then replaced by new Definitions:

<objectmeta_type="Dexterity FTI"name="Document"/>

To make the existing content editable again you need to migrate it to Dexterity (please see the section on migration) or uninstall plone.app.contenttypes (see the section on uninstalling).

Archetypes-based content provided by add-ons (e.g. Products.PloneFormGen) will still work since only the default-types are replaced.

If you install plone.app.contenttypes on a fresh site (i.e. when no content has been edited or added) the usual default-content (Events, News, Members…) will be created as dexterity-content.

plone.app.dexterity >= 2.0.7. Dexterity is shipped with Plone 4.3.x. Version pins for Dexterity are included in Plone 4.2.x. For Plone 4.1.x you need to pin the right version for Dexterity in your buildout. See Installing Dexterity on older versions of Plone.

plone.dexterity >= 2.2.1. Olders version of plone.dexterity break the rss-views because plone.app.contenttypes uses behaviors for the richtext-fields.

plone.app.event >= 1.1.4. This provides the behaviors used for the event-type.

plone.app.portlets >= 2.5a1. In older version the event-portlet will not work with the new event-type.

There is also a view /@@pac_installer that allows you to install plone.app.contenttypes without replacing those archetypes-types with the dexterity-types of which there are existing objects in the site. Afterwards it redirects to the migration-form and only the types that you chose to migrate are installed. This allows you to keep certain types as archetypes while migrating others to dexterity (for example if you did heavy customizations of these types and do not have the time to reimplement these features in dexterity).

Topics are migrated to Collections. However, the old type Topic had support for Subtopics, a feature that does not exit in Collections. Subtopics are nested Topics that inherited search terms from their parents. Since Collections are not folderish (i.e. they cannot contain content) Subtopics cannot be migrated unless Collections are made folderish (i.e. that they can contain content). Also the feature that search terms can be inherited from parents does not exist for Collections.

The migration-form will warn you if you have subtopics in your site and your Collections are not folderish. You then have several options:

You can delete all Subtopics before migrating and achieve their functionality in another way (e.g. using eea.facetednavigation).

You can choose to not migrate Topics by not selecting them. This will keep your old Topics functional. You can still add new Collections.

You can modify Collections to be folderish or create your own folderish content-type. That type would need a base-class that inherits from plone.dexterity.content.Container instead of plone.dexterity.content.Item:

You can either use a new Collection type or simply modify the default type to use this new base-class by overriding the klass-attribute of the default Collection. To override add a Collection.xml in your own package:

The migration-form warns you if any of your old types were extended with additional fields using archetypes.schemaextender. The data contained in these fields will be lost during migration (with the exception of images added with collective.contentleadimage).

To keep the data you would need to write a custom migration for your types dexterity-behaviors for the functionality provided by the schemaextenders. This is an advanced development task and beyond the scope of this documentation.

collective.contentleadimage was a popular addon that allows you to add images to any content in your site by extending the default types. To make sure these images are kept during migration you have to enable the behavior “Lead Image” on all those types where you want to migrate images added using collective.contentleadimage.

The old types that use leadimages are listed in the navigation-form with the comment “extended fields: ‘leadImage’, ‘leadImage_caption’”. The migration-form informs you which new types have the behavior enabled and which do not. Depending on the way you installed plone.app.contenttypes you might have to first install these types by (re-)installing plone.app.contenttypes.

To help you migrating these types to Dexterity plone.app.contenttypes contains a migration form (/@@custom_migration) that allows you to migrate any (custom or default) Archetypes-type to any (custom or default) Dexterity-type. The only requirement is that the target-type (the Dexterity-type you want to migrate to) has to exist and that the class of the old type is still present. It makes no difference if the type you are migrating from is still registered in portal_types or is already removed or replaced by a dexterity-version using the same name.

In the form /@@custom_migration you can select a Dexterity-type for any Archetypes-types that exists in the portal. You can then map the source-types fields to the targets fields. You can also choose to ignore fields. You have to take care that the values can be migrated (since there is no validation for that), e.g. it would make no sense to migrate a ImageField to a TextField. There are build-in methods for most field-types, custom or rarely used fields might not migrate properly (you can create a issue if you miss a migration that is not yet supported).

After you map the fields you can test the configuration. During a test one item will be test-migrated and Plone checks if the migrated item will be accessible without throwing a errors. After the test any changes will be rolled back.

It is recommended that you reuse the migration-code provided by plone.app.contenttypes in plone.app.contenttypes.migration.migration.migrateCustomAT for custom migrations.

To do this you have to simply pass a mapping of source- to target-fields to a migration-method for each type.

fromplone.app.contenttypes.migration.migrationimportmigrateCustomATdefmy_custom_migration():fields_mapping=({'AT_field_name':'some_field','DX_field_name':'description',},# Migrate AT imagefield to DX imagefield using the mapping in# plone.app.contenttypes.migration.field_migrators.FIELDS_MAPPING{'AT_field_name':'some_atimage','DX_field_name':'some_dximage','DX_field_type':'NamedBlobImage',},)migrateCustomAT(fields_mapping,src_type='SomeATType',dst_type='SomeDXType')

A field-dict without a key DX_field_type from one of the migrators in plone.app.contenttypes.migration.field_migrators.FIELDS_MAPPING will always use plone.app.contenttypes.migration.field_migrators.migrate_simplefield as its migration-method. That can migrate most field-types where the value does not have to change (e.g. strings, lists, tuples, dicts etc.).

plone.app.contenttypes.migration.field_migrators has special field migrators for the following field-types: RichText, NamedBlobFile, NamedBlobImage, Datetime, Date. They transform values from the Archetypes-version of such fields to their Dexterity counterparts.

If you use rare or custom fields or want to apply special transforms to your data while migrating you can pass custom methods as field_migrator with the fields_mapping. This way you can migrate fields that are usually not migrateable.

Here is an example where this method is used to migrate a Richtext-Field into a Tuple-Field by passing the custom field-migrator some_field_migrator. In such a custom migrator you can do just about anything you wish.

Before version 1.0a2 the content-items did not implement marker-interfaces. They will break in newer versions since the views are now registered for these interfaces (e.g. plone.app.contenttypes.interfaces.IDocument). To fix this you can call the view /@@fix_base_classes on your site-root.

Since plone.app.contenttypes 1.1a1, the Collection type uses the new Collection behavior and the Event type utilizes behaviors from plone.app.event. In order to upgrade:

First run the default profile (plone.app.contenttypes:default) or reinstall plone.app.contenttypes

When used in Plone 4.x plone.app.contenttypes uses the default z3c.form widgets. All widgets work as they used to with Archetypes except for the keywords-widget for which a simple linesfield is used. Replacing that with a nicer implementation is explained below.

It is also possible to use plone.app.widgets to switch to the widgets that are used in Plone 5.

The schemata for the types File, Image and Link are defined in xml-files using plone.supermodel. This allows the types to be editable trough the web. The types Document, News Item, Folder and Event have no schemata at all but only use behaviors to provide their fields.

If you use the profile default then the default-content in new sites will still be Archetypes-based. You’ll then have to migrate that content using the migration-form @@atct_migrator or delete it by hand.

If you changed the base-class of existing types (e.g. because you changed them to be folderish) you also need to upgrade the base-class of existing objects. You can use the following form for this: @@base_class_migrator_form.

This form lets you select classes to be updated and shows the number of objects for each class. This form can be used to change the base-class of any dexterity-types instances. The migration will also transform itemish content to folderish content if the new class is folderish. You might want to use the method plone.app.contenttypes.migration.dxmigration.migrate_base_class_to_new_class in your own upgrade-steps.

You could alternatively override the peroperty model_file of the type-definition with a empty string and use the property schema to provide your custom python-schema.

For more complex features you should always consider create custom behaviors and/or write your own content-types since that will most likely give you more flexibility and less problem when you want to upgrade to a newer version in the future.

Remove path index injection in “plone.collection” behaviors results method.
It is a duplicate.
Exactly the same is done already in the plone.app.querybuilder.querybuilder._makequery,
which is called by above results method.
[jensens]

Deferred adapter lookup in collection view.
This was looked up for contentmenu/toolbar at every authenticated request.
It also had side effects if custom collection behaviors are used.
[jensens]

Fixed unstable robot test for location criterion. [maurits]

Don’t fail for utils.replace_link_variables_by_paths, if value is None.
The value can be None when creating a Link type with invokeFactory without remoteUrl set and calling the indexer before setting the URL.
[thet]

Handle languages better for content that is create when site is generated
[vangheem]

In FolderView based views, don’t include the portal_types query, if
object_provides is set in the results method keyword arguments. Fixes
a case, where no Album Images were shown, when portal_state’s
friendly_types didn’t include the Image type.
[thet]

Register folder and collection views under the same name. Old registrations
are kept for BBB compatibility.
[thet]

Refactor full_view and incorporate fixes from collective.fullview to
1) display the default views of it’s items, 2) be recursively callable
and 3) have the same templates for folder and collections.
[thet]

Refactor folder_listing, folder_summary_view, folder_tabular_view and
folder_album_view for folders as well as standard_view (collection_view),
summary_view, tabular_view and thumbnail_view for collections to use the same
templates and base view class.
[thet]

In the file view, render HTML5 <audio> or <video> tags for audio
respectively video file types. Ancient browsers, which do not support that,
just don’t render these tags.
[thet]

Define default_page_types in the propertiestool.xml profile.
[thet]

Add event_listing to available view methods for the Folder and Collection
types.
[thet]

Add form to install pac and forward to dx_migration
after a successful migration to Plone 5
[pbauer]

Rename atct_album_view to folder_album_view.
[pbauer]

Do a better check, if LinguaPlone is installed, based on the presence of the
“LinguaPlone” browser layer. Asking the quick installer tool might claim it’s
installed, where it’s not.
[thet]

Register folderish views not for plone.app.contenttypes’ IFolder but for
plone.dexterity’s IDexterityContainer. Now, these views can be used on any
folderish Dexterity content.
[thet]

Add a ICustomMigrator interface to the migration framework, which can be used
to register custom migrator adapters. This can be useful to add custom
migrators to more than one or all content types. For example for
schemaextenders, which are registered on a interface, which is provided by
several content types.
[thet]

In the migration framework, fix queries for Archetype objects, where only
interfaces are used to skip brains with no or Dexterity meta_type. In some
cases Dexterity and Archetype objects might provide the same marker
interfaces.
[thet]

Add logging messages to content migrator for more verbosity on what’s
happening while running the migration.
[thet]

Use Plone 4 based @@atct_migrator and @@atct_migrator_results template
structure.
[thet]

Collection: get querybuilderresults view instead of using the
QueryBuilder class directly.
[maurits]

Fix migration restoreReferencesOrder removes references
[joka]

Enable summary_view and all_content views for content types that
have the collection behavior enabled. Define collection_view for
those types so you can view the results. These simply show the
results. The normal view of such a type will just show all fields
in the usual dexterity way.
[maurits, kaselis]

Add customViewFields to the Collection behavior. This was available
on old collections too.
[maurits, kaselis]

Change Collection to use a behavior. Issue #65.
[maurits, kaselis]

Improved test coverage for test_migration
[joka]

Add tests for vocabularies used for the migration
[maethu]

Add migration-form /@@atct_migrate based on initial work by gborelli
[pbauer, tiazma]

Fix Bug on SearchableText_file indexer when input stream contains
characters not convertable in ASCII. Assumes now utf-8 and replaces
all unknown. Even if search can not find the words with special
characters in, indexer does not break completely on those items.
[jensens]

Remove dependency on plone.app.referenceablebehavior, as it depends on
Products.Archetypes which installs the uid_catalog.
[thet]

Make collection syndicatable.
[vangheem]

Include the migration module not only when Products.ATContentTypes is
installed but also archetypes.schemaextender. The schemaextender might not
always be available.
[thet]

Add fulltext search of file objects.
[do3cc]

Fix link_redirect_view: Use index instead of template class var to
let customization by ZCML of the template.
[toutpt]