Ticket #9272 (closed PLIP: fixed)

Opened 7 years ago

Last modified 6 years ago

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

rps_diff.png Download (4.8 KB) - added by esteele 7 years ago.
Plone 4 core vs PLIP 9272 (with exposeDCMetaTags set to True)

Change History

comment:1 follow-up: ↓ 2 Changed 7 years ago by 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. 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.

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:5 Changed 7 years ago by jaroel

  • Description modified (diff)

Redrafted PLIP.

comment:6 Changed 7 years ago by alecm

+1

Provided that it is off by default and easy to discover

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:11 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

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:18 Changed 7 years ago by esteele

  • Owner set to jaroel

comment:19 Changed 7 years ago by jaroel

  • Status changed from new to assigned

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:21 Changed 7 years ago by grahamperrin

  • Cc grahamperrin@… added

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:25 Changed 7 years ago by jaroel

Ready for review

Changed 7 years ago by esteele

Plone 4 core vs PLIP 9272 (with exposeDCMetaTags set to True)

comment:26 follow-up: ↓ 29 Changed 7 years ago by esteele

Rendering speed does not appear to suffer when enabling exposeDCMetaTags.

Plone 4 core vs PLIP 9272 (with exposeDCMetaTags set to True)

(ReadOnly test of Plone 4-python2.6 vs PLIP9272 with exposeDCMetaTags set to True)

I can provide the rest of the test results to anyone interested. They were just too large to attach to this ticket.

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

(In [30090]) Updating my review. Recommending +1 to merge. Refs #9272.

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

(In [30480]) Removing PLIP branches. Closes #9272.

comment:39 Changed 6 years ago by esteele

(In [30481]) Missed Plone merge when merging #9272. Refs #9272.

comment:40 Changed 6 years ago by esteele

(In [30482]) Merge changes from #9272 into Sunburst. This is probably worth refactoring. Refs #9272.

comment:41 Changed 6 years ago by esteele

(In [30483]) Factor the Dublin Core information out into an htmlhead viewlet. Refs #9272

Note: See TracTickets for help on using tickets.