There's a design flaw in how cr_templates/content_template works.
In CR, you can defined "content_types" and "item_subtypes".
Both are related.
content_type extends content_revision, and has a row in cr_revisions.
item_subtype extends content_item, and has a row in cr_items.
Problem statement:
content_template is defined as an item_subtype, but used as a content_type.
lars=# select object_type, supertype, table_name, id_column, package_name from acs_object_types where object_type = 'content_template';
object_type | supertype | table_name | id_column | package_name
------------------+--------------+--------------+-------------+------------------
content_template | content_item | cr_templates | template_id | content_template
(1 row)
Notice how its supertype is 'content_item', meaning it's an item_subtype.
create table cr_templates (
template_id integer
constraint cr_template_id_fk references
cr_items on delete cascade
constraint cr_templates_pk
primary key
);
Notice how the column references cr_items, not cr_revisions.
This is consitent with the information in the acs_object_types table:
lars=# select object_type, supertype, table_name, id_column, package_name from acs_object_types where object_type = 'content_template';
object_type | supertype | table_name | id_column | package_name
------------------+--------------+--------------+-------------+------------------
content_template | content_item | cr_templates | template_id | content_template
(1 row)
Now for how it's being used:
lars=# select item_id, name, live_revision, content_type from cr_items where content_type = 'content_template';
item_id | name | live_revision | content_type
---------+----------------------+---------------+------------------
544 | file-storage-default | 545 | content_template
284 | default_template | 285 | content_template
(2 rows)
Note how content_type says 'content_template', which is illegal since content_template is not a content_type.
So given that content_template's supertype is content_item, you'd think that object_id 284 is a content_template, but in fact, it's not:
lars=# select object_id, object_type from acs_objects where object_id = 284;
object_id | object_type
-----------+--------------
284 | content_item
(1 row)
Yet, there's still a row in cr_templates:
lars=# select * from cr_templates where template_id = 284;
template_id
-------------
284
(1 row)
So the default template's live_revision ID is 285, let's look closer at that:
lars=# select revision_id, item_id, title, content from cr_revisions where revision_id = 285;
revision_id | item_id | title | content
-------------+---------+----------+-------------------------------------
285 | 284 | Template | <html><body><content></body></html>
(1 row)
Which object_type does this object have?
lars=# select object_id, object_type from acs_objects where object_id = 285;
object_id | object_type
-----------+------------------
285 | content_template
(1 row)
content_template. But there's no row in cr_templates:
lars=# select * from cr_templates where template_id = 285;
template_id
-------------
(0 rows)
There should be according to the definition of the object_type.
PROPOSED CHANGE (not for current release, for 5.1):
- In types-create.sql, create content_template as a content_type, not an object_type.
- content_template__new needs to create a new content revision, and insert into cr_templates with the revision_id, not the item_id.
- Need to add a content_template__new_revision function.
Probably some other things as well.
The purpose of this post is to figure out to what extend people currently depend on the existing behavior, what other people's experiences are, and how we should go about fixing this.
/Lars
