Hi all. I've searched for an answer to this q, digested the results and now need some advice.

I've got three node types: country; article; place. Articles and places are related to country via a CCK node reference field. I want to deliver a series of pages showing details of the country, with tabs for related articles and places plus customised pages to view individual article and places.

I've managed to do this and (after pulling out my hair) even got the tabs working by using panel pages, with a page list as follows:

/country/%node/overview - country overview tab (default menu tab)
/country/%node/articles - shows a list of article
/country/%node/places - shows a list of places
/article/%node - single article
/place/%node - single place

(FYI, I'm ruling out overriding the system node/%node path. I've created specific pages to display nodes based on the URL (i.e. /article/%node, /place/%node etc) and I'm happy with this as I believe it will be more manageable for future development.)

Perfect! However, the old chestnut of URL aliasing has reared it's head. For the benefit of SEO, I want to use some kind of alias instead of the node id. Ideally, I'd like the alias to be auto generated from the node title, much like the functionality of pathauto. (I can't use pathauto directly on my country node as that creates a single alias for the /node/%node page - I need an alias for overview, articles and places. Also I don't want to use the /node/%node path in Panels)

My thinking at the moment is to dive under the hood and develop a custom module and ctools plugin. The module will create a unique string alias for a node (on create/update) based on it's title (a la pathauto) and store it in it's own db table. The ctools plugin will be an argument plugin that will resolve a given alias into a node (by selecting against the table). I'm thinking of using a table to ensure uniqueness, rather than just creating a function to consistently encode titles into aliases (it IS conceivable to have nodes with duplicate titles in this project). It sounds like Jerad had a similar challenge with Music Box - http://drupal.org/node/241344

Before I roll my sleeves up and start coding, am I missing anything? Perhaps a magic module that's lost in Durpal-land?

Jimbo.

PS - the documentation for panels is bloody scarce! But I'm sure you know that already. Is anyone heading up documentation who I can chat to - I'm more than happy to volunteer some time to help. Even FAQs / useful posts would be a great starter…

Comments

merlinofchaos’s picture

Yes. You are spot on, and this is something I think would be absolutely fantastic. I would be willing to ship it with CTools, probably, though it should probably be its own module inside the project since it creates new data that users might not actually need.

If you pop onto IRC you can chat with me about Panels documentation. I'm usually willing to discuss it with people who want to contribute. Right now it's been difficult to get anything going in terms of documentation. I think the idea of documenting Panels is big enough that most people don't really know where to even start. I've created a bunch of advanced help stub pages for Page Manager and put that out there hoping that people would contribute, but so far no one has contributed anything.

I think the thing we really need right now is a good, well-written and concise 'getting started' document that describes what the major pieces are and how you might set them up. That data *is* out there but it's pretty scattered. Worse, Panels has been through at least four major revisions in its lifetime, and each one has completely changed the UI so older documentation is more or less useless. now.

merlinofchaos’s picture

CTools includes a cleanstring tool that will help generate the alias, btw.

It would be nice if the tool were written generically enough to be expandable so that it can be applied easily to users taxonomy terms and other data as well.

jimbojingers’s picture

Cheers Earl (or is it just Wizard?), thanks for the comments. A few q's:

Glad alias approach is the right way. It appears straight forward to both create the token at node/term/widget CUD and also to re-create said object as a context via a new set of arguments. So far so good. However I think the Crux of making this usable will be how accessible these readable, alias-ised URLs will be to the end user/themer, etc.

For example, in the above case I could create a link to the country overview in my templates with "/country/".whizzy_get_alias_function(mynodeid)."/overview", but it would be much nicer if I could do it with whizzy_get_url('country_overview', mynodeid), which would know about the country_overview panel page, know what aliases it expects in the URL, replace them and output the URL. I guess ultimately it would be wonderful if this could be rolled into the UI of views when creating a field based view - so instead of just 'link the title to the node page' it could be 'link this field to this panel page', and the magic below would churn out a correctly formatted URL. Again, would you mind sanity checking this approach, plus any pointers would be most welcome.

As for the documentation, agreed that a getting started doc would be extremely useful. I'm embarking on my first project to use panels as a significant part of the solution and the curve is steep, hopefully once I've emerged from t'other side I should be in a good place to write something up.

James

merlinofchaos’s picture

Title: (another) Question about aliasing, advice and best practice needed » Create a tool to help provide aliases for nodes.
Category: support » feature
Summit’s picture

Subscribing, interested in the alias tool progressing from James.
greetings, Martijn

japerry’s picture

Status: Active » Closed (won't fix)

Not happening in D6 Panels. There are probably better tools for this.