-
1. Re: Admin updates to CMS portlet decorations don't take affe
theute Jul 22, 2007 3:59 AM (in response to thorntond)Use the CMS content-type when you add a window
-
2. Re: Admin updates to CMS portlet decorations don't take affe
thorntond Jul 22, 2007 5:56 PM (in response to thorntond)I added a CMS portlet as user admin with the content-type set to CMS. Most of the time it sets the CMS Portlet content correctly but sometimes it does not. I haven't spent any time trying to figure out why it sometimes won't set properly.
Updating the CMS Portlet rendering properties in the Management Portlet is having no affect on the rendering of the CMS Portlet.
Danny -
3. Re: Admin updates to CMS portlet decorations don't take affe
theute Jul 23, 2007 2:31 AM (in response to thorntond)I will have a look at the decorations issue. Thanks.
-
4. Re: Admin updates to CMS portlet decorations don't take affe
theute Jul 23, 2007 6:55 AM (in response to thorntond)Can you try to set "DecorateContent" to true on the portal:service=ContentRenderer,type=cms Mbean declared in:
portal-cms.sar/META-INF/jboss-service.xml
It should behave as you expect (note that you can still decide to hide decorations for a particular windows using the windows properties) -
5. Re: Admin updates to CMS portlet decorations don't take affe
thorntond Jul 23, 2007 2:55 PM (in response to thorntond)With the DecorateContent set to true, the CMS Portlet window does render with decorations.
-
6. Re: Admin updates to CMS portlet decorations don't take affe
theute Jul 23, 2007 3:21 PM (in response to thorntond)This is what you wanted ?
-
7. Re: Admin updates to CMS portlet decorations don't take affe
thorntond Jul 23, 2007 5:36 PM (in response to thorntond)This is the way I would like the CMS Portlet to render. Thanks Thomas. However, I think it is a bug in Portal 2.6 if setting the rendering type in the management portlet has no affect.
-
8. Re: Admin updates to CMS portlet decorations don't take affe
theute Jul 23, 2007 5:43 PM (in response to thorntond)Yep this is misleading. I wasn't aware of this new behavior.
Fortunately this can be worked-around easily.
We'll clean that up in a future release, thanks for reporting this.