Ability to define/store arbitrary seo metadata

[benglass]

Unless I missed something in the code, it seems that currently the seo metadata that is supported is limited to title, keywords, description and original url. It would be great if you could store arbitrary items such as facebook open graph data. Since the information is stored as an array this doesn't seem like it would too difficult (although it would complicated the admin form) but right now the SeoMetadata::fromArray only handles the aforementioned keys.

It would also be ideal to be able to specify default values for these keys across the site (although I believe this can be handled via sonata seo bundle).

[wouterj]

It would also be ideal to be able to specify default values for these keys across the site (although I believe this can be handled via sonata seo bundle).

That's not the scope of this bundle. This bundle is just a tiny layer on top of Sonata, it can't work without the SonataSeoBundle. Use the SonataSeoBundle config to set defaults.

[wouterj]

But on your other part, you have a good point. I've planned to fix this for 1.1. I'll post my ideas once I get the picture about how it should be done.

[ElectricMaxxx]

The only reason why the SeoMetada has that from/toArray methods is cause the phpcr-odm has no possibility to persist flat value objects (doctrine/phpcr-odm#461).
So it would be possible to expand it for more function. But we need to be carefull not to just copy the SonataSeoBundle. I think that we should add function that depends on contents or its structure.

[ElectricMaxxx]

BTW can somebody explain what facebook matters on SEO?

[wouterj]

@ElectricMaxxx just like microformats/microdata, Open Graph data helps the bot to get a better overview about which texts are important and what the site is really about. Besides that, facebook uses it for it's like button etc.

[dbu]

With simplecms documents we have the extra field which is a hashmap, allowing to store arbitrary scalar data. Not sure if this bundle should actually be the MetadataBundle rather than just SeoMetadataBundle. On the other hand its easy to extend a document and roll your own - and that is more semantic than throwing values into an extra array.

But i agree the metadata class should be extendable / replacable without hassle.

[ElectricMaxxx]

My reason to create an object called SeoMetada instead of just an array (with all the work for convert for persistence) was, to have a oop way to get the properties. Code in the SeoPresentation would be much harder if would need a if (!empty($seoMetadata['title']) {...} for every item. And every property has its representation in DOM (carried by sonatas PageService).
So if we wanna expand the object we need to have a look at sonatas PageService, is it still there. Then we need to have a look: is it affected by our document. (OK, facebook-like-buttons do so, i.e).

For very random hashmaps to just store some data the sollution of @dbu and the SimpleCms would be cool. Either to create an array extras in the SeoMetadata, use an existing solution on the document or create a new on on content document. Indeed this would need some work for the admin form, but would work. The think i got some head ache would be: What to do with random data i do not know what the user plan to do with? When i have got a title in SeoMetadata i know it: i fetch it and push it into sonatas Pageservice and override the existing default value to create a title tag with the value i fetched (extended by an translation key to get a standard view).

[benglass]

I am not suggesting that this become a generalized bundle for storing any kind of metadata about a document. As @dbu suggested if you want to store a hash of random stuff you can map it using the assoc phpcr functionality.

What I'm suggesting is that for an SeoBundle to really handle per-document seo it has to be able to handle other seo settings (meta tags) for facebook open graph, other meta tags like robots, etc. These meta tags can be rendered by the sonata page service (it currently has the ability to specify different meta properties with default values). I propose we expand the SeoMetadata class to be able to support other meta tags, perhaps through configuration. Ideally if this is just providing an sonata seo bundle integration it would somehow get a list of support meta tags from sonata seo.

From http://sonata-project.org/bundles/seo/master/doc/reference/installation.html#configuration

# app/config/config.yml
sonata_seo:
    page:
        metas:
            name:
                keywords:             foo bar
                description:          The description
                robots:                  index, follow

            property:
                'og:site_name':       Sonata Project Sandbox
            http-equiv:
                'X-Ua-Compatible':      IE=EmulateIE7

So if this bundle could pull the configuration for metas which is being used by sonata to determine which keys should be storable as SeoMetadata that would be ideal from my perspective. Then you can use sonata seo to configure defaults and this bundle just provides a way to persist the relevant seo metadata onto phpcr entities.

That kind of functionality isn't even really specific to PHPCR and it would even be nice to have an ORM method for that as well but that is perhaps not in the scope of this bundle.

[ElectricMaxxx]

I will start to do that this evening. But want to solve two questions before starting:

1. Is assoc able to persist deeper structures now or what is needed for that Support nested associative arrays doctrine/phpcr-odm#417
2. Which chars arn't allowed as keys for the assoc mapping in phpcr-odm? (@dbu, @lsmith77 )

Cause the easiest way to to do that would be an array (or easier an ArrayCollection) with a "add" function for the admin support and a little hack in the listener to transform the data to persist it in a usual assoc way. Either we can keep the nested structure and just persist an extra array called properties or i will prefix the keys with propterty_ and build the ArrayCollection onLoad.

[dbu]

the key charset in a a hashmap should not limited afaik. even / and such should work, phpcr should escape all values.

lets do it for flat arrays and address the phpcr-odm issue of nested arrays one day.