PHP Meeting Recap – February 12th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

The agenda was to discuss which version to include the notice in and how to deal with the dismissal functionality of the notice.

Release Plan

  • After requesting feedback in the #core channel, there were some concerns expressed about publishing the notice in a minor release (like 4.9.5), particularly because a notice like that suddenly being thrown from a minor release may seem weird.
  • However the amount of users affected by this would be very low, since only users on PHP 5.2 are initially targeted.
  • Releasing sooner than later would allow for quicker feedback and stats, to iterate based on those.
  • The decision was to go with the 5.0 release for now. When the notice has been merged into trunk, it can be reevaluated whether it should be merged in the minor release branch.

Notice Dismissal

  • Four initial possibilities were suggested to be considered:
    • The notice shouldn’t be dismissible at all.
    • The notice should be permanently dismissible.
    • The notice should be dismissible, but come back every month.
    • The notice should be dismissible, but come back every core update.
  • @clorith expressed concerns about heavier support load when bringing the notice back “unexpectedly”, like after a month. On the contrary, the notice being persistent is part to the solution, so people trying to get rid of it otherwise are doing it wrong.
  • If it needs to be brought back, that should preferably happen per (major) update.
  • Option 4 ended up to be the most viable one out of the suggestions.
  • @SergeyBiryukov then suggested to check how the existing Browsehappy notice does that. It was quickly discovered/remembered that the Browsehappy notice is not actually implemented as an admin notice, but as a dashboard widget.
  • That approach sounds promising too, so @flixos90 added he’ll work on an alternative patch for an implementation as dashboard widget.

Next week’s meeting: Admin Notice vs. Dashboard Widget

The agenda for next week is to decide on one of the following approaches to pursue:

Screenshots

Servehappy Admin NoticeServehappy Dashboard Widget

Benefits of admin notice

  • Very visually prominent.
  • Quick overview of details, layout similar like known welcome notice.

Benefits of dashboard widget

  • Not as easy to accidentally click away without looking, as fully dismissing requires to open screen options first.
  • Only shown in dashboard which appears to be more appropriate than everywhere.
  • Follows Browsehappy implementation, so less new code and tweaks required.

If you have any suggestions or feedback before the meeting, please comment on the Trac ticket or the individiual pull requests if applicable.

#core-php, #servehappy