In XP7.7 we got the new allow-filter for parts. It is very nice. However, when starting to use it we experienced a few things that we didn’t expect, and that was a bit surprising at first leading is to research our code for bugs.
If you add an “allow”-rule for any specific content type, as was our need, it will effectively not be allowed on page templates or the portal:site content. That was unexpected even if we figured it out after a while. The docs should have a note on this as I think many will go through the same process as us here.
If a part is already on a page of the wrong type of content (as might be the case since this is a new feature) you will not get information about this in Content Studio. What you will get is a empty form, and no name of the part to the right. This led us first to research if our form was broken, or if there was any other bugs. After a while we discovered that we were on a disallowed content type. So, putting a tiny message into Content Studio on the right side would help a lot - “Part Xxx is not allowed on Content Type xxx and cannot be edited”.
Are you sure you pointed to the right docs, Bobby? <allow-child-content-type> for content types doesn’t work the way you described.
But you probably meant <allow-on-content-type> config for parts/layouts from here? Then you are right, site and page template are content types as well and have to be added to allowed content types config of a part/layout. We have now added a note to the docs.
If a part is already on a page of the wrong type of content (as might be the case since this is a new feature) you will not get information about this in Content Studio. What you will get is a empty form, and no name of the part to the right. This led us first to research if our form was broken, or if there was any other bugs. After a while we discovered that we were on a disallowed content type. So, putting a tiny message into Content Studio on the right side would help a lot - “Part Xxx is not allowed on Content Type xxx and cannot be edited”.
This is definitely a bug, registered it here. Should land in 3.3.2 in a couple of weeks.
Fantastic Alan, even though I pasted the wrong link you understood correctly. Yeah it was the <allow-child-content-type> that gave us this problem. Glad you fixed the docs and also improving CS in next release. Couldn’t be more satisfied!
