too many aliases

[wichert]

Every rename in the site generates an aliases. This is nice, but it also creates a lot of useless aliases. For example I new have an alias for frontpage.2007-10-29-1232768683 -> welcome.

Perhaps we need some more control over automatic alias creation. A global on/off switch would be useful, and perhaps it could be a per-type thing as well.

It certainly should not happen for the automatic renaming of newly created AT instances.

[limi]

I agree that it shouldn't happen for objects coming out of portal_factory.

There's a perceptual difference between manually created and automatically created aliases, however. Plone should know where an object went when being moved or renamed, always. I don't see the use of a switch for this, it's useful functionality that should always be on.

Having a marker on these aliases so the autogenerated ones could be displayed separate from the manual ones is probably a good idea, though. That way UIs like RedirectionTool can list things in a more manageable way.

[wichert]

I'm not sure I agree.

Personally I was very surprised that those aliases were created automatically - this is too much magical behaviour for my taste and not something that should be enabled by default. It definitely should be something you can easily disable.

I'm not sure if showing magically created aliases differently in the user interface will help a lot.

[witsch]

Replying to wichert:

It certainly should not happen for the automatic renaming of newly created AT instances.

this was fixed as part of #8260 (martin did agree with the suggested fix, btw). so you'll only have to come up with a conclusion about the need for a switch now... :)

[wichert]

There is a need. It should be possible to disable all of plone.app.redirect - it adds extra overhead that a lot of sites do not need or want. It has a very high DWIM-feeling to me.

In hindsight I wish this was not part of core. It could be an excellent third party product.

[optilude]

We put it in the core because we wanted to be able to sport the claim "no more broken links". For that, we needed link integrity + the auto redirects when things move. It's a strong selling point in many circles, so I stand by our decision to include it.

There is of course also RedirectionTool, which adds a GUI to explicitly create redirects/aliases. That one is more sensible to have outside the core.

That said, I agree it needs a global "off" switch in the control panel. I still think it should be on by default because (a) I don't think the overhead is noticable in most sites and (b) the value is only there if it's been running "forever", i.e. there's no value in turning it on after you've broken a bunch of links by renaming things. ;-)

So - +1 for a switch, and +1 to leave it enabled by default. Anything else would be too much of a policy change for 3.x, but I'll argue for keeping it on in 4.0 as well, of course.

[wichert]

Anything that introduces magic do-what-i-mean behaviour should be disabled by default in my opinion.

I find its behaviour incredibly confusing at times. plone.org has some very lovely examples: if you typo the release number of a product in a URL you suddenly end up at the release for a copmletely different product. Just look at  http://plone.org/products/plone/3.1.4 for example.

[witsch]

perhaps it just needs a UI to be able to remove such confusing entries?

[hannosch]

I agree this needs an on/off switch.

[kleist]

I do understand the argument "Plone should know where an object went when being moved or renamed, always". But I don't agree with the last word.

When an administrator renames items in a controlled way, e.g. during development or site maintenance, this behavior is simply pita. At the very least, it must be possible to delete an automagically created "alias".

[optilude]

To edit aliases, use  http://pypi.python.org/pypi/Products.RedirectionTool.

[dukebody]

(In [33250]) Update changelog. Refs #7278.

[dukebody]

Replying to dukebody:

(In [33250]) Update changelog. Refs #7278.

There's a typo. It should be #9278 instead.