The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
We focused on the next sections of the requirements document, Section 3 “Current Status”, and Section 4 “Project Goals”.
Section 3. Current Status
Finalized description of existing APIAPIAn 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. features and limitations
Section 4. Project Goals
We continue refining the definitions of our MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia (minimum viable productMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia) a.k.a. Version 1.0
We outlined important research the project should include
We noted importance of retaining backwards compatibility of notifications handling
At the close of the meeting, @hrmervin posed the question of how/if GutenbergGutenbergThe 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/ methods of notification handling can influence this project, either in short term or long term.
In WordPress 5.3, a new screen has been introduced to help ensure the site’s administration email remains accurate and up to date. The site’s adminadmin(and super admin) email (as defined when installing WordPress, and found on the Settings > General page) is a critical part of every WordPress site. This new screen will help site owners remain in full control of their site, even as years go by.
How does this work?
By default, administrators will see a screen after logging in that lists the site’s admin email address once every 6 months.
They are presented with 4 actions:
The site’s email is verified as correct: After clicking “The email is correct” button, the user is taken to the Dashboard with an admin notice saying “Thank you for verifying”. The screen will be hidden for 6 months from all administrators.
The site’s email needs to be changed: After clicking the “Update” button, the user is taken to the Settings > General page where they can update the site’s email address. Administrators will be presented with the verification screen the next time they log in.
The user clicks “Remind me later”: the user is taken to the Dashboard. Administators will see the screen again after 3 days have passed.
Back to “Site Name”: When this link is clicked, the user will be taken to the site’s home page. Administrators will be presented with the verification screen the next time they log in.
Available Actions and Filters
There are a few action hooksHooksIn 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. on the verification page that developers can use to customize the screen.
admin_email_confirm – Fires before the admin email confirm form.
admin_email_confirm_form – Fires inside the admin-email-confirm-form form tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), but before any other output.
A new action hook after the form was not introduced. Instead, use the login_footer action, which is called just after the closing </form> tag. The if ( 'confirm_admin_email' === $_GET['action'] ) conditional can be used to check that the email verification screen is being shown.
One new filterFilterFilters 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., admin_email_check_interval, has also been introduced. This filter can be used to change the frequency that administrators should see the verification screen.
The following example changes the interval from the default of 6 months to 2 months:
The way the edit lock works now, if you close your browser with the post open, the lock will stay in effect until it times out. Might it not be better if we shortened the edit lock time to something like 120 seconds and kept it locked via an XHR every 90 seconds that the edit screen for that post is open?