Links on Sites do not work for pages that have parents

[pingfr]

Using refinery 1.0.3. I am building a site with multiple pages. The site has a home page and them pages that have the home page as a parent. Links to any pages that are siblings of the home page work fine. If I add pages that are children of the home page, the links just route back to the home page. The url/href for the child pages differs depending on how it is generaged. It may be /child-page or /home/child-page. In either case the link is broken and returns to the home page. This is also broken if I just enter the full route in the browser address bar. I am working in Internet Explorer 8. This looks more like an engine issue than a browser issue. No custom routes defined in the routes.rb.

This is pretty much a standard install of RefineryCMS. Some minimal page customization on _content_page, _footer, _header, _head, and _site_bar.

[parndt]

What about with version 1.0.9?

[pingfr]

Just installed 1.0.9 and it acts the same. However I learned some more as I have been looking at this. The request process is running through twice. The first time it is getting the page request. The second time it is getting a request for menu.css. I am not sure where this is coming from but is causing a record not found (Can't find page with ID=menu.css). I am not sure where the menu.css is getting injected into the process. It may be that error that is causing the problem.

[pingfr]

A little more info. On a hunch, I checked the public/stylesheets folder and there was no menu.css in the folder. I noticed that stubs of other css files was there so I added a blank menu.css. That took care of the missing menu.css error but didn't fix the problem with the links working (or not working as the case may be).

[pingfr]

I have a debug dump to add to this process. There are some interesting things happening here that I don't understand. The dump below is a trace when clicking a link that breaks. This would be a child link of the home page as described before.

Because page ID values and the like obviously change, here is the run down. The page that was requested has an ID of 6 in my local database. All slug types are valid for either a page or user. I am not that familar with the routing paths of Refinery CMS, but all looks pretty reasonable until you get to the section that I have marked below with ###### above and below the section. That section appears to go out to some kind of cache and grabs a query for the home page and proceeds to render the parts. Then after that I see the correct query for the page that I really want. It appears to execute but the rendering process never occurs.

My debug testing is on a 64 bit Windows 7 machine, however it appears that I get the same results on our Linux server. I just can poke at it as much because our customer is using it. I hope this is more helpful than my previous information.

Here is the trace:

Started GET "/home/test-page" for 127.0.0.1 at 2011-11-11 09:30:23 -0800 Processing by PagesController#show as HTML Parameters: {"path"=>"home/test-page", "locale"=>:en} SQL (2.0ms) describe roles_users User Load (1.0ms) SELECT users.* FROM users WHERE users.id = 1 LIMIT 1 SQL (1.0ms) SHOW TABLES SQL (1.0ms) SHOW TABLES Page Load (1.0ms) SELECT pages.id, pages.depth, pages.parent_id, pages.lft, pages.rgt, pages.link_url, pages.menu_match, page_translations.title as page_title FROM pages INNER JOIN page_translations ON page_translations.page_id = pages.id WHERE pages.draft = 0 AND pages.show_in_menu = 1 AND page_translations.locale = 'en' ORDER BY lft ASC Slug Load (0.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id IN (1,6,7,8,3) and slugs.sluggable_type = 'Page' AND (slugs.locale = 'en')) ORDER BY id DESC Slug Load (0.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id = 6 AND slugs.sluggable_type = 'Page') ORDER BY id DESC Slug Load (1.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id = 7 AND slugs.sluggable_type = 'Page') ORDER BY id DESC Slug Load (0.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id = 8 AND slugs.sluggable_type = 'Page') ORDER BY id DESC Slug Load (0.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id = 3 AND slugs.sluggable_type = 'Page') ORDER BY id DESC SQL (2.0ms) describe roles_users Role Load (0.0ms) SELECT roles.* FROM roles WHERE roles.title = 'Refinery' LIMIT 1 User Load (1.0ms) SELECT * FROM users INNER JOIN roles_users ON users.id = roles_users.user_id WHERE (roles_users.role_id = 1 ) SQL (0.0ms) SELECT sluggable_id FROM slugs WHERE ((slugs.sluggable_type = 'Page' AND slugs.name = 'test-page' AND slugs.sequence = 1)) Page Load (0.0ms) SELECT pages.* FROM pages WHERE pages.id = 6 LIMIT 1 PagePart Load (0.0ms) SELECT page_parts.* FROM page_parts WHERE (page_parts.page_id = 6) ORDER BY position ASC PagePart::Translation Load (0.0ms) SELECT page_part_translations.* FROM page_part_translations WHERE (page_part_translations.page_part_id = 11) Page Load (1.0ms) SELECT pages.* FROM pages WHERE pages.id = 1 LIMIT 1 PagePart Load (0.0ms) SELECT page_parts.* FROM page_parts WHERE (page_parts.page_id = 1) ORDER BY position ASC PagePart::Translation Load (1.0ms) SELECT page_part_translations.* FROM page_part_translations WHERE (page_part_translations.page_part_id = 2) Page::Translation Load (0.0ms) SELECT page_translations.* FROM page_translations WHERE (page_translations.page_id = 1) PagePart::Translation Load (0.0ms) SELECT page_part_translations.* FROM page_part_translations WHERE (page_part_translations.page_part_id = 1) Rendered shared/_content_page.html.erb (100.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_html_tag.html.erb (1.0ms) Role Load (0.0ms) SELECT * FROM roles INNER JOIN roles_users ON roles.id = roles_users.role_id WHERE (roles_users.user_id = 1 ) Rendered shared/_site_bar.html.erb (11.0ms) Page::Translation Load (0.0ms) SELECT page_translations.* FROM page_translations WHERE page_translations.locale = 'en' AND (page_translations.page_id = 6) LIMIT 1 SeoMetum Load (0.0ms) SELECT seo_meta.* FROM seo_meta WHERE seo_meta.seo_meta_type = 'Page::Translation' AND seo_meta.seo_meta_id = 6 LIMIT 1 Page::Translation Load (1.0ms) SELECT page_translations.* FROM page_translations WHERE (page_translations.page_id = 6)

###################################################################### CACHE (0.0ms) SELECT pages.* FROM pages WHERE pages.id = 1 LIMIT 1 CACHE (0.0ms) SELECT page_translations.* FROM page_translations WHERE (page_translations.page_id = 1) Rendered shared/_head.html.erb (30.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_ie6check.html.erb (1.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_menu_branch.html.erb (6.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_menu_branch.html.erb (31.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_menu.html.erb (51.0ms) Rendered shared/_header.html.erb (71.0ms) Rendered shared/_footer.html.erb (0.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-core-1.0.9/app/views/shared/_javascripts.html.erb (1.0ms) Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/refinerycms-pages-1.0.9/app/views/pages/show.html.erb within layouts/application (292.0ms) ######################################################################## CACHE (0.0ms) SELECT slugs.* FROM slugs WHERE (slugs.sluggable_id = 6 AND slugs.sluggable_type = 'Page') ORDER BY id DESC Completed 200 OK in 673ms (Views: 331.0ms | ActiveRecord: 13.0ms)

[pingfr]

One last observation on this for now. If I click on a link that is a sibling for the home page, I do not get the cached queries for the home page. For example, if I have an about page that is a sibling (not parented by any other page), the run looks like above except the

CACHE (0.0ms) SELECT pages.* FROM pages WHERE pages.id = 1 LIMIT 1 CACHE (0.0ms) SELECT page_translations.* FROM page_translations WHERE (page_translations.page_id = 1)

does not occur. So it appears that something is causing this to happen only if the link is heading for a child page. In the case of top level pages, the last query you see is the correct set of queries for the desied page.

[pingfr]

OK. I hope you didn't spend much time on this. I finally found it and the issue was in a small bit of customization in our _content_page.html.erb. There was some code that changed the global @page value just prior to rendering the link. That was causing the page to render incorrectly. The code was taking a look at the parents of pages and messing with the global value and not using it's own safe value.

Thank you for looking into this. I hate taking other peoples time on stuff that ends up coming back to our code.