This patch allows the user to let certain pages use different title patterns based on their paths.

Keep in mind, this is the actual browser path (i.e. $_SERVER['REQUEST_URL'] not $_GET['q']).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nicholasThompson’s picture

I like this idea a lot - would allow for control of non-node pages quite nicely.

I'm not sure about the implementation though - it's fine for able-minded people such as you and I, however I'm not sure your Standard Issue blogger would be able to configure that sensibly...

nicholasThompson’s picture

Version: 5.x-1.1 » 5.x-2.x-dev
Component: Code » User interface
Assigned: Unassigned » nicholasThompson

This would make a nice addition to the 2.x branch (the 1.x branch is frozen now).

nicholasThompson’s picture

Status: Active » Postponed

This is still a feature I'd like to implement... I'm thinking some kind of "URL Pattern : Token Pattern" system where People can add things like "forum/%" and map it to a token pattern. This would solve, or at least be a simple work-around, for implementing integration with Views.

I am, however, going to mark it as Postponed simply so we can get Page Title 2 out for final release and port it to Drupal 6.

nicholasThompson’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev
Status: Postponed » Needs review
FileSize
8.31 KB

I get bored easily... This is something I'd do in Drupal 6 first...

What does this do? It adds a new configuration tab... That tab allows you to add, delete and edit new path pattern "things". These are path:pattern:scope sets. The scope defines what object gets passed to tokens.

I've just tested this out against the current DRUPAL-6--2 release and I can actually control the page title template of taxonomy/term/* pages and user/* pages. I think this is a small victory!

The problem now is how to make it "aware" of the context... Its all very good saying "this is a user page", but the URL might not necessary be "user/*" and its not safe to assume the UID is always in arg(1)....

I feel the answer may in fact lie with menu_get_item() and menu_get_object()....

Any thoughts?

Murz’s picture

subscribe

Poieo’s picture

This would solve the problem with Views and Panels. Why did it die here? Is there another method for altering the page titles of Panels and Views?

richygecko’s picture

I agree with Poieo. This is exactly what i need. With so many pages made from views and panels the page title module really only affects the stuff that I'm least interested in changing. would be great to get focus on the main views and panel pages as they are the core landing pages for my current project.

I know the nodewords module has the ability to override by path and use tokens. Any chance that might provide some direction.?

nicholasThompson’s picture

Priority: Normal » Critical

Overriding by path seems a popular feature request so I'll take a look...

Thing is, it won't solve "the views problem". The issue is scope. For a generic view (like "archive", for example) which has no arguements there is no problem. The issue is when you start adding arguments such as term id (for taxonomy page), user id (for author listing pages) and so on. How does Page title know (a) where ther argument sits and (b) what scope is it (c) what kind of argument is it (eg, term name or term id?).

I will add path page titles, but it won't solve everything. More work needed :)

Brian294’s picture

I just published a 6.x module that marries the best features of page_title and nodewords. Wildcard paths and tokens supported. Great for tough-to-reach page titles in Views, Panels, and other non-node paths!

http://drupal.org/project/nodewords_pagetitle

Peace,
Brian

nicholasThompson’s picture

I've just seen the module you did - will have to give it a test run.

Question... How are you handling context of arguments? Eg... a path such as Test/1/2/3... What is each arg? Node ID, Term ID, User ID, Just a number?

The main reason I've been holding off on the simple static path matching is that I wanted to do it "properly" with context matching rather than a half-feature release...

Brian294’s picture

I leave the arguments up to nodewords. :-) I rely on their logic to determine a path match.

DamienMcKenna’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

The D6 branch is no longer supported so no new features will be added.