Products.cmfplone: Should be easy to create have a byline

[djay]

User problem

Some sites show some combination of

• last updated date
• last published date
• creators name
• last editors name

The person in charge of deciding _what_ information is shown on the page (information architect/content team leader/site admin/themer) should be able to include this information in the page easily and flexibly being able to pick which of the above they want to show. Showing at least the publication date is a common feature of blog posts and news items in other CMS's

History

The byline was a feature used both by internal editors and reused to show to the public (with reduced functionality, ie no history). Currently for 5.0 it is hidden by default because there is last updated date is shown in the toolbar and the history view provides the other info at a single click.

replaces https://github.com/plone/Products.CMFPlone/issues/668 and https://github.com/plone/Products.CMFPlone/issues/714

Options

1. Have a tickbox to turn the byline on
   
   
   
   • Fix the current tickboxes in security and site which previously determine if the byline is visible to the public and if it should show last published date. This would turn it on for everyone or off for everyone.
     
     
     
     
     
     • should probably move somewhere more sensible like theming.
     
     
     
     • improve them to give more options about showing date without author #668
     
     
     
     • pro: backwards compatible setting.
     
     
     
     • con: makes it harder for themers to cope with visual elements that can be turn on thus breaking the theme (but we already have that with things like TOC)
     
     
     
   
   
2. Have the viewlet hidden but easily enabled by switching on the viewlet ttw. Document how to use diazo to hide parts you don't want.
3. Always have the byline turned on. Document how to use diazo to hide parts you don't want or all of it
4. Document how to use diazo to create your own byline using parameter expression like modified = context/modified and a diazo rule like <insert-after css:theme="#content h1"><p>Last modified {$modified}</p></insert-after>
   - pro: teaches them more flexible approach. code is small and easy to copy
   ~~- con: means that have to modify an out of the box theme.
5. solve "way to include dynamic or rich content into the text of a page" #469, ie by mosaic or similar. byline would be a tile. or by htmlfragments (requires coding)
6. have something like collective.listingviews built into plone which enables admins to add portlets with common metadata without coding which can then be styled using diazo.

[davilima6]

You opened a new issue but forgot to mention original thread (#668) most voted suggestion: byline stays as available CMS feature however hidden and marked as a deprecated viewlet that will need to be replaced when Mosaic comes out. By there we'll have a configurable byline tile that will allows us to delete old site setup settings.

As a bonus we avoid changing twice the recommended way of having a byline in Plone.

I also find important to bring in this issue the research by @hvelarde: despite Barceloneta aiming for minimalism, byline may be considered an expected native CMS feature.

[keul]

Probably it's too late for Plone 5, but I think it's time to make the byline a little more configurable.

We really enjoy the works we did with rt.lastmodifier, where there's a specific permission for every piece of the byline (that's is _not_ related to theme but is a security configuration). The global check "show/hide byline to anonymous" is not enough in lot of use cases.

[davilima6]

Nice! I hope it's not hard porting those features into Mosaic's byline tile.

[hvelarde]

@djay I really appreciate the work you have done trying to resume the conversation we have the other day, but we need to agree on one basic concept before continue working on this issue: the byline is content, not presentation. so, it is not the "themer" who decides if that content is there, but the publisher of a site.

it has to be easy to change the settings and it has to be done independently of the theme; I don't see the need of having Diazo involved on this.

what @keul showed here probably the way we need to go.

[hvelarde]

@vangheem why did you closed it? we haven't even starting talking about it :-)

[mauritsvanrees]

@hvelarde He closed it automatically by merging a pull request that actually fixes it. Seems legit. :-)

[hvelarde]

@mauritsvanrees no, it doesn't fix it; we're talking about different things here

[davilima6]

@hvelarde is right, only the #714 part of this issue has been closed by plone/plone.app.layout#59 - and even then not completely cause now we have bad redundancy with toolbar: if we are keeping history in the latter we must hide the viewlet by default. Also we should file a bug in which the viewlet doesn't respect its visibility setting in @@site-controlpanel (/cc @rodfersou)

After that we still have to discuss how to implement the controls suggested in #668. I think those should go on Mosaic only (option 5) for the sake of avoiding both coredev rewrites and integrators pain in the near future.

[rodfersou]

This issue https://github.com/plone/Products.CMFPlone/issues/1037 closes the part to respect @@site-controlpanel

/cc @davilima6 @hvelarde

[hvelarde]

I removed the "_strange to have some aspects of theme determined by a tickbox and others_" line from the "Have a tickbox to turn the byline on" option; as we discussed before, metadata is content, not theme.

[fredvd]

Now with the latest released Plone 5.0.6 there's a Security setting in the control panel:
"Allow anyone to view 'about' information" which doesn't do anything for the byline for anonymous vistors because by default the byline viewlet is hidden.

[hvelarde]

@fredvd I fixed that for Plone 5.1

[thet]

Closing this, because following the discussion and linked PR/issues it looks like this issue being fixed.
Reopen if not.

[hvelarde]

it's not, but I'll create a new one later explaining what's missing; then we can close this one.

[hvelarde]

superseded by #1908.