This recap is a summary of our previous PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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.
The agenda was to discuss which version to include the notice in and how to deal with the dismissal functionality of the notice.
- After requesting feedback in the #core channel, there were some concerns expressed about publishing the notice in a minor release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. (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 A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., it can be reevaluated whether it should be merged in the minor release branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..
- 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 (and super admin) notice, but as a dashboard widget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user..
- That approach sounds promising too, so @flixos90 added he’ll work on an alternative patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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:
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 An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket Created for both bug reports and feature development on the bug tracker. or the individiual pull requests if applicable.