[opencms-dev] Having fun with detail pages...

[Claus Priisholm]

Hi Georg

Thanks for the feedback, I've been digging a bit further...

(1) You say "configured the /.content/v8news folder for multiple resources,
not just news..."

This makes me wonder how to configure it in the first place. To begin with
I did not consider anything related to that folder (I think ADE created it
for me when dropping the first news onto a page). Then I realised the
flower-example has the folder set to "v8newsgallery" so I changed it to
that, but it did not make a difference. Clearly this is not the
configuration you are refer to, as the folder - of course - can only be of
one type at the time, so it seems to suggest that there is some other
configuration I am missing out on.

After much debugging I can see that
CmsConfigurationCache.initializeFolderTypes() gets called a couple of times
the first time this link handling is invoked. Seems that it does not find
any CmsADEConfigData that attributes to the list of folder types, but it do
consult "module configuration" which among other things defines v8news
along with a folder called "news".

AFAIK the only place this can come from is the module_config file in the
v8news module.

As far as keeping track of which of the many config files that matters, and
when I'm a somewhat in the dark...
The default name of the .content/news folders seems to be "v8news", and the
name pattern seems to "v8news-%(number).html" - this is different from the
corresponding values in the v8news module config (which defines "news" and
"n_%(number).html"), and yet when doing the "detail page link" magic it
then uses "news" rather than "v8news".

I have not (knowingly) set the "v8news" and "v8news-%(number).html"
anywhere so I am wondering where they come from. My .content/.config
"Disables all" and then sets the types I need (mostly the default  v8 ones)
along with custom formatters. I do not set the folder name per resource
type as I don't really have an opinion as to what these content fragments
gets labeled, so I'm fine with the type name.

Seemingly this is not sufficient, so based on my debugging, the solution so
far is to set the name in the /.content/.config for the folder to "news" so
it matches whatever it finds in the configuration. Then the detail page
links works and new news articles ends up in that folder.

Brs
Claus


2012/11/12 Georg Westenberger <g.westenberger at alkacon.com>

> Hello Claus,
>
> I can think of two possible explanations for the problem:
>
> 1 - You have accidentally configured the .content/v8news folder for
> multiple resource types, not just news.
> It is not possible in ADE to configure the same folder for multiple
> content types. If you do it, the link generation for detail pages will get
> broken.
>
> 2 - The page displaying the v8list element  is not located in the
> sub-sitemap in which you have configured the detail page for the type
> v8news.
> Detail page link generation depends on the path of the page on which the
> links are going to be rendered. Detail pages will only be looked up
> for the sub-sitemap which that path is in, and its ancestors. This is so
> that you can have different detail pages for a type in different
> sub-sitemaps.
>
> The methods getAllDetailPages and isDetailPage don't take the current page
> into account, they are used for different purposes, not for link generation.
>
> Kind Regards,
>
> Georg
>
> --
> Georg Westenberger
>
> Alkacon Software GmbH  - The OpenCms Experts
> http://www.alkacon.com - http://www.opencms.org
> ______________________________**_________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/cgi-**bin/mailman/listinfo/opencms-**dev<http://lists.opencms.org/cgi-bin/mailman/listinfo/opencms-dev>
>
>
>
>


-- 
Claus Priisholm
+45 48 22 46 46
cpr (you know what) codedroids.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20121118/da0cde0e/attachment.htm>