create custom exception/error handling mechanism

[ElectricMaxxx]

As a follow up from #177

Would like to spice up the frontend test only by adding one more level in the routes/contents created in the FixtureLoader to see both ancestor and parent suggestions.

[ElectricMaxxx]

Feel free to merge, when you like it. You can see the purpose of this PR in the Frontend Test.
One typo in a route serves a list of suggestions - parent and ancestor.
In an application i would customize the template, wanted to check the result only.

[ElectricMaxxx]

Btw: depending when you want to tag, i will implement both (alternate locale too) in the Sandbox this or next night. Lastest monday Morning in train.

[lsmith77]

@wouterj I will leave review with you, ok? just make sure to only merge things that are certain to have no big side effects at this point in the RC phase.

[ElectricMaxxx]

@wouterj i think i have all line endings in New files this time :-)

@lsmith77 this PR should have no side effects. Its a feature beside to the common behavior of this bundle (SEO metadata).

[ElectricMaxxx]

But if "activated" in an cms with PHPCR it will provide a big help for error pages. And an example to extend it for the use with other persistence implementations.

[wouterj]

$group = $group ?: 'default';

[wouterj]

As said, I don't understand the name "BestMatcher".

I also think the 2 current BestMatchers are redundant and one can fullfill the job as good as 2 can.

[wouterj]

We should also have a way to switch of core best matchers imo

[ElectricMaxxx]

BestMatcher

@dbu and i came to that name. They are responsible for computing the best matches for a wrong url or just a typo.

Why are ther two?

Cause both are doing a different job and are registered separately by a tag. You can add your own matcher and call them what ever you want and let them do what ever you want. Btw: different matchers mean different groups. I would suggest to create a grouped output, like

<div>
    <ul>
        {% for group, matchs in best_matches %}
                {% for match in matchs %}
                    <li>{{ group }} - {{ match.name }}</li>
                {% endfor %}
        {% endfor %}
    </ul>
</div>

The presentation model/controller creates an array like that as data for the template.

switch core of

Yes and No. First the complete behavior is activated, when you add our Controller/Presentation as exception controller in the twig config. Second, the core ones are actived only, when choosing cmf_seo.persistence.phpcr: true. But i can imagine to not load the best_matcher.xml when a config like cmf_seo.disable_core_matcher: false exists. So you can use own matcher without being forced to use the core once in combination with phpcr.

[dbu]

if this class acts as controller, i would put it in the Controller namespace of our bundle

[dbu]

i would add configuration options for cmf_seo.error.phpcr_parent_matcher.enabled and cmf_seo.error.phpcr_ancestor_matcher.enabled or something like this. we probably don't need config for the feature per se, as it won't do anything when not reconfiguring the error controller in the application, right?

[dbu]

maybe we could have just one matcher class here, a ancestor mapper with a limit. to get a parent mapper you would use the ancestor with limit 1 ;-)

maybe rather than BestMatcher we could call this thing SuggestionProvider? its giving suggestions what page you might wanted to look at when you hit a 404 page.

[ElectricMaxxx]

Right it does nothing.

But would have head aches with your config example. By enabling/disabling all i would just suppress the loading of a service Definition file, by enabling them as Single services i would have to create them manuallyin the extension class of suppress them in compiler Pass, where i do not have the config. =

[ElectricMaxxx]

So you would see ancenstors as all children of a common parent?
I would See them as sibblings.

And again we would leave the meaning of grouped providers. By having them separate i you need the constraints: give me an array and a group name. And i pass that to the template. But with different logic in the providers? Maybe a ass. array with identifiers/groups as keys and nested array for the route suggestions? =

[ElectricMaxxx]

So...
except the 2-in-1-SuggestionProvider story and the 1-insteadof-2-Enable-SuggestiongProvider story all open stuff should be fixed:

• names: SuggestProvider instead of BestMatcher, even the tag
• controller: instead of a presentation model it is a controller now
• some CS and docBlock fixes

[dbu]

suggestionProviders or suggestionProviderChain?

[wouterj]

As this is a huge feature, I'll properbly not make it into 1.2 (which is released this week)

[dbu]

yeah, rather get it right than rush it in.

@lsmith77 also raised the question if this actually belongs into the
SeoBundle or would merit a bundle of its own. its not tied to any other
features of the SeoBundle so it could be separated. while good 404 pages
is required for SEO, you could want good 404 pages without caring about
search engines.

[ElectricMaxxx]

No problem, so i would be the first with a feature for 1.3 g

But will finish the open issues here this evening i think.

Then it will be your decission where to Merge.

[ElectricMaxxx]

I would see it in SeoBundle as it is good for both SEO and for UX. Last can infect others to look into the CMF. Especially both SuggestionProvider, which are able to serve content right from the Heart of the CMF. =

[dbu]

looks sane to me. in conflict with master though.

as discussed, lets wait with merging until after the release and bump the version for this one.

[ElectricMaxxx]

👍

[lsmith77]

this will have to wait for the next release cycle. btw also needs a rebase

[ElectricMaxxx]

Ok.

[ElectricMaxxx]

rebased and squashed. Created a 1.1 branch too. So feel free to merge when ok.

[dbu]

cool! @ElectricMaxxx did you do a doc PR as well? if not, can you please open an issue so we don't forget this? undocument features are unlucky...

[ElectricMaxxx]

done in symfony-cmf/symfony-cmf-docs#606