ID-based slug instead of title

[woop]

Hi! I've been looking for a way to change the way slugs are build when saved. 

I've created a form to post new pages using the api which works great, but I'm not pleased with the path generated.

The path is automatically generated from the title of the page, but I'd rather use the ID instead (similar to youtube's video ids) since my posts are primarily video based and doesn't contain much text.

Current path: 

example.com/video/an-uninteresting-title-that-is-automatically-generated

What I neeed:

example.com/video/5432

So, I don't need to change the parent - just the slug.

Any suggestions? (I'm not too good with PHP)!

Thanks!

[apeisa]

since you are using api already, try this right after your save:

$p->name = $p->id;

$p->save();

[woop]

thanks! that did it. I tried to manipulate $p->path but with no luck. completely missed $p->name. never crossed my mind to look there. I guess $p->title is used to populate $p->name which is used to create $p->path? Am I getting it right?

[Martijn Geerts]

yep.

So name is always unique in a parent to.

[adrian]

This might also be of some interest. I will probably be implementing diogo's suggestions shortly, but hoping for some other feedback as well:

http://processwire.com/talk/topic/4611-redirect-id-based-urls/

[matjazp]

How to make PW use IDs instead of slugs in general, like all pages? Or just on some pages (user choice)?

[adrian]

The linked module above will let you do that:

http://modules.processwire.com/modules/process-redirect-ids/

Works for either all pages, or specific templates/pages that you select.

[matjazp]

Thx, Adrian, but this will not work when using $page->children->render() or renderPager() (and a lot of others I assume) since they use page->url to generate the markup instead page->id ...

[adrian]

I guess I don't really know exactly what you want. That module will allow you to link to any page using its ID. Are you want to have internal links in an RTE field be ID based? If that's what you want you could create a simple text formatter module to change the links.

Sorry, I am probably missing your point still. Could you explain your scenario in a little more detail. I am sure there is a way to achieve what you are looking for.

[matjazp]

I would like that all PW modules/function/methods be aware of possibility to use IDs instead of urls.

Let say I have page with title Test (url=test, id=1000) and two children: Foo (url=foo, id=1001) and Bar (url=bar, id=1002). echo $page->children->render(); produces something like:

<ul>
  <li><a href="/foo/">Foo</a></li>
  <li><a href="/bar/">Bar</a></li>
</ul>

 

What I would like is that echo $page->children->render(); creates this:

<ul>
  <li><a href="/1001/">Foo</a></li>
  <li><a href="/1002/">Bar</a></li>
</ul>

Your module just add an option to use ID on specific templates/pages (and that is great) but I have to write my own method/function to display ID's, because render() will always echo page url and not page ID. I hope I made myself clear (English is not my native language).

[adrian]

Actually thanks to the genius of WillyC, that is pretty easy. Well I guess it's really Ryan's genius, but Willy's post has been a classic for quite some time!

$pages->addHookAfter('Page::path', null, 'hookPagePath');
function hookPagePath(HookEvent $e) {
  $page = $e->object;
  $e->return = "/$page->id/";
}

That will rewrite all your links, but you'll still need my module to make the links actually work.

I am actually thinking this code might be a nice optional addition to my module.

Of course you can put a conditional "if" to only return the id for particular templates or whatever if you need.

EDIT: There actually appears to be a conflict between the two - stay tuned - I'll take another look at this tomorrow

Edited May 18, 2014 by adrian

[matjazp]

Thx for the link. If you know where and when to hook ... Yes, this would be very nice addition to your module. And yes, that would apply only to specific (selected) pages/templates (or all if none is selected). Maybe this settings should be in the page and template instead in the module. 

I also found a small bug: if you run PW in subdirectory, then example links in "ShortLinks" are not correct (subdir is missing).

[Pete]

Why would you want to use IDs instead of human readable (and memorable) URLs? I don't understand why that would be desirable. If you are worried about page URLs changing then there's a module you can use to take care of that.

The subdirectory thing isn't a bug, your URLs in your example start with a / so this will always go to the root folder. You can add this in place of that first / to resolve that.

<?php echo $config->urls->root; ? >

[adrian]

I also found a small bug: if you run PW in subdirectory, then example links in "ShortLinks" are not correct (subdir is missing).

Thanks for the report - I have fixed this bug and pushed it to Github. Let me know if it works for you now.

I agree with Pete about not generally wanting to have links go to ID based URLs though. My module is just meant to be an easy way to provide a shorter link, or perhaps a human readable link with the ID appended, like: http://www.mysite.com/article/this-is-the-full-title-1058/

[cstevensjr]

I believe ID base urls have very good uses though they may not be suitable for most projects.  I do have a few projects where being able to access the unique Page ID is beneficial. Why should we have to create a new unique identifier when ProcessWire already has a built-in one?

The great thing about ProcessWire is that there are a multitude of solutions available.  You are not forced to work in a particular or limited way.

[matjazp]

@Pete: for me it is much easier to remember the number eg. 1058 than some-very-long-fancy-url.

@Adrian: fix for PW subdirectory is ok. Let me know if you modify your module to support id based render methods.

[adrian]

@Adrian: fix for PW subdirectory is ok. Let me know if you modify your module to support id based render methods.

Well I have a version for you to test. It has a new option called: Rewrite Links and a companion "Rewrite Format" in the config settings. This way you can determine how the urls will be rewritten. I have tested with:

/{$page->name}-{$page->id}/

and

/{$page->id}/

I attached this version here as I don't want to push it to Github yet. It mostly seems to be working fine, but there is a problem when loading the default PW sitemap page. The recursive function for generating the page links is causing some major problems, so please don't try that.

Let me know if you think this approach meets your needs though and I'll figure out how to fix the bug and maybe consider a more efficient way to do things - I never planned this module to have this functionality, so there might be a better approach.

EDIT: Please keep in mind that I mostly agree with Pete - long friendly URLS are a much better default. I think the name-id combo isn't a bad idea because it creates a permanent link even if the page name changes, but the id on its own seems like a bad idea for a default URL. The module's original goal was just to allow for shortlink alternatives, but not replacing the default link.

[adrian]

Turns out the issue with the site map page is not due to the rewriting of links and is actually an issue if you try to render that page from another page, completely independent of this module. I am using render() when the "Load" option is selected, hence the problem. I will still see if I can find a way around this, but for the moment I have set the load option to ignore the site-map page (instead, it defaults to redirect).

I have pushed this latest version with the custom URL rewrite option to Github and updated the modules directory.

Let me know how it goes for you.

[matjazp]

Yes, that's what I was looking for, /{$page->id}/ is ok for me (didn't try site map)! Great job, thank you. Suggestion: if I choose to rewrite all links, then enabled templates/pages are probably irrelevant. 

[adrian]

Thanks for the report. I have pushed another update that makes the automatic link rewriting honor the template/page restrictions. I think this is beneficial as I can see users wanting to have all functions of this module's only applied to a specific section of their site - maybe a blog or news articles section or the like.