Ticket #7278 (closed Feature Request: wontfix)

Opened 6 years ago

Last modified 11 months ago

too many aliases

Reported by: wichert Owned by: optilude
Priority: minor Milestone: Future
Component: General Version:
Keywords: Cc:

Description

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.

Change History

comment:1 Changed 6 years ago by optilude

  • Type changed from defect to Enhancement

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by 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.

comment:4 in reply to: ↑ description Changed 6 years ago by 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... :)

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by witsch

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

comment:9 Changed 6 years ago by hannosch

  • Milestone changed from 3.x to 4.0

I agree this needs an on/off switch.

comment:10 Changed 5 years ago by hannosch

  • Milestone changed from 4.0 to Future

comment:11 Changed 5 years ago by 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".

comment:12 Changed 5 years ago by optilude

comment:13 follow-up: ↓ 14 Changed 4 years ago by dukebody

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

comment:14 in reply to: ↑ 13 Changed 4 years ago by dukebody

Replying to dukebody:

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

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

comment:15 Changed 22 months ago by davisagli

  • Component changed from Infrastructure to General

comment:16 Changed 22 months ago by kleist

  • Status changed from new to confirmed

comment:17 Changed 11 months ago by eleddy

  • Status changed from confirmed to closed
  • Resolution set to wontfix

This ticket has not been modified in over 9 months. In another brazen attempt to clean this tracker up, this is closed. If you really, REALLY care about this ticket, please re-verify that it is still an issue on the current supported releases (4.2 or 4.3) and reopen. Better yet, submit a pull request to fix the bug and then close the bug properly. We <3 you and all of your effort, but we can't go on like this anymore. I hope you aren't too mad and we can still be friends. Hugs.

Note: See TracTickets for help on using tickets.