Previously Martin Aspeli wrote:
> Wichert Akkerman wrote:
> >404 being slow has two problems: it is slow, and it is uncached which
> >makes it extra painful. Making it slower could be disastrous.
> It's merged now, but it's trivial to make changes to
> default_error_page.pt as we see fit.
> So - the changes are as follows:
> - Nothing different if error type is not NotFound (404)
> 1. An attempted redirect if the path storage has something. This
> basically means some string manipulation to decide which path was
> "intended", and a BTree lookup to determine if there's something for
> this path. If found, a 301 redirect is performed.
> 2. Otherwise, we look "up" the intended path and use traversal from
> the portal root to check for an object that matches; this basically
> covers the case when you wrote http://site.com/some/path/veiw or
> http://site.com/some/psth (typo near the end of the URL) - it'll suggest
> (in a listing) /some/path or /some in this case.
> 3. Also, we look at the end of the URL (last part after a slash) and
> perform a catalog search for SearchableText=id. If that returns nothing,
> we try again, with the second-to-last part of the URL, and so on until
> we find something or the portal root. We don't try to do searches for
> common method aliases or special things like 'index_html'.
> Note - I've just replicated the logic that RedirectionTool was doing in
> the same template. If plone.org suffers with RedirectionTool, it'd
> suffer with this and vice-a-versa.
> So basically, if we have a redirect (automatically constructed when
> things are moved or renamed) then the template is possibly even a bit
> faster than before. This is the real "link integrity" use case, I guess.
> The "helpful suggestions part (one or more traversals + one or more
> catalog queries, of which the top 10 are returned) is the one that slows
> things down. I see a few options:
> - Remove it entirely
> - Delegate it to some other template ("click here to see
> suggestions"); not ideal UI but gives us back the speed.
> - Let people remove as necessary by customising the template
> - Make it optional depending on some control panel setting
Making 1, 2 and 3 optional might be nice. From the way you describe it
none of this is a per-user thing, so we can probably cache the action
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Framework-Team mailing list