Ticket #9320 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 7 years ago

Add global status bar for site notifications

Reported by: limi Owned by: mj
Priority: n/a Milestone: 4.0
Component: General Version:
Keywords: Cc: plip-advisories@…

Description (last modified by limi) (diff)

Proposer: Alexander Limi
Seconder: Martijn Pieters

Motivation

A very common case for Plone sites is the need to have a message at the top of the site notifying people about upcoming downtime, maintenance or similar events. At the moment, everyone seems to customize their main_template or similar to render something at the top of every page in the site, but this has numerous issues — the text ends up in search engines, you're running with a customized main_template for the duration, etc.

Assumptions

We're making this as simple and stupid as possible — but it should probably still be implemented as a viewlet, so people can position it as they wish in the site layout.

Proposal & Implementation

  • I propose that we add a single field to the "Site" control panel that accepts raw HTML, so people have flexibility to add whatever is needed to communicate their message — mailto links, etc.
  • This field is then rendered using a simple async JS call for two reasons:
    • It won't end up in search engine indexes, which is beneficial
    • Adding a message to your site shouldn't invalidate all the cached pages
  • The shown message should have a hash associated with it, so you can close the message, and sets a cookie so the message doesn't show up again — similar to what we do on plone.org for IE6 users right now.

Deliverables

  • A new field in the Site control panel
  • JS for retrieving the status message asynchronously, and to set a cookie if you close the message — and check for the presence of this cookie when the JS to retrieve the message is executed.
  • Some basic tests that confirms that the status message shows up
  • Updated site admin documentation
  • Localization (only for the control panel field)

Risks

  • If we think that raw HTML for the global status message is too insecure, we can implement filtering. This would probably add a tiny bit of complexity, but I don't see why we would do this — if you have admin permissions, you can do way scarier things than insert some XSS code in the status message. :)
  • If we allow raw HTML, people may start abusing this field to add JS, CSS or similar to the site.
  • I'm not intimately familiar with viewlets, but there's probably an upgrade GS handler needed to add the viewlets to existing sites?

Participants

  • Martijn Pieters
  • Rob Gietema (backup for Martijn)
  • Alexander Limi (UI oversight, should be minimal needs on this PLIP, though)

Progress

We already have parts of this code running on plone.org; if you run IE6, you get a dismissable message that remembers that you have seen it. It has appropriate styling etc.

Change History

comment:1 Changed 7 years ago by limi

  • Priority changed from minor to n/a

comment:2 follow-up: ↓ 6 Changed 7 years ago by pupq

(Am I understanding properly that if you've "closed" this message, or don't have one, period, that this async call is not made? Otherwise, we'd be making this request for every view of every page, no? And that could have a signficant performance impact in exchange for feature that only some people would use only some of the time.)

If that's the case, then this seems +0.5 from integrators--it comes up once in a while (and people do now do the predictable template edit). This case seems much more common on intranets ("It's a snow day, don't come to work!"), so the cached-by-search-engine feature is almost never brought up as a concern. However, if this has all the features, and no performance impact for most people, the risk seems low and it does offer a benefit they can understand.

This would seem, though, like this could be handled as an add-on product (CMFSnowDay ;) ). Is this common enough to make core?

comment:3 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:4 Changed 7 years ago by limi

  • Owner set to mj
  • Description modified (diff)

Martin said yes, with the caveat that he might be short on time these days because of moving and stuff. I'm in the process of locating a backup person just in case.

comment:5 Changed 7 years ago by limi

Martijn, that is :P

comment:6 in reply to: ↑ 2 Changed 7 years ago by limi

Replying to pupq:

Am I understanding properly that if you've "closed" this message, or don't have one, period, that this async call is not made?

Correct. It would check for the cookie before making the async call.

comment:7 Changed 7 years ago by alecm

+1

Of course this still makes an extra async request on every page load when there is no cookie, even when there is no message to display. If you do a server side check in advance to prevent the async request when there's no message, then you lose the caching advantages. Since Google and other search engines are apparently doing some JS parsing/execution now, one of the advantages of using an async call may no longer be relevant.

comment:8 Changed 7 years ago by limi

  • Description modified (diff)

comment:9 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:10 Changed 7 years ago by MatthewWilkes

This feels like an add-on product to me.

FWT Vote: -1

comment:11 Changed 7 years ago by rossp

FWT vote: +1. I think this is valuable enough for site administrators that aren't integrators to make it available without having to add an egg.

comment:12 Changed 7 years ago by davisagli

FWT vote: -1. I also think this belongs in an add-on unless it can be implemented in a way that doesn't require an extra async request for every page load.

comment:13 Changed 7 years ago by calvinhp

FWT Vote: +1 I also agree with rossp on this one, we have seen many uses for this and would appreciate it being part of the core.

comment:14 Changed 7 years ago by raphael

FWT vote: -1 for Plone core -

+1 for add-on

comment:15 Changed 7 years ago by erikrose

  • The Site configlet is just where I expected this would be—right next to the "throw your JS in here" field—so color one user unastonished. :-)
  • What happens in Plone 5? It sounds like this should become a tile in a layout, editable through whatever the tile-editing UI ends up being.

I haven't run into this use case among our clients, and Joel's experience of a lack of demand for this carries a lot of weight with me—he sees a lot of folks. I'm on the make-it-a-plugin side of the fence, so my FWT vote is -1. Can't wait to recommend the plugin to people, though!

comment:16 Changed 7 years ago by esteele

  • Status changed from new to closed
  • Resolution set to wontfix

Rejected for Plone 4.0 by FWT vote. We'd like to see this as an add-on though.

comment:17 Changed 7 years ago by ldr

-1 for core, all those extra requests are bad

comment:18 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.