Ticket #9272 (closed PLIP: fixed)
Exposing and editing Dublin Core properties
Reported by: | jaroel | Owned by: | jaroel |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Templates/CSS | Version: | |
Keywords: | Cc: | plip-advisories@…, yurj, grahamperrin@… |
Description (last modified by limi) (diff)
Motivation
Exposing the DC properties in the <head> of HTML pages increases the semantic value of Plone based websites.
Proposal
Expose the DC properties in HTML.
Implementation
In plone_control_panel: add a control panel which allows to enable/disable DC properties exposure (default=disabled) and which show the fields + explanation of those fields.
In /edit: if exposeDCMetaTags is enabled, add a tab that allows to disable DC properties exposure. The tab should show what data will be exposed.
The control panel, the tab and the tag generator must check "show_about" (show creator/author data.)
Risks
This was removed in earlier Plone versions because it had performance issues. It needs to be benchmarked again to make sure it doesn't negatively affect performance.
Attachments
Change History
comment:2 in reply to: ↑ 1 Changed 7 years ago by jaroel
Replying to hannosch:
This is already possible today. Turn on the "exposeDCMetaTags" boolean in portal_properties/site_properties and the DC stuff is exposed in the head section.
Ok, clear. Could we then at least turn it on by default and make it editable via plone_control_panel and /edit ?
comment:3 Changed 7 years ago by MatthewWilkes
That seems like a good suggestion, jaroel, could you redraft the PLIP to take that change into account?
Matt
comment:4 Changed 7 years ago by hannosch
Having this controllable via a real control panel sounds good. But I'm not so sure about turning this on by default. To my knowledge meta elements are currently not used by any system anymore. Search engines only look at content that is actually visible to the end user, as the meta tags where abused too often. I don't know of any widespread service that would actually use this information. There's also some potential problems with exposing sensitive information in those DC properties like author names, collaborators or various dates. Some of these settings are hidden by the "show_about" setting at other places. If we should decide to show this information, there needs to be some way of reviewing the information for a normal user in the editing interface, so he knows what he exposes - the browsers "show page source" doesn't quite cut that.
comment:7 Changed 7 years ago by pupq
Many search apps you decide to use instead of Plone can look for metadata here, even though few, if any public search engines do.
Every class, at least one students asks "how come the metadata isn't in the head section"--some people do seem to expect it there.
Having a pref in Site Setup to control this would seem to be win/win, and meet users' expectations.
comment:8 Changed 7 years ago by limi
Just make sure that this is profiled — the reason it was removed from Plone 2.0 onwards was that it had severe effects on performance. This might no longer be the case, but the potential upside of the metadata stuff isn't sufficient if it slows down page rendering in any way.
comment:9 Changed 7 years ago by limi
- Description modified (diff)
Adding the performance concerns to the risk section.
comment:10 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:12 Changed 7 years ago by MatthewWilkes
FWT Vote: +1
comment:13 Changed 7 years ago by rossp
FWT vote +1, provided any performance issues discovered are resolved.
comment:14 Changed 7 years ago by davisagli
FWT vote: +1.
I'm not convinced that there is value in exposing an override for this setting on the edit page of each item, however.
comment:15 Changed 7 years ago by raphael
FWT vote: +1 (assuming that it's only about (i) exposing the site property in the control panel and (ii) changing the default if performance loss is acceptable)
comment:16 Changed 7 years ago by calvinhp
FWT Vote: +1 for being off by default, but shown in the site setup control panel area. Optionally it would be nice if you could choose how you would want it included and support something like RDFa
comment:17 Changed 7 years ago by esteele
Approved by FWT vote.
comment:20 Changed 7 years ago by yurj
- Cc yurj added
Problem: DC talks about the object which plone talks about, or about the plone object?
For example, I publish a page which talks about a book. The DC:author is set to the creator of the page, not the creator of the book. So, semantically, it appeears related to the book, even if it is not. There are many other examples about ambiguos meaning of metadata in CMS software.
comment:22 Changed 7 years ago by jaroel
control panel + rendering metatags in https://dev.plone.org/plone/changeset/28477 and https://dev.plone.org/plone/changeset/28478
Initial testing show no real slowdown (ab -n 1000 = 107s or 9.35r/s + ab -n 1000 -c 1000 = 108s or 9.25r/s)
comment:23 Changed 7 years ago by jaroel
err for ab -n 1000 -c 100: 107 sec without DC rendering and 108 with :/
comment:24 Changed 7 years ago by jaroel
comment:25 Changed 7 years ago by jaroel
Ready for review
Changed 7 years ago by esteele
-
attachment
rps_diff.png
added
Plone 4 core vs PLIP 9272 (with exposeDCMetaTags set to True)
comment:26 follow-up: ↓ 29 Changed 7 years ago by esteele
comment:27 follow-up: ↓ 30 Changed 7 years ago by esteele
comment:28 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 23.
comment:29 in reply to: ↑ 26 Changed 7 years ago by jaroel
Replying to esteele:
Rendering speed does not appear to suffer when enabling exposeDCMetaTags.
I can provide the rest of the test results to anyone interested. They were just too large to attach to this ticket.
I would like to see all tests here, even if it's just for creating a history.
comment:30 in reply to: ↑ 27 Changed 7 years ago by jaroel
Replying to esteele:
My review is at http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/plips/plip9272-review-esteele.txt
As mentioned in http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/plips/plip9272-dcproperties.txt , I do think /edit will be usefull but it's more for an addon product. Another option is to defer that to 4.1, so we can at least deliver for 4.0.
comment:31 Changed 7 years ago by jaroel
- Milestone changed from 4.0 to 4.x
I'd like to move this PLIP to 4.x. I was in a tight scheduled project for the last two weeks and will be for the next week or so. I am not able to get this done in time.
comment:32 Changed 7 years ago by jaroel
- Milestone changed from 4.x to 4.0
Tests were added for the control panel addition and to check the DC properties in the output HTML. I don't agree with adding the site default language when a content type is set as "Language neutral". "Language neutral" means the object is really language independent (an image for example) and thus shouldn't have a language specified as DC property.
comment:33 Changed 7 years ago by jaroel
Ready for merge
comment:34 Changed 6 years ago by esteele
comment:35 Changed 6 years ago by rossp
FWT vote: +1 for merge
comment:36 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose 0 Laurence Rowe +1 Matthew Wilkes - Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:37 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9609
comment:38 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed
This is already possible today. Turn on the "exposeDCMetaTags" boolean in portal_properties/site_properties and the DC stuff is exposed in the head section. The DC properties aren't special in any way but part of the normal edit screens of every object. Users don't know that for example title and description are defined in dublin core. Grouping by the presence in a technical standardseems non-optimal to me.