Search results and automatic choice of best engine page for a given engine route

[boutell]

We support more than one engine page per engine module. This raises the question of which engine page should be linked to for a given link_to or url_for call.

We already support expressly pushing an engine page as the target and then popping it afterwards.

However we now have a new issue: virtual pages in search results. Right now they are coming up as as bogus links to the virtual pages that contain that content.

We should block that, ignoring them like the 'global' page. But this raises a larger issue: how *should* we link back to blog posts in search results? They are implemented as areas, there should be permalinks back to the blog posts, not nothing at all.

A possibility: if the slug contains a slash, but does not start with a slash, it's a Symfony URL. This is very elegant. It leverages the symfony routing engine instead of reinventing the wheel. (If there is no slash at all we need to ignore it in search results entirely)

But what happens when that symfony URL points to an engine route and there is more than one engine page, as is typically true for the blog plugin? Which engine page should get the permalink?

I see two possibilities:

1. Post an event with the sfRoute object. The engine can then decide which of its engine pages should win. If it doesn't respond my usual default algorithm wins. This cleverness would need to be invoked in aRouteTools::addPageToUrl.

(If the winning page has the admin flag and the user is not a potential editor (aTools::isPotentialEditor, something like that), ignore this search result, pre-pagination so we don't wind up with page 1 having nothing on it)

2. Forget trying to merge virtual pages with fully paginated site search results at all. Instead, ignore all virtual pages in the regular search and post an event from the search action to fetch other search results and integrate them into the site search results via separate "teaser" components, with a link back to the main search feature for that particular plugin if you want more results of that kind.

The latter, honestly, is consistent with stuff we've done successfully in other places. Merging search results can be tricky and confusing. It's also slow though - two Zend searches where one would do if we got the routing right.

I think we should take a deep breath and tackle the cool way (#1).

Dan, on reflection I am assigning this to you because you are working on the blog plugin and you need this right now. I want to do it but it's not in my field of view at the moment. Tap me on the shoulder for anything you have doubts or questions about and make sure we do code review of it together before it's official.

[geoffd]

This relates to ticket #448

[tboutell]

Fixed in [2964]

A blog posts slot with a post in the jobs category will now link to the jobs-specific engine page.

The aDoctrineRoute class now automatically calls getEngineSlug on the sf_subject (the object the link is for), if that method exists. So far in my tests this looks like a solid fix to the longstanding problem of generating decent permalinks for blog and event slots.

This is done only if we are not already on an engine page of the relevant type (for instance you are never taken away from the /blog engine page when you click on a permalink for something shown there, even if it's even better for the /job page).

Also you are never taken away from an engine page that has been explicitly pushed or set with the engine-slug parameter.

I like that this fix is nice and OOPy and doesn't require the use of Symfony events.