Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

decision for default value concatenation into getSeo*() extractor methods #126

Closed
ElectricMaxxx opened this issue Apr 7, 2014 · 3 comments

Comments

@ElectricMaxxx
Copy link
Member

As described in symfony-cmf/symfony-cmf-docs#442 (diff) it would be better solution to give the descission of "how to handle the default values" in the hand of the developer that implements the extraction methods on the document.

@wouterj
Copy link
Member

wouterj commented Apr 7, 2014

Hmm, I thought about it tonight and now I disagree with this. However, we should not talk about "Default title", but about "Standard title" imo. The Content can determine how the title for that content will look. However, the site may have a title as well. That should be determined in the configuration.

For instance, I want to have the title "%content_title% | My awesome CMF site". The "My awesome CMF site" is the standard part of the title for the site, the "%content_title%" part can be variable per content and is determined for the document

@ElectricMaxxx
Copy link
Member Author

Ok calling it standard instead of default would make easier to get a difference in the meaning between the default values you can set in sonata_seo configuration section and the standard values in the cmf_seo configuration section.
Cause if you set the default values in the sonata block and implement the Twig-Helpers will produce page settings as described by sonata if the content is not aware in seo at all.
Would be the same as doing <title>{% block title %}Default title{% endblock %}</title> and override it by an extension or not. We have got the same situation now. "Default title" will come from sonata_seo section, all overwriting stuff will be produced in case of seo aware contents.

So, with calling it standard instead of default would make it easier to explain why to create an sonata_seo configuration block too.

@dbu
Copy link
Member

dbu commented May 2, 2014

this can be closed right?

@wouterj wouterj closed this as completed May 2, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants