PHP Meeting Recap – September 24th

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

Update PHP Page

We first discussed the current implementation of the dynamic blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. we want to include at the top of the “Update PHP” page.

• @nerrad had already implemented a GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ block to provide this functionality. It has multiple fields in its sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. to allow adapting the text to display.
• @dd32 suggested looking into a hardcoded PHP template instead, to reuse Glotpress functionality for the translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. workflow. Otherwise, it is very difficult for translators to know when strings had been updated. Also, this would ideally go into the theme for the Support subsite, instead of 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, to isolate the changes to this subsite only.
• We mostly agreed that internationalization is easier with a hardcoded approach where the strings to localize are found in the code. @sergey pointed out that this is how all the content is done on the main 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/ site and linked to an example.
• The approach to take would be to create a page wporg-support/page-update-php.php and hardcode the content into that.
• This discussion showed that we wasted a lot of time (@nerrad invested up to 10 hours into the first iteration of the plugin), because the actual requirements were never mentioned before starting. We should think about how we can avoid situations like this in the future, making sure we don’t invest time in “non-options”.

WSOD Protection

We then moved on to discuss progress on #44458 – Catch WSODs and provide a means for recovery for end users.

• The current implementation is missing logic for themes and might not yet work correctly on multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site installations.
• @flixos90 will mention the ticketticket Created for both bug reports and feature development on the bug tracker. during the multisite meeting to look at what would be necessary for making it work with multisites.
• For themes, @afragen quickly tested what would happen when no theme at all would be loaded. The login screen and the adminadmin (and super admin) backend do not seem to be affected.
• For skipping to load a theme that throws errors, we can add an additional condition in the bootstrap code where WP decides whether to load the functions.php file or not.

Next week’s meeting

• Next meeting will take place on Monday, October 1st, 2018 at 15:00 UTC in #core-php.
• Agenda:
  • Discuss hardcoded approach to “Update PHP” page.
  • Collect feedback on multisite approach for WSOD protection.
• 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, #core-php, #php, #servehappy, #summary