Forums / General / Default URI of deleted objects

Default URI of deleted objects

Previous topic

General

Next topic

Author	Message
Russell Michell	Sunday 28 September 2008 3:36:48 pm Hi there folks, Am I the only one that thinks the default eZ behaviour for linking to deleted content-objects is a little odd? * Create an Article called "Test", then publish it. * In any other existing Article object, add a link via the online editor to the Article "Test" then publish it. * Rename "Test" - the link to it in the existing Article is updated. Fine, all good. * Move "Test" to another folder - the link to it in the existing Article, is updated. Fine, all good. * <b>But</b> Delete "Test" to the Trash - the link to it in the existing Article, is updated - but to the default SiteURL? Is it possible to change the default location that links to deleted objects point to, and leave them as-is so that when you run something like runcronjobs.php, the link results in "invalid" being returned so it can be flagged as something that site-admins/editors need to check and fix? Cheers, Russ Russell Michell, Wellington, New Zealand. We're building! http://www.theruss.com/blog/ I'm on Twitter: http://twitter.com/therussdotcom Believe nothing, consider everything.
Mark Marsiglio	Sunday 28 September 2008 6:57:51 pm Try changing your error.ini settings. The settings that I use most often are: [ErrorSettings] DefaultErrorHandler=rerun DefaultRedirectURL=/content/view/error/2 DefaultRerunURL=/content/view/error/2 ErrorHandler[20]=rerun RerunURL[20]=/content/view/error/2 This results in the url staying the same, and 404 headers being sent to the user. We set up a custom override on the error view to show the sitemap and a search field so that the user can find the page that they were looking for. However, it will come back as an invalid link when you run an external checker on it. The internal link checker will not pick this up because it does not check eznode urls. However, if you have pages linked using the regular format of url (i.e. /folder/subfolder/page_name) either in relative or absolute format, the link checker should pick up the problem. To avoid dead link problems when deleting pages that are connected via eznode:// links, we recommend to our content managers that they check the Reverse Relations that the page has (using the admin interface) before deleting a page to see what other pages link to it, or have it embedded. http://www.thinkcreative.com Turning Ideas Into Strategic Solutions
Russell Michell	Monday 29 September 2008 3:46:13 pm Hi there and thanks Mark, I take your point with regard to ensuring deleted items no longer have reverse-linked items, but do you find this method works for links that point to items that have just been placed in the trash? What I mean is, once you access a page which used to link to a content-object but has just been removed to the trash, all URIs pointing to it seem to be auto-updated to what appears to be SiteURL from site.ini. How do you reconfigure eZ to change this URI? In override/error.ini.append.php if I use: [ErrorSettings] DefaultErrorHandler=displayerror If I now punch in a non-existent URL - I get the eZ default "Module Not Found" error (Error 20). But if I select the link that used to point to a normal content object (An Article for instance) but has since been moved to the trash, the link itself becomes updated - no eZ error, the link simply changes and becomes SiteURL. The same if I use your solution for override/error.ini.append.php DefaultErrorHandler=rerun DefaultRedirectURL=/content/view/987 DefaultRerunURL=/content/view/987 ErrorHandler[20]=rerun RerunURL[20]=/content/view/987 Or am I totally misunderstanding something (It wouldn't be the first time!) Cheers, Russ Russell Michell, Wellington, New Zealand. We're building! http://www.theruss.com/blog/ I'm on Twitter: http://twitter.com/therussdotcom Believe nothing, consider everything.

Author

Message

Russell Michell

Sunday 28 September 2008 3:36:48 pm

Hi there folks,

Am I the only one that thinks the default eZ behaviour for linking to deleted content-objects is a little odd?

* Create an Article called "Test", then publish it.
* In any other existing Article object, add a link via the online editor to the Article "Test" then publish it.
* Rename "Test" - the link to it in the existing Article is updated. Fine, all good.
* Move "Test" to another folder - the link to it in the existing Article, is updated. Fine, all good.
* <b>But</b> Delete "Test" to the Trash - the link to it in the existing Article, is updated - but to the default SiteURL?

Is it possible to change the default location that links to deleted objects point to, and leave them as-is so that when you run something like runcronjobs.php, the link results in "invalid" being returned so it can be flagged as something that site-admins/editors need to check and fix?

Cheers,
Russ

Russell Michell, Wellington, New Zealand.
We're building! http://www.theruss.com/blog/
I'm on Twitter: http://twitter.com/therussdotcom

Believe nothing, consider everything.

Mark Marsiglio

Sunday 28 September 2008 6:57:51 pm

Try changing your error.ini settings. The settings that I use most often are:

[ErrorSettings]
DefaultErrorHandler=rerun
DefaultRedirectURL=/content/view/error/2
DefaultRerunURL=/content/view/error/2

ErrorHandler[20]=rerun
RerunURL[20]=/content/view/error/2

This results in the url staying the same, and 404 headers being sent to the user. We set up a custom override on the error view to show the sitemap and a search field so that the user can find the page that they were looking for. However, it will come back as an invalid link when you run an external checker on it.

The internal link checker will not pick this up because it does not check eznode urls. However, if you have pages linked using the regular format of url (i.e. /folder/subfolder/page_name) either in relative or absolute format, the link checker should pick up the problem.

To avoid dead link problems when deleting pages that are connected via eznode:// links, we recommend to our content managers that they check the Reverse Relations that the page has (using the admin interface) before deleting a page to see what other pages link to it, or have it embedded.

http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions

Russell Michell

Monday 29 September 2008 3:46:13 pm

Hi there and thanks Mark,

I take your point with regard to ensuring deleted items no longer have reverse-linked items, but do you find this method works for links that point to items that have just been placed in the trash?

What I mean is, once you access a page which used to link to a content-object but has just been removed to the trash, all URIs pointing to it seem to be auto-updated to what appears to be SiteURL from site.ini. How do you reconfigure eZ to change this URI?

In override/error.ini.append.php if I use:

[ErrorSettings]
DefaultErrorHandler=displayerror

If I now punch in a non-existent URL - I get the eZ default "Module Not Found" error (Error 20). But if I select the link that used to point to a normal content object (An Article for instance) but has since been moved to the trash, the link itself becomes updated - no eZ error, the link simply changes and becomes SiteURL.

The same if I use your solution for override/error.ini.append.php

DefaultErrorHandler=rerun
DefaultRedirectURL=/content/view/987
DefaultRerunURL=/content/view/987
ErrorHandler[20]=rerun
RerunURL[20]=/content/view/987

Or am I totally misunderstanding something (It wouldn't be the first time!)
Cheers,
Russ

Russell Michell, Wellington, New Zealand.
We're building! http://www.theruss.com/blog/
I'm on Twitter: http://twitter.com/therussdotcom

Believe nothing, consider everything.