Alain Schlesser 3:30 pm on December 3, 2018
Tags: , ,   

PHP Meeting Recap – November 26th

This recap is a summary of our previous PHPPHP 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.

Chat Summary

  • @schlessera introduced the idea of using the concept of “feature flags” to be able to commit experimental code to be tested 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. without immediately affecting everyone by default. Features hidden behind these feature flags would be opt-in through a mechanism like a setting in wp-config.php. The WP BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. Tester 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 could maybe be updated to provide a graphical interface to enable such feature flags.
  • The general format for feature flags in the wp-config.php could be something like the following: 
    define( 'WSOD_PROTECTION', getenv( 'WSOD_PROTECTION ) || false );
  • This allows for direct hardcoding of the value, as well as for passing it in via the server environment.
  • Discussion revolved around whether such a “feature flag” system would actually improve anything. For code to be considered “committable” to trunk under a feature flag, conditions would probably be the very same than for it to be committable to trunk directly.
  • @nerrad is concerned about the code churn that such feature flags could add to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development.
  • @sergeybiryukov is concerned that feature flags would create a new precedent in WordPress and would prefer to have us either commit the required hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. into Core to provide WSOD protection through a plugin, or to iterate directly in trunk as this has been done before the advent of feature plugins.
  • An alternative approach would be to make branches available through the WP Beta Tester plugin. However, branches are hard to keep in sync with trunk, especially in SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase..
  • @afragen will experiment with changes to the WP Beta Tester plugin to see how feature flags or branches could be handled.

Post-meeting update

Next week’s meeting

  • Next meeting will take place on Monday, December 3rd, 2018 at 15:00 UTC in #core-php.
  • Agenda: WCUS in-person opportunities planning.
  • 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, #summary