::slaps forehead:: Me read good. Me read really good. Sorry, Benny, no 
excuse for that. Thanks for dinging me back. I deserved that.

We are using Share Layouts, and that's where the problem turned out to be. 

For posterity: The RailsPage that gathers the info from the pages is 
defined by Share Layouts. Specifically, within its radiant_layout method, 
if it can't find a page by URL, it creates a RailsPage object and assigns 
some parameters to it so that the layout has the information it needs (like 
title, url, slug, etc.) 

After I dug into this a little more, what I discovered was that, 
previously, we were setting some values (description and keywords) via an 
aliased method chain on the Shared Layouts assign_attributes method. But 
description is - in Radiant 1.* - a method of its own, so whenever 
description was called later as part of the meta tag, it didn't retrieve 
the value we tried to set, but instead (as the method for description is 
defined to do) it went to the PageFields to find a value there - a value 
that obviously didn't exist for this generic RadiantPage.

Mystery solved! Thank you for your help!

Eric

On Wednesday, October 10, 2012 10:14:35 AM UTC-4, Benny Degezelle wrote:
>
> Hi Ethan (you started it),
>
> So, in your controller, you find a page and finally call page.render, 
> or..? If it's done that way, tag.locals.page should start off as that page. 
> tag.locals.page may and probably will change during the rendering, but 
> tag.globals.page should always be the actual page that is being rendered.
>
> I assume you are using 
> radiant-share-layouts-extension<https://github.com/radiant/radiant-share-layouts-extension>or
>  
> radiant-layouts-extension<https://github.com/squaretalent/radiant-layouts-extension>?
> I have a gut feeling that looking at 
> https://github.com/squaretalent/radiant-layouts-extension/blob/master/app/models/rails_page.rb#L6-22
> If you would rename those to use 'path' i.o. 'url' (and ideally alias the 
> url methods to the path ones), your problem might be fixed.
>
> If not, it would help to have some actual code to look at.
>
> Cheers,
> Benny
>
> Op dinsdag 9 oktober 2012 15:52:21 UTC+2 schreef saalon het volgende:
>>
>> Brian,
>>
>> Thank you for the response. The extension is loading last, thank you for 
>> verifying that. And I did move all of the routes to config/routes.rb.
>>
>> The routes themselves are actually working correctly, and the rest of the 
>> page is fine. The only thing (so far) that's off is the page the radius 
>> tags are receiving as the context in tag.globals/locals.page.
>>
>> The curious thing is that we never did anything to set that context 
>> previously. It had just worked. I'm  not certain how this used to work - if 
>> doing a find on a page simply set that page as the context - and if that's 
>> still how it's expected to work but isn't, or if something changed. Any 
>> idea how a page ends up in tag.globals.page?
>>
>> Eric
>>
>> On Tuesday, October 9, 2012 9:33:49 AM UTC-4, Benny Degezelle wrote:
>>>
>>> Hi Eric,
>>>
>>> Somewhat stabbing in the dark here, but my first guess would be this is 
>>> a load order issue.
>>> At some point after 0.8, the default extension load order was reversed.
>>> Open config/environment.rb, you should find 'config.extensions = [..]' 
>>> in there. Try setting your custom extension last in there.
>>>
>>> Also, in your custom extension, are your routes defined in 
>>> config/routes.rb yet? 
>>>
>>> Op maandag 8 oktober 2012 20:36:23 UTC+2 schreef saalon het volgende:
>>>>
>>>> Hey, all!
>>>>
>>>> I'm having a tricky problem since our upgrade from Radiant .8 to 1.* 
>>>> that is particular to the extension we built, I'm certain, but I'm hoping 
>>>> someone cna provide some context about the best direction to go.
>>>>
>>>> One of the things our extension does is define some routes for one of 
>>>> our custom page types. We don't want to have Radiant render the page 
>>>> because we do a lot of very custom stuff in the layout, but we use the 
>>>> page 
>>>> for all the data. So, essentially, someone goes to /production/32178 and 
>>>> we 
>>>> do a find_by_slug for that page and use it in the view.
>>>>
>>>> The problem: We'd been using the now deprecated r:meta:keyword and 
>>>> r:meta:description tags in the layout to set the meta description and 
>>>> keywords. When they stopped working, I looked into it expecting it to be 
>>>> part of the deprecation, but something else is going on. Essentially, the 
>>>> page that the tag has in its context in tag.globals and tag.locals is not 
>>>> the ProductionPage we're using, but a RailsPage. It appears that 
>>>> previously, whatever was happening previously resulted in setting the 
>>>> ProductionPage we did the find_by_slug on in the controller as the 
>>>> tag.globals.page. Now that's no longer happening.
>>>>
>>>> Is there a way to override within our controller what ends up in the 
>>>> tag.globals.page (or tag.locals.page) variable? I tried setting a @page 
>>>> instance variable as a test, but that did nothing. Any insights into how 
>>>> to 
>>>> proceed would be appreciated.
>>>>
>>>> Eric
>>>>
>>>

Reply via email to