Pages URLs Problem

[esquire]

I raised this issue earlier, way back with IP.Content and I don't know what to do about it now in IPS 4 - URLs MUST include any category / subcategory structure.  I have unfortunately wasted a very large amount of time putting up a test site and concluding I'm stuck and can't figure out a better way. Open to suggestions and hopefully some option to avoid requiring taxonomy in the URL. 

All CMSes I've used could create URLs independentl of the taxonomy - meaning creating categories and structure was completely independent of URL generation.n typical CMS you can have the options of postnumber-post-topic format and that's all.  1234-post-topic-here. I'm about to launch a new site and want to use IPS 4. Problem I'm having is that the article portion may change significantly over time. I'm dealing with a massively large and complex subject even though it's just one entity that I'm dealing with, e.g. a music site, a large city, state, etc. So what I think is an easier organization will get completely messed up as time goes along. For example, if I create a categories like this for a city site:

tourist >

Transportation >

And then I realize that what was just a handful of articles must become this:

tourist > neighborhoodhere >

Transportation > bus (or train, light rail, car, taxi, etc.)

Any subcategory I am adding to better categorize my content requires another URL change. This has had me seriously rethink how I will use IPS and Pages. I'm not sure how 301 redirects will be handled since each time I recategorize data I will hypothetically need a redirect. So

tourist / article-name-123

tourist / midtown / article-name-123

tourist / neighborhood-name / article-name-123

will require at least 2 redirects. They will always have to stay there because now there are 3 URLs generated for the same article. Now if it grows even further, it might be: 

tourist / county / neighborhood / article-name-123

There are numerous reasons to recategorize after you've discovered that some things aren't working as intended, need to be consolidated, broken out, etc. All I wanted to do was just grow my site and not clutter it up with numerous unneeded subcategories while the content amount was small. Looking for ideas because this seems patently unmanageable. 

 

[esquire]

Anyone have ideas? Addons? FURL experts? I recall reading that something in the URL was required fo Pages with categories to perform properly, which includes the category in the URL? I certain hope this isn't the case and that we can strip out the categories and just use the Page record number which is in the URL and get rid of the rest (category and the "r").

[Kevin Carwile]

 

[esquire]

Kevin - great series of addons you've got there. I may end up asking you about them as it would seem to require at least a $60 investment per site if this could work (for advanced aliases and automation.) I'd also have to investigate how it works, which it hopefully will. It looks like a great piece of programming and no doubt well worth the money if it can override how Pages works. 

If it may benefit others, I'm wondering if a conversation here would work about how one might set things up so that the creation of a standard article could use a different URL, e.g. /database page name/title-of-article-here.1234  (record number in database)  This way when you view articles on the site they will show the aliased URL and that when an http request is made it returns a standard 200 and not redirections. Thanks!

[Kevin Carwile]

Its pretty simple really. You can use rules to automate the creation of a new path alias for a pages record when it is created. Rules has built in token replacements so you can structure the alias however you like. And you can use multiple rules to create different url schemes for different circumstances.

Path aliases will automatically set the new alias as canonical and any standard internal url to the pages record will 301 redirect. If you decide to change the alias again later, the old alias will then redirect to the new one.

[esquire]

So taking an example, if I create a page that has a category URL such as site.com/dbase/cat/subcat/post-name/  - a new url is automatically generated by the plugin. Now when that page gets published, which URL is used - the plugin's URL or the IPS4 Pages internal URL? From what I'm hearing, I'm assuming you're saying that it will use the IPS 4 URL and that the plugin creates an aiias, e.g. site.com/dbase/123-post-name/ as an "alias" to the longer URL. That alias is used as a canonical so that Google will (hopefully) index that alias instead of the URL that is appearing visibly. I'm hoping that it isn't the case since users will copy and use the URL that appears when they pull up a page. So the alternative is that what you mean to say is that the plugin will catch the published page and use the alias every time IPS generates the URL, such as on the home page, in widgets, in RSS feeds,etc. and that it substitutes its own URL every time the real internal IPS4 URL is to be used.

[Kevin Carwile]

5 hours ago, esquire said:

the plugin will catch the published page and use the alias every time IPS generates the URL, such as on the home page, in widgets, in RSS feeds,etc. and that it substitutes its own URL every time the real internal IPS4 URL is to be used.

Yes. When a path is set to canonical, it will always be used when a link to the underlying page is generated through core processing. It's magical.

[esquire]

42 minutes ago, Kevin Carwile said:

Yes. When a path is set to canonical, it will always be used when a link to the underlying page is generated through core processing. It's magical.

LOL. It actually is. It's great work.

One last question - let's say I have a Database in Pages that uses Categories, which requires all those categories and subcategories in the URL. Is the IPS core converting the alias to the IPS4 URL and then rendering the page that way? I recall hearing something about the need to store information about a page in the URL when using Categories for a Database. Makes no sense to me as I would think they are independent but have to ask. If it's bypassed, then I can't fathom why anyone would require all that extra stuff in the URL. 

[Kevin Carwile]

Hence the reason why I built the app.

IPS4 does not store a mapped url for every record created. Instead, it uses pattern matching to generate and interpret urls. This is why certain info (such as the record id) needs to be present in the furl.

Personally, I like to have pinpoint control over the urls to every page on my site, and although you can create an individual url alias through IPS furl manager manually, it has significant limitations. You have to know the exact internal system url to map it to, it creates additional processing overhead to every page for each new furl you create, it cannot be automated, and you cant create "shortcut" urls that redirect to the canonical.

My app solves all of these problems by sitting on top of the core furl interpreter and canonicalizing all urls generated before output, and directly routing incoming requests to mapped aliases.

[esquire]

This app is insane. I am assuming that you can create a pattern for each module that is in the format:

module-name/record-subject-here-12345 so you can get the subject or title of a record and the record number?

In summary, this amazing app seems to perform the following:

• URL shortener for every page
• Uses the shortened URL as the Link Canonical for both the internal IPS page and the link shortened URL
• Has a second optional module to automate the above process for every Page you create
• Adds some overhead overlaying a shortener but response time should be negligible for small to moderate sized sites

The truth is that every web page has to have a unique ID. In theory you can have every page just be pulled up using mysite.tld/1 or mysite.tld/2 and then the core FURL interpreter will just store the details of what needs to happen, e.g. use forum module, pull up record 12345. I don't understand why the IPS FURL manager wouldn't either use this system or a uniform application of site.com/database-identifier/record-identifier/ In this fashion the URL would quickly and easily spell out module + record number. Like Wordpress and most systems I use, you can call any record in the database by using either the (1) complete URL with record name in the URL and the record number; or (2) just the record number. So:

mysite.com/topic/topic-name-here-12345/ can also be referred to as mysite.com/topic/12345/ 

This is helpful for 301 redirects should you move to a new system and much preferable to pure text posts. I only learned this later when I tried to wean myself off of Wordpress to discover that having no record ID in the URL made it impossible to have an efficient script for redirection.

I looked at the automation app. It's extremely well designed, ridiculously detailed in being able to identify so many tasks and it appears to apply the same record create/update recognition for every app that gets installed. This is probably the only thing that will make using categories work unless IPS can somehow separate the URLs from the taxonomy of content. This is crazy great and should replace the IPS 4 core IMHO, lol. Great work.

[Kevin Carwile]

11 minutes ago, esquire said:

URL shortener for every page

Yes

12 minutes ago, esquire said:

Uses the shortened URL as the Link Canonical for both the internal IPS page and the link shortened URL

Yes

12 minutes ago, esquire said:

Has a second optional module to automate the above process for every Page you create

Correct. It is automation ready because it can be controlled via rules. But rules is an application that stands on its own.

14 minutes ago, esquire said:

Adds some overhead overlaying a shortener but response time should be negligible for small to moderate sized sites

No. No overhead is added. Using IPS core furl manager to create short urls generates the overhead. Path alias eliminates the overhead.

[esquire]

12 minutes ago, Kevin Carwile said:

No. No overhead is added. Using IPS core furl manager to create short urls generates the overhead. Path alias eliminates the overhead.

I don't get why IPS wouldn't use such a system. This is really spectacular. In theory it makes converting from or to IPS 4 seamless and without requiring any 301 redirections.

In case anyone is wonder what on earth I mean.... check this out:

https://fixxer.com/mag/se/subse/another-lousy-page-i-dont-understand-r4/  >>>>>  https://fixxer.com/4

https://fixxer.com/mag/se/subse/no-photo-here-and-text-is-gone-r5  >>>    https://fixxer.com/mag/no-photo-here-and-text-is-gone-5

https://www.yoursitehere.tld/articles/category/subcategory/subcategory/post-name-here-which-can-be-long-r12345/

BECOMES

https://www.yoursitehere.tld/articles/post-name-here-which-can-be-long-12345/

The only thing it doesn't do is allow for a dot in the URL like other software we know does (and I hate the way it looks in addition to using them.) This is downright incredible and might actually be the saving grace for the use of IPS 4 Pages. You'll just need to get punished by helping me a bit in making sure the setup is automated properly after obtaining the pro versions. This is darn amazing.

[CheersnGears]

This sounds like another of Kevin's add-ons that I"ll need to buy once I can move to 4.x