I am currently working on fixing document type compositions in v7. And I hit some questions that require... community input. Here goes the first one:
Assume I create
content type WithMetaTitle that has a tab named Meta that has a property MetaTitle
content type WithMetaKeywords that has a tab named Meta that has a property MetaKeywords
content type MyContent that is composed of both WithMetaTitle and WithMetaKeywords
and content type MyContent adds property Whatever to the Meta tab
Of course... we all assume that when editing a content of type MyContent, we'll see one tab named Meta with two properties, MetaTitle and MetaKeywords. So far, so good.
Question: what-if I edit content type WithMetaTitle and change the tab's name to NewMeta? When I go and edit my content, what's the name of the tab (or is it tabs...)? Where is the Whatever property? What makes most sense from a user's point of view?
From my perspective, MyContent would still include a composition (namely, WithMetaKeywords) that has a Meta tab, so the Whatever property could stay there (in the Meta tab).
@Andy, @Nicholas: so option 1 would be, do not rename an "inherited" tab as long as it still can inherit from a tab with its name. In our case, renaming WithMetaTitle.Meta to WithMetaTitle.NewMeta does not rename MyContent.Meta - but then if I rename WithMetaKeywords.Meta to WithMetaKeywords.DingDang, it would rename MyContent.Meta too. Makes sense and is consistent...
Yes, that sounds sensible to me too. As you say, once you've made a decision to set up a composition, you've linked the two items, so - in the absence of another matching name as per your first question - renames should cascade down.
I just wrote a long reply, but I realized that i dont actually know how the composition works exactly.
If I have the doctypes from the original post:
content type WithMetaTitle that has a tab named Meta that has a property MetaTitle
content type WithMetaKeywords that has a tab named Meta that has a property MetaKeywords
content type MyContent that is composed of both WithMetaTitle and WithMetaKeywords
and content type MyContent adds property Whatever to the Meta tab
Does the MyContent actually have it's own Meta tab, or is it truly inherited? What happens if I explicitly create a Meta tab on the MyContent doctype? Will there be a difference from a database perspective?
To start, I find the fact that you use Content Type interchangably with Document Type confusing. In the backed under Document Types there are many references to things like "This Content Type uses X as a Master Content Type." So I think that there should be a consensus to stick with a single terminology and not mix them up.
As for compositions, I think I understand the idea behind this but I'm not sure if I agree with the approach. It's almost like looking for a problem that isn't there or it's a solution for a different problem. I see compositions almost as a way of working with grouped or shared data types and avoiding having to have complex tree's of Document Types. The approach I would recommend would be the ability to create Document Type Elements which would be groups of data types that are created independant of a "Tab" name. This way you could great a "meta" group, that has elements like MetaTitle, MetaKeywords and you could add it to any tab of any Document Type. Changing a tab name wouldn't affect MetaTitle but changing MetaTitle (from maybe text to text multiline) would update all document types that use it.
I'm not sure if that makes sense or if I'm totally misunderstanding the purpose of Compositions. Either way I think it would be a handy feature.
"Derived question: create root type MyContent1, tab MyTab, ppty MyProp1 create root type MyContent2, tab MyTab, ppty MyProp2 add type MyContent1 as a composition to MyContent2 rename MyContent1.MyTab to MyContent1.SomethingElse I would assume that MyContent2's tab name changes to SomethingElse too? So it's all done by name - soon as tabs with same names are composed, we assume they are related."
I would have two different tabs: MyTab and SomethingElse. If users want the same tab name, they have to rename explicitly MyContent2.MyTab to MyContent2.SomethingElse. And if at some point they decide to undo the composition, each tab would keep its original name, except if they have explicitly changed (renamed) it.
Another example could be:
Content Type: SEO - Tab: SEOFields * Property: Title * Property: Description
Add type SEO as a composition to NEWS Add type SEO as a composition to BLOG
When creating contents for NEWS and BLOGPOST:
Content: Blog01 - Tab: Data * Property: NewsSummary * Property: NewsContent - Tab: SEOFields * Property: Title * Property: Description
Content: BLOGPOST01 - Tab: Data * Property: BlogSummary * Property: BlogContent - Tab: SEOFields * Property: Title * Property: Description
What happen if someone renames the tab "SEOFields" to "Data" for the content type SEO? All properties would appear in one tab named "Data" for both NEWS and BLOGPOST, wouldn't they?
Content: Blog01 - Tab: Data * Property: Title * Property: Description * Property: NewsSummary * Property: NewsContent
Content: BLOGPOST01 - Tab: Data * Property: Title * Property: Description * Property: BlogSummary * Property: BlogContent
They realize that it was a mistake an rename back the tab "Data" to "SEOFields" for the content type SEO. Properties should appear as initially, shouldn't they?
Content: Blog01 - Tab: Data * Property: NewsSummary * Property: NewsContent - Tab: SEOFields * Property: Title * Property: Description
Content: BLOGPOST01 - Tab: Data * Property: BlogSummary * Property: BlogContent - Tab: SEOFields * Property: Title * Property: Description
What do you think?
I got the following error In Umbraco 720 Beta 2 when there is a clash between property names in the composition:
Server error: Contact administrator, see log for full details. Failed to retrieve data for child nodes undefined
LOG Error: System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> Umbraco.Core.Exceptions.InvalidCompositionException: InvalidCompositionException - ContentType with alias 'T1' was added as a Compsition to ContentType with alias 'T2', but there was a conflict on the PropertyType alias 'p2'. PropertyTypes must have a unique alias across all Compositions in order to compose a valid ContentType Composition. at Umbraco.Core.Models.ContentTypeCompositionBase.AddContentType(IContentTypeComposition contentType) at Umbraco.Core.Persistence.Repositories.ContentTypeBaseRepository`1.ContentTypeQueryMapper.MapContentTypeChildren[TRepo](IContentTypeComposition[] contentTypes, Database db, TRepo contentTypeRepository, IDictionary`2 allParentContentTypeIds) at Umbraco.Core.Persistence.Repositories.ContentTypeRepository.PerformGet(Int32 id) at Umbraco.Core.Persistence.Repositories.RepositoryBase`2.Get(TId id) at Umbraco.Core.Services.ContentTypeService.GetContentType(Int32 id) at umbraco.cms.businesslogic.web.DocumentType.setupNode() at umbraco.controls.ContentTypeControlNew.LoadContentType(Int32 docTypeId) at umbraco.controls.ContentTypeControlNew.OnInit(EventArgs e) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.d__0.MoveNext()
To reproduce the error:
Content Type: T1 * Property: p1
Content Type: T2 * Property: p2
Add type T1 as a composition to T2
So far everything works properly
Now, if you add a new property named 'p2' to the content type T1 you get the error. You should get a user friendly message error saying that you cannot have two properties with the same name in a composition. So far it is not a big deal. The real problem here is that you can't modify any content type to undo the change. You need to fix it through the database!
@Alain "What do you think?" => your example makes sense... so when you rename the tab back to "SEO Fields" you want to keep the local "Data" tab. The child "Data" tab would not be renamed because it is a "local" tab that existed prior to being merged with the parent tab (when it got renamed to "Data"). Interesting ;-)
I have a suggestion regarding the fact that compositions are done through "Checkboxes". There is absolutely nothing wrong with it, but normally when users see a checkbox, they understand that it is something you can activate/deactivate, and that normally means that if they change the state of a checkbox, by returning this checkbox to its previous value any change will be undone. That is exactly what happens with "Allowed child node types" checkboxes (just above compositions). You can tick one checkbox and save, and if you change your mind and you untick the checkbox and save, you are back to the previous state. In the case of compositions, if you untick a composition checkbox, you are removing one or more properties of a document type, what means that you are deleting the data contained in these properties for all the nodes using this content type. And that could be a lot of data with only one untick! My point is (sorry for the long explanation) -> before saving the changes, a message box should be displayed letting users know that they could lose data and they need to confirm the action. This could save some tears ...
Hi Stephen,
I'm not sure if you are still working on Compositions... but came across this post while having my own issues with them.
My main concern is Ordering Tabs & Properties. I've found that when I add compositions to certain doctypes, the tabs and property order work as I'd expect, and inexplicably, on others it is inconsistent.
In my own experience, I have a Composition called "CompPageSettings" which includes two Tabs: "Page Settings" with an order number of 15 and another named "SEO & Meta" with order number of 90. On most of the Doctypes that use this composition, the "SEO & Meta" tab displays far to the right, but on one (Homepage) is it displaying as the second visible tab. This is in spite of the "Homepage" DocType including other compositions (with Tabs with lower order numbers) and three of its own "local" Tabs with order numbers of 1, 11, & 12. Changing the order numbers - on the local tabs, or on the Composition doesn't alter the order. Also strangely, the tabs are displaying in the proper order on the DocType's "Generic Properties" tab, but on the Content Node itself, they are displaying in a different order.
What I'd expect for Property Order:
I'd expect that Composition properties would be at the top of the Tab, and if DocTypes added their own "local" properties onto the same Tab, those would be displayed below the "inherited" properties.
My experience is once again, inconsistent. In most cases, it seems to behave this way, but in other cases, the Composition Property on a Tab is at the BOTTOM of the Tab. I have a Composition named "CompPageContent", which includes 1 Tab named "Content" and 1 Property on that tab named "PageHeadline". For any DocType I add this to, I then tend to add local properties to that "Content" tab. For many Doctypes, "PageHeadline" remains at the top of the Content tab. For a few, however, it is displaying below the local properties. Also, I can't seem to get it to "move" to the top of that Tab. I have tried shifting the local properties over to another tab, then saving the DocType, then moving them back and saving again, but it didn't change anything.
I'm unclear about how the order data is stored in the database, but it seems that it isn't getting consistently updated when individual elements change.
Also, if anyone know how I can "kick" these items into their proper places, I'd be glad of the info.
Regarding property order - I agree with you regarding what you'd expect, that the composition properties would be at the top of a tab and the other additional properties at the bottom, but I have to say that what I would like is to to be able to edit the order of properties so that non-composition properties could appear first if possible. I just like absolutely granular control ;)
@Janae - Perhaps what might work is if Compositions don't really have "Tabs" at all - if they just represent little groups of Properties, then instead of checking a box to include Composition Tabs on a DocType, you could actually add a Composition inside the Generic Properties Tab to whatever Tab and location you'd like - almost like its a property it itself...
@All - So, I managed to solve my initial problem with the following steps:
Backup Database
Run SQL like this:
UPDATE [dbo].[cmsPropertyTypeGroup]
SET [sortorder] = 90
WHERE [text] = 'SEO & Meta'
GO
This fixed some of the problems, but that Homepage was still misbehaving. Luckily, there is only 1 Homepage in the current install, so I copied the data out of the properties on the "SEO & Meta" tab to Notepad, removed the Composition from the Homepage DocType, then Saved.
Next, I noticed that on the "Tabs" area on the "Homepage" Doctype, there was now an "SEO & Meta" tab with sort order 2 displayed. Hmmm.... Interesting. It didn't have any properties, so I deleted it, Saved again, then re-added the Composition, saved again, and NOW it is displaying in the right location. Phew!
I noticed that regarding the "Content" Tab "PageHeadline" displaying at the bottom of the tab, I followed a similar process. First, I moved the "local" properties from the "Content" tab to "Generic Properties", removed the Content Composition, saved, deleted the "phantom" Content tab which appeared on the "Tabs" tab, saved, re-added the Content Composition, then moved the properties back to that Tab, Saved again.
My theory is that since the "Homepage" type was created early on in my development process. I likely had those Tabs originally on the "BasePage" (parent of "Homepage" - which now has no Tabs or Properties of its own). I decided to move them to separate Compositions, removing them from the BasePage. But perhaps when I removed them from BasePage, they were still "present" as inherited on the child "Homepage" doctype. When I then added the new Compositions to the Homepage, they were essentially "hiding" the original ones, but those original ones were being used for the Sort Order.
Seems the solution is that when Tabs are being removed from a DocType, the code needs to make sure it is removed from child DocTypes.
in seo control i put high number(200) so. whenever you composite seo control in pages. seo control will appear right most side(second last).
i set generic propety control to 201.by that whenever you composite this control. this will appear last. see image
you can not ordering in child page.you should reorder in control which you will going to composite
We need to talk about Compositions
Hey,
I am currently working on fixing document type compositions in v7. And I hit some questions that require... community input. Here goes the first one:
Assume I create
Of course... we all assume that when editing a content of type MyContent, we'll see one tab named Meta with two properties, MetaTitle and MetaKeywords. So far, so good.
Question: what-if I edit content type WithMetaTitle and change the tab's name to NewMeta? When I go and edit my content, what's the name of the tab (or is it tabs...)? Where is the Whatever property? What makes most sense from a user's point of view?
Cheers,
Stephan
From my perspective, MyContent would still include a composition (namely, WithMetaKeywords) that has a Meta tab, so the Whatever property could stay there (in the Meta tab).
Most logical to me sounds two tabs:
+1 Andy
@Andy, @Nicholas: so option 1 would be, do not rename an "inherited" tab as long as it still can inherit from a tab with its name. In our case, renaming WithMetaTitle.Meta to WithMetaTitle.NewMeta does not rename MyContent.Meta - but then if I rename WithMetaKeywords.Meta to WithMetaKeywords.DingDang, it would rename MyContent.Meta too. Makes sense and is consistent...
Derived question:
I would assume that MyContent2's tab name changes to SomethingElse too?
So it's all done by name - soon as tabs with same names are composed, we assume they are related.
Yes, that sounds sensible to me too. As you say, once you've made a decision to set up a composition, you've linked the two items, so - in the absence of another matching name as per your first question - renames should cascade down.
My brain goes straight into classical inheritance mode when I think about this.
If the properties on the base type are specified in a different tab to the inherited type then the inherited type should have two different tabs.
MyContent should have two resultant tabs.
Meta which contains the composite of inherited property MetaKeywords from base WithMetaKeywords and the instance property Whatever
NewMeta which contains the inherited property MetaTitle from the base WithMetaTitle
Anything else could lead to confusion and some messed up compositions.
I just wrote a long reply, but I realized that i dont actually know how the composition works exactly.
If I have the doctypes from the original post:
To start, I find the fact that you use Content Type interchangably with Document Type confusing. In the backed under Document Types there are many references to things like "This Content Type uses X as a Master Content Type." So I think that there should be a consensus to stick with a single terminology and not mix them up.
As for compositions, I think I understand the idea behind this but I'm not sure if I agree with the approach. It's almost like looking for a problem that isn't there or it's a solution for a different problem. I see compositions almost as a way of working with grouped or shared data types and avoiding having to have complex tree's of Document Types. The approach I would recommend would be the ability to create Document Type Elements which would be groups of data types that are created independant of a "Tab" name. This way you could great a "meta" group, that has elements like MetaTitle, MetaKeywords and you could add it to any tab of any Document Type. Changing a tab name wouldn't affect MetaTitle but changing MetaTitle (from maybe text to text multiline) would update all document types that use it.
I'm not sure if that makes sense or if I'm totally misunderstanding the purpose of Compositions. Either way I think it would be a handy feature.
Phill
"Derived question:
create root type MyContent1, tab MyTab, ppty MyProp1
create root type MyContent2, tab MyTab, ppty MyProp2
add type MyContent1 as a composition to MyContent2
rename MyContent1.MyTab to MyContent1.SomethingElse
I would assume that MyContent2's tab name changes to SomethingElse too?
So it's all done by name - soon as tabs with same names are composed, we assume they are related."
I would have two different tabs: MyTab and SomethingElse. If users want the same tab name, they have to rename explicitly MyContent2.MyTab to MyContent2.SomethingElse. And if at some point they decide to undo the composition, each tab would keep its original name, except if they have explicitly changed (renamed) it.
Another example could be:
Content Type: SEO
- Tab: SEOFields
* Property: Title
* Property: Description
Content Type: NEWS
- Tab: Data
* Property: NewsSummary
* Property: NewsContent
Content Type: BLOGPOST
- Tab: Data
* Property: BlogSummary
* Property: BlogContent
Add type SEO as a composition to NEWS
Add type SEO as a composition to BLOG
When creating contents for NEWS and BLOGPOST:
Content: Blog01
- Tab: Data
* Property: NewsSummary
* Property: NewsContent
- Tab: SEOFields
* Property: Title
* Property: Description
Content: BLOGPOST01
- Tab: Data
* Property: BlogSummary
* Property: BlogContent
- Tab: SEOFields
* Property: Title
* Property: Description
What happen if someone renames the tab "SEOFields" to "Data" for the content type SEO?
All properties would appear in one tab named "Data" for both NEWS and BLOGPOST, wouldn't they?
Content: Blog01
- Tab: Data
* Property: Title
* Property: Description
* Property: NewsSummary
* Property: NewsContent
Content: BLOGPOST01
- Tab: Data
* Property: Title
* Property: Description
* Property: BlogSummary
* Property: BlogContent
They realize that it was a mistake an rename back the tab "Data" to "SEOFields" for the content type SEO.
Properties should appear as initially, shouldn't they?
Content: Blog01
- Tab: Data
* Property: NewsSummary
* Property: NewsContent
- Tab: SEOFields
* Property: Title
* Property: Description
Content: BLOGPOST01
- Tab: Data
* Property: BlogSummary
* Property: BlogContent
- Tab: SEOFields
* Property: Title
* Property: Description
What do you think?
I got the following error In Umbraco 720 Beta 2 when there is a clash between property names in the composition:
Server error: Contact administrator, see log for full details.
Failed to retrieve data for child nodes undefined
LOG Error:
System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> Umbraco.Core.Exceptions.InvalidCompositionException: InvalidCompositionException - ContentType with alias 'T1' was added as a Compsition to ContentType with alias 'T2', but there was a conflict on the PropertyType alias 'p2'. PropertyTypes must have a unique alias across all Compositions in order to compose a valid ContentType Composition.
at Umbraco.Core.Models.ContentTypeCompositionBase.AddContentType(IContentTypeComposition contentType)
at Umbraco.Core.Persistence.Repositories.ContentTypeBaseRepository`1.ContentTypeQueryMapper.MapContentTypeChildren[TRepo](IContentTypeComposition[] contentTypes, Database db, TRepo contentTypeRepository, IDictionary`2 allParentContentTypeIds)
at Umbraco.Core.Persistence.Repositories.ContentTypeRepository.PerformGet(Int32 id)
at Umbraco.Core.Persistence.Repositories.RepositoryBase`2.Get(TId id)
at Umbraco.Core.Services.ContentTypeService.GetContentType(Int32 id)
at umbraco.cms.businesslogic.web.DocumentType.setupNode()
at umbraco.controls.ContentTypeControlNew.LoadContentType(Int32 docTypeId)
at umbraco.controls.ContentTypeControlNew.OnInit(EventArgs e)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.d__0.MoveNext()
To reproduce the error:
Content Type: T1
* Property: p1
Content Type: T2
* Property: p2
Add type T1 as a composition to T2
So far everything works properly
Now, if you add a new property named 'p2' to the content type T1 you get the error. You should get a user friendly message error saying that you cannot have two properties with the same name in a composition. So far it is not a big deal. The real problem here is that you can't modify any content type to undo the change. You need to fix it through the database!
Alain
@Alain "What do you think?" => your example makes sense... so when you rename the tab back to "SEO Fields" you want to keep the local "Data" tab. The child "Data" tab would not be renamed because it is a "local" tab that existed prior to being merged with the parent tab (when it got renamed to "Data"). Interesting ;-)
About the error: can reproduce, workingo n it.
Great! :)
I have a suggestion regarding the fact that compositions are done through "Checkboxes".
There is absolutely nothing wrong with it, but normally when users see a checkbox, they understand that it is something you can activate/deactivate, and that normally means that if they change the state of a checkbox, by returning this checkbox to its previous value any change will be undone. That is exactly what happens with "Allowed child node types" checkboxes (just above compositions). You can tick one checkbox and save, and if you change your mind and you untick the checkbox and save, you are back to the previous state.
In the case of compositions, if you untick a composition checkbox, you are removing one or more properties of a document type, what means that you are deleting the data contained in these properties for all the nodes using this content type. And that could be a lot of data with only one untick!
My point is (sorry for the long explanation) -> before saving the changes, a message box should be displayed letting users know that they could lose data and they need to confirm the action. This could save some tears ...
Hi Stephen, I'm not sure if you are still working on Compositions... but came across this post while having my own issues with them.
My main concern is Ordering Tabs & Properties. I've found that when I add compositions to certain doctypes, the tabs and property order work as I'd expect, and inexplicably, on others it is inconsistent.
What I'd expect for Tab Order:
Tabs can be explicitly set with a Sort Order number. If this is changed, it should apply to all doctypes the composition is on. As stated here: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/53729-tab-order-in-umbraco-711 sometimes this isn't the case.
In my own experience, I have a Composition called "CompPageSettings" which includes two Tabs: "Page Settings" with an order number of 15 and another named "SEO & Meta" with order number of 90. On most of the Doctypes that use this composition, the "SEO & Meta" tab displays far to the right, but on one (Homepage) is it displaying as the second visible tab. This is in spite of the "Homepage" DocType including other compositions (with Tabs with lower order numbers) and three of its own "local" Tabs with order numbers of 1, 11, & 12. Changing the order numbers - on the local tabs, or on the Composition doesn't alter the order. Also strangely, the tabs are displaying in the proper order on the DocType's "Generic Properties" tab, but on the Content Node itself, they are displaying in a different order.
What I'd expect for Property Order:
I'd expect that Composition properties would be at the top of the Tab, and if DocTypes added their own "local" properties onto the same Tab, those would be displayed below the "inherited" properties.
My experience is once again, inconsistent. In most cases, it seems to behave this way, but in other cases, the Composition Property on a Tab is at the BOTTOM of the Tab. I have a Composition named "CompPageContent", which includes 1 Tab named "Content" and 1 Property on that tab named "PageHeadline". For any DocType I add this to, I then tend to add local properties to that "Content" tab. For many Doctypes, "PageHeadline" remains at the top of the Content tab. For a few, however, it is displaying below the local properties. Also, I can't seem to get it to "move" to the top of that Tab. I have tried shifting the local properties over to another tab, then saving the DocType, then moving them back and saving again, but it didn't change anything.
I'm unclear about how the order data is stored in the database, but it seems that it isn't getting consistently updated when individual elements change.
Also, if anyone know how I can "kick" these items into their proper places, I'd be glad of the info.
Thanks ~Heather
@Heather,
Regarding property order - I agree with you regarding what you'd expect, that the composition properties would be at the top of a tab and the other additional properties at the bottom, but I have to say that what I would like is to to be able to edit the order of properties so that non-composition properties could appear first if possible. I just like absolutely granular control ;)
@Janae - Perhaps what might work is if Compositions don't really have "Tabs" at all - if they just represent little groups of Properties, then instead of checking a box to include Composition Tabs on a DocType, you could actually add a Composition inside the Generic Properties Tab to whatever Tab and location you'd like - almost like its a property it itself...
@All - So, I managed to solve my initial problem with the following steps:
Run SQL like this:
This fixed some of the problems, but that Homepage was still misbehaving. Luckily, there is only 1 Homepage in the current install, so I copied the data out of the properties on the "SEO & Meta" tab to Notepad, removed the Composition from the Homepage DocType, then Saved.
Next, I noticed that on the "Tabs" area on the "Homepage" Doctype, there was now an "SEO & Meta" tab with sort order 2 displayed. Hmmm.... Interesting. It didn't have any properties, so I deleted it, Saved again, then re-added the Composition, saved again, and NOW it is displaying in the right location. Phew!
My theory is that since the "Homepage" type was created early on in my development process. I likely had those Tabs originally on the "BasePage" (parent of "Homepage" - which now has no Tabs or Properties of its own). I decided to move them to separate Compositions, removing them from the BasePage. But perhaps when I removed them from BasePage, they were still "present" as inherited on the child "Homepage" doctype. When I then added the new Compositions to the Homepage, they were essentially "hiding" the original ones, but those original ones were being used for the Sort Order.
Seems the solution is that when Tabs are being removed from a DocType, the code needs to make sure it is removed from child DocTypes.
Most Relevant Related Bugs:
Other Related Bugs:
in seo control i put high number(200) so. whenever you composite seo control in pages. seo control will appear right most side(second last).
i set generic propety control to 201.by that whenever you composite this control. this will appear last. see image you can not ordering in child page.you should reorder in control which you will going to composite
is working on a reply...