Make Page Title show proper titles for Panels -- requires Token cache fix

AFAIK It should work with Panels (I assume Panels 2?)... I'll have to investigate.

Yes, I meant Panels 2.

It's not yet working?

I was also experiencing this error. After enabling Page Title, I found that all my panel page titles were of the form "Home | [Site Name]".

I discovered that this was because page_title_preprocess_page() was calling page_title_page_get_title() on every page, and that function doesn't seem to work properly when arg(0) !== 'node'.

Attached is a one-liner patch that resolves the issue by limiting page_title_preprocess_page() to operate when arg(0) == 'node'. I think this is a good solution, for now at least, since Page Title doesn't seem currently to include patterns for anything besides node pages.

Has anyone had a chance to review this patch? I see that there's a 2.2 version of the module now and it still hasn't been reviewed on here or committed. I will test after I upgrade my site to 2.2 & see whether the patch is still necessary. If so, I will report back here & bump the version number on this issue.

Hi Evan!
The issue still appears in the current 2.x-dev version. I can, however, confirm that the above patch works correctly in that version.
Thanks!
-Brian

I just upgraded my page_title.module & I can confirm that the patch still applies and works in Page Title 2.2. So, unless there's any objections to this approach, can this be committed to the module?

The problem with that patch is that page_title supports other things like blogs, users, etc.

Here is a patch for the way I solved panels compatibility, which I think shouldn't remove any of the functionality from other page types.

This should be applied to page_title.module.

Nick

Thanks for the patch! I'll test it soon - changing status to "needs review" accordingly. I only used Page Title for nodes, but I can understand now why my patch wouldn't be sufficient for everyone.

I forgot to change version to 2.2, which is what I'm using. Or was this patch against the -dev?

Sorry to comment again, I realized that the new patch changes the scope of the issue slightly, so I should rename it (since it's not limiting page_title_preprocess_page to nodes).

I just want to add that I use Page title as well and realized that my panel pages show no titles any more. I used to define the titles by drupal_set_title and even in this way the titles are not defined as long as page title is installed.

Page Title IS compatible with Panels (atleast for 3.x version of Panels it is 100% compatible). There is just one bug preventing it to work. See #529186: Usage of global token breaks default page titles because of early Token caching.
This issue' title doesn't make any sense.

Please refrain from making issue titles completely meaningless. For many of us, Page Title was *not* compatible with Panels because it overrode the titles of pages with nonsense (i.e., "Home"). You could have called attention to your fix - which I will test - without changing the title.

If your fix fixes this issue, as well as others, then I will mark this one as duplicate. But my patch in #3, and the later versions, worked for a particular case.

Sorry, I didn't mean to affend you. It works for me, and I don't have any issues. Page Title should not be made "compatible", cause it has "default title" concept, and it should fallback to default if there is no specific replacement rule. Actually it's probably same way for any titles set up by other modules, e.g. Views pages titles should work same way. The only problem is this concept doesn't work because of the token cache bug. With the workaround for this bug, Page Title simply uses what Panels (or any other module) sets up. Making specific "compatible" patches doesn't make sense when there's general mechanics for all modules to set title that should just work, but doesn't because of a bug.

Ok, thanks for the clarification. I'm just saying you could have said that to begin with, rather than trying to make a point with your change to the title. You make a good case; I just wasn't aware of the root cause of the bug.

I decided not to switch to using your workaround because of the performance implications. I'll wait until a better solution can be found. I've updated issue title accordingly.