Tag Archives: servehappy

Alain Schlesser 2:58 pm on July 2, 2018
Tags: , , servehappy,   

PHP Meeting Recap – June 25th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • We first discussed terminology: are we talking about “PHP upgrades” or “PHP updates“? We are currently mixing both of these in a rather random fashion. We then decided that we’ll stick to “PHP updates” and “updating PHP” from now on, because:
    • The distinction between “update” and “upgrade” is lost on most users anyway, so we should only use one in user communication.
    • “Upgrade” implies an improvement. An “update” means getting it to the latest state. While it will provide improvements, doing an “update” is actually what we’re after, even if no improvements are to be had.
    • “Update” better fits with the rest of WP communication as well.
  • The following changes will be made to make all project deliverables consistent with the above decision:
    • Patches in #43986, #43987 and #44350 will be changed to only refer to “updates”.
    • The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. capability upgrade_php will be renamed into update_php.
    • The support page will be renamed from Upgrading PHP to Updating PHP, and the page’s content will be adapted accordingly.
    • The support page’s URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org will be changed to https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
    • A redirect will be done from https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
  • Then we quickly discussed the #design <=> #marketing collaboration with @jaymanpandya and @alexdenning. They have already made contact and will keep us updated on their collaboration progress.
  • Finally, we discussed our new goal of “sandboxing” the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme’s PHP code in some way to make sure users cannot be locked out of their site through a white-screen-of-death (WSOD).
  • Current observations:
    • Exceptions don’t help, as they are not fully integrated into the error handling at PHP 5.2.
    • We can use a shutdown handler to detect fatal errors and know where they were triggered: https://3v4l.org/4jWAs .
    • Such a shutdown handler could record a fatal error, and the next page request could then detect a recorded fatal error and decide based on some heuristics whether to initiate “safe mode”
    • We cannot just act on plugin activation/deactivation, as this will still take the site down if we update PHP.
    • We cannot disable a single plugin, as we cannot reliably detect who the actual culprit is in all cases.
    • We might be able to disable a single plugin in those cases where we hit a parse error in a file of a plugin.
  • A TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. was created for this: #44458 – Catch WSODs and provide a means for recovery for end users

Next week’s meeting

  • Next meeting will take place on Monday, July 2nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on the avoiding WSODs in PHP.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Alain Schlesser 10:58 am on June 4, 2018
Tags: , , , servehappy,   

PHP Meeting Recap – May 28th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • We started with discussing TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. behavior: while @afragen added actions to make the new blocking functionality extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software., @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patchpatch 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. that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Felix Arntz 2:45 pm on April 14, 2018
Tags: , , servehappy,   

PHP Meeting Recap – April 9th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • The design meeting had not taken place at the time to discuss design of the nag, but the topic was discussed later the week, so next week there will be feedback to review. Screenshots of both the expanded and collapsed state of the dashboard widgetWidget 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. are present on the ticketticket Created for both bug reports and feature development on the bug tracker. #41191.
  • Via the Automattic editorial team, an updated version of the copy for the nag was suggested and uploaded as a patch.
  • The suggested changes were met with consent, especially considering the removal of a rather redundant sentence to continue reading and a fragment focusing on the people working on WordPress (as they are not the group the widget is targeting).
  • The new “PHP Upgrade Required” was approved as well. While mentioning the term PHP which may initially be unknown to the site owner, it clearly identifies the problem, and via the word “required” it is a clear call to action.
  • The one sentence questioned was the following:

    The instructions we provide will guarantee a secure, painless update.

    Particularly the word “guarantee” may be misleading as it is impossible to guarantee a painless update process. @nerrad shared multiple alternatives which he also added to the ticket. There was consent that at least “guarantee” should be replaced with “help with”.

  • An important thought that was emphasized again was that, while upgrading PHP is not that trivial, there needs to be a positive attitude and expressions being used about that in order to motivate site owners to proceed. It must not be too euphemistic though – updating PHP is undoubtedly more complicated than updating a browser for example.
  • Except for the one sentence it was agreed that the revised version is more accurate, on-point and in line with the wording used in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. otherwise.

Next week’s meeting

  • Next meeting will take place on Monday, April 16th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss design feedback for the nag, as expressed in their meeting and on the ticket.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Felix Arntz 9:42 am on April 3, 2018
Tags: , , servehappy,   

PHP Meeting Recap – April 2nd

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • Design feedback was not yet available to review, so this was postponed to next week.
  • Per #41191, @pento will ask the Automattic editorial team to review the wording.
  • @markjaquith brought up that the large amount of text currently in the nag may be too much. Since the PHP upgrade education page already contains detailed information, the nag should be more on point. Key points are:
    • PHP runs your site.
    • Your PHP is outdated.
    • Updating makes your site faster and more secure.
  • @flixos90 suggested to compare the nag with the one from Browsehappy which is way shorter. While upgrading PHP is not trivial, it should be possible to shorten the current copy so that it is only a bit longer than the Browsehappy message. Something like the following may work already:

    It looks like your site is using an outdated/insecure version of PHP. PHP is the programming language that WordPress is built on. To make your site faster and keep it secure, please upgrade the PHP version on your webserver.
    Learn how to upgrade my PHP (link)

  • It’s important to highlight the performance aspect of upgrading, not only the improved security.
  • @afragen shared his proof-of-concept for rejecting plugins that require a higher PHP version than available. While a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation would need to cover much more than the functionality present, it is a good source to start working from, and some of the code or ideas may be reused in the implementation for #40934.

Next week’s meeting

  • Next meeting will take place on Monday, April 9th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss design feedback and wording of the nag.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Alain Schlesser 8:31 am on April 2, 2018
Tags: , , , servehappy,   

PHP Meeting Recap – March 19th & 26th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat log from March 19th
Chat log from March 26th

Chat Summary

Dashboard widgetWidget 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. (#41191)

  • The voice of the widget text has been adapted to better match the overall WordPress feel.
  • The accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) concerns that were raised have been addressed.
  • The widget currently looks like this:
  • The TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. was flagged for ui-feedback and we are now waiting for the #design team to be able to go over the ticket. Once all of their feedback has been processed and incorporated, the version in trunk will be ready to discuss backporting it to the next minor releaseMinor 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. (4.9.6).

PHP version requirements for plugins & themes (#40934)

  • @sergey intends to work on a first implementation of the above ticket.
  • To start work on this ticket, we created a new branchbranch 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". servehappy-require-php in the https://github.com/wp-core-php/wordpress-develop repository (link to branch).
  • Anyone wanting to contribute to this repository should DM @schlessera to be added as a contributor (with an email or GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ username).
  • @afragen has built a first proof-of-concept to check a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’s headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. requirements: https://github.com/afragen/requires-php. Testing and feedback are welcome!

Next week’s meeting

  • Next meeting will take place on Monday, April 2, 2018 at 15:00 UTC in #core-php.
  • Agenda: [Go over #design feedback and] discuss how to proceed with plugin requirements.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Felix Arntz 7:46 pm on March 3, 2018
Tags: , , servehappy,   

PHP Meeting Recap – February 26th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • The agenda for the meeting was to discuss the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoint for which a first version was introduced the previous week.
  • It was ensured that the endpoint parses PHP versions correctly and allows for flexibility by parsing out the actual version number from strings which may contain additional environment-specific information.
  • Some concerns regarding the structure of the response were expressed, particularly related to redundancy, future maintainability and inconsistencies.
  • By the end of the meeting, it was agreed to go with the following response structure:
    • recommended_version – string – The PHP version recommended by WordPress
    • is_supported – boolean – Whether the PHP version is actively supported
    • is_secure – boolean – Whether the PHP version receives security updates
    • is_acceptable – boolean – Whether the PHP version is still acceptable for WordPress
  • It was also decided to remove all IP address-related functionality, as it is unlikely that those will be needed in the future. Detecting hosts by IP address and maintaining host-specific data via the API would be a huge maintenance burden, and additionally passing the IP address would overcomplicate the current efforts by having to deal with possible privacy concerns.

Call for Testing

Since the meeting, the API endpoint has been updated to use the aforementioned response data structure, and an updated patchpatch 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 the PHP nag in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., implemented as a dashboard widgetWidget 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. like previously decided, is ready to be applied.

Please thoroughly test the API endpoint and patch. The API is already live, and the current plan for the patch is to commit it to core next week.

  • The API endpoint is available at https://api.wordpress.org/core/serve-happy/1.0/, and it requires a php_version query parameter to be passed.
  • The patch for the core nag is available at https://core.trac.wordpress.org/attachment/ticket/41191/41191.6.diff, making use of the API endpoint. When applied and your installation is not on PHP 5.2, you can “simulate” the behavior by going into the src/wp-admin/includes/dashboard.php file, looking for the wp_check_php_version() function and temporarily hard-coding ‘5.2’ in there instead of the actual PHP version. For the related ticketticket Created for both bug reports and feature development on the bug tracker., see #41191.

Next week’s meeting

  • Next meeting will take place on Monday, March 5, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the patch for the core nag.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Alain Schlesser 3:52 pm on February 26, 2018
Tags: , , servehappy,   

PHP Meeting Recap – February 19th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • Main topic for this meeting was to discuss the two different implementations of the servehappy notice we have so far:
    • an adminadmin (and super admin) notice that appears at the top of all pages;
    • a dashboard widgetWidget 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 only appears on the dashboard.
  • @flixos90 quickly described the main benefits of the alternative dashboard widget approach:
    • it requires less logic;
    • it is harder to unintentionally hide;
    • it matches what the browsehappy project did.
  • We discussed how best to set the priority of the widget, so it won’t be displayed below the fold. @clorith noted that adding it to dashboard.php would ensure it is always shown first, just like the browsehappy one.
  • Those present during the meeting unanimously voted for the dashboard widget, instead of the admin notice. We thus decided to go with the alternative approach of the dashboard widget moving forward.
  • We decided to work on getting this into trunktrunk 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. for now, with the option of backporting it to the next minor releaseMinor 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. if there’s consensus later on.
  • The reshowing of the widget should not be included in the code for now, but could be part of the “database migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies.” code that gets run on updates. This lets us defer the decision of when to reshow.
  • The discussion then moved on to a ServeHappy APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoint on wp.org that could be used to dynamically control the behavior of the dashboard widget.
  • @flixos90 has implemented a first version of the API endpoint following the details we’ve discussed, and it is already available right now: https://api.wordpress.org/core/serve-happy/1.0/?php_version=5.2
  • The information that is sent to the ServeHappy API endpoint (PHP version + indirectly IP address through server access logs) might have implications on GDPR compliance. We should raise this concern in the #gdpr-compliance channel.
  • We discussed how to let hosts provide upgrade information. A mechanism using constants or filters would be preferable to providing this through the API endpoint, as we’d want to decentralize this information and not maintain it ourselves.

Next week’s meeting

  • Next meeting will take place on Monday, February 26, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the new API endpoint.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Felix Arntz 6:43 am on February 13, 2018
Tags: , , , servehappy,   

PHP Meeting Recap – February 12th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

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 releaseMinor 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 trunktrunk 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 branchbranch 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"..

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 coreCore 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 adminadmin (and super admin) notice, but as a dashboard widgetWidget 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 patchpatch 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:

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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. or the individiual pull requests if applicable.

#core-php, #php, #servehappy, #summary

Alain Schlesser 12:27 pm on January 29, 2018
Tags: , , servehappy,   

PHP Meeting Recap – January 22nd

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.

Chat Summary

  • The #design team has acknowledged our call for design help for servehappy and added a corresponding task in their Trello board. @jaymanpandya has stepped forward and was assigned this task.
  • We summarized again how we’re envisioning the site:
    • stand-alone design, as including it into the wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ page design would reduce the impact and hinder proper optimization;
    • targeting site owners, with the option to make the content adapt to URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org parameters for more precise targeting;
    • focused on easy consumption and avoiding overwhelm, with additional, more detailed content available as needed;
    • hosted on wordpress.org infrastructure and showing a small mention to the wordpress.org project;
    • not collecting usage data or feedback through the site, as that will likely get vetoed.
  • @jaymanpandya is an experienced UXUX User experience designer and will work on a first set of mockups so that we can get a feel for how this might work as a real site.

Next week’s meeting

  • Next meeting will take place on Monday, January 29, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss UX mockups and hosting situation.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

Alain Schlesser 3:09 pm on January 9, 2018
Tags: , , , servehappy   

Servehappy Roadmap

The group of people in the #core-php channel has been discussing and planning a project codenamed “servehappy” for some time now. We are at the point where we think that our plan has matured enough to present it to a bigger WordPress audience, in the hopes that we can get buy-in from more people to support or join our cause.

Goals

Primary Goal (long-term, indirect):

  • Reduce the number of WordPress installations running on an unsupported PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher version

Secondary Goals (short-term, direct):

  • Make WordPress site owners aware that they are running an unsupported version of PHP
  • Educate WordPress site owners about PHP and its versions
  • Provide WordPress site owners with tools and resources that enable them to update their site’s PHP version

The primary goal is what we’re aiming at. However, this is not something we can directly act upon. The secondary goals are the actionable elements that are in line with the primary goal.

We are confident that we can produce a definite positive impact on the primary goal through a concerted effort on these secondary goals.

Current State

A good overview of the current state can be found in the project repository’s README.md file.

 

Mockup of the ServeHappy page, showing collapsible sections of content.

ServeHappy page mockup
Click to enlarge

 

Through our regular weekly meetings we’ve made good progress on putting together the content for an informational page called “servehappy“ (in reference to the “browsehappy” page that helped get rid of legacy web browsers). The page should ideally be hosted on the wordpress.org infrastructure, similar to how the browsehappy page is stored.

 

Mockup of the WordPress admin dashboard, showing an admin notice warning about the PHP version.

Adminadmin (and super admin) notice mockup
Click to enlarge

 

This page is meant to be linked to by admin notice(s) in the WordPress admin dashboard that will appear for people with unsupported PHP versions. Work on implementing these can start as soon as we have confirmation that the servehappy project should be further pursued.

 

Mockup of a plugin detail screen in the admin dashboard, showing a red "Cannot install" button and a link to the ServeHappy page.

PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party requirements mockup
Click to enlarge

 

Finally, we want to work on enforcing plugin/theme PHP requirements as they can already be stated in the plugin/theme metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. information. With time, this will provide developers with better control over their code base and incentivize site owners to keep up with the WordPress ecosystem’s evolution.

We’ve prepared a short overview document that details the core integrations and how they tie into the servehappy page.

As a side note, while working on the servehappy page content, we started collecting links to various resources that can be of use to people wanting to update their PHP version. These can be found in a separate servehappy-resources repository.

Project Progression

We intend to target only PHP 5.2.x initially, to not put too much pressure on the support channels of hosting providers. When a reasonable amount of time has passed and most of the initial updating effort has been completed, we can consider moving the needle up to PHP 5.3.x.

Provided that we have a clear roadmap, transparent communication and the patience to let site owners and hosters handle the updates in manageable intervals, this provides us with a tool to slowly catch up to PHP releases and reduce the currently growing gap between WordPress requirements and PHP versions.

Timeline

Here’s our current preliminary timeline:

Information Page on WP.org – Current Draft
– Trac ticket		 1st Quarter 2018
Admin Notice in Dashboard – Trac ticket 2nd Quarter 2018
Minimum PHP Requirements – Trac ticket 3rd Quarter 2018

Of course, these are only guesstimates. The actual development work involved makes this timeline easily possible, but what is time-consuming (and hard to predict) is the amount of discussions that are needed to find a concensus on all critical decisions.

Our Request

Before we invest more time into this project, we want to get a basic decision (in principle) about whether we should pursue or not.

  1. Is the servehappy project worthwhile and do we have a general buy-in from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. leadership?
  2. Can we make the servehappy project an official feature project?
  3. Information Page – Can this page be hosted on the wordpress.org infrastructure?
  4. Information Page – Who is responsible for the final editorial check?

To this end, we had the servehappy project added to the agenda of the upcoming devchat meeting on 10th Jan, 2018. This post was prepared to allow attendees of this meeting to get a quick overview of the project in preparation for the meeting.

#php, #roadmap, #servehappy