Everything cool and wrong about upcoming WordPress 4.7

WordPress 4.7 has been announced for christmas this year and it will have great changes for developers. It finally cleans up some things and not only have a hyped Twentyseventeen theme. I reviewed the commits and like to share with you what is new and what might break your site.Read the more up to date and famous one afterwards!
WordPress 4.7: Custom bulk actions, Theme inheritance and more
Open in new tab for later

Nice shiny code in the upcoming WordPress 4.7

Some in the community complain about bad code and sometimes it really hurts my eyes too. But while reading the commits I found some interesting approaches to clean up everything. Read on to see how the code gets better.

WordPress wants to get rid of global variables

Usually you and the whole WordPress-Core-Team does this whenever they need a query:

global $wpdb;
But this is no longer needed in query objects. Finally the database layer gets injected into the object itself. This is the great work of Scott Taylor who removed some “global $wpdb” statements:

Scott Taylor on 18.08.16 at 20:20

Query: add a `protected` field, `$db`, (composition, as it were) to `WP_*_Query` classes to hold the value for the database abstraction, instead of importing the `global $wpdb` into every method that uses it. Reduces the number of global imports by 32.

So after WordPress 4.7 on you can use the protected $db field

$this->db->posts // to get the name of the posts table

I hope for a getter because right now this field is protected and does not really have any advantage for non-core developer. It is injected in some query classes:

  • WP_Comment_Query
  • WP_Meta_Query
  • WP_Network_Query
  • WP_Site_Query
  • WP_Tax_Query
  • WP_Term_Query
  • WP_User_Query
  • WP_User
  • wp_xmlrpc_server

Functions instead of global variables

Just like the above refactoring a global variable has been replaced by a function. Seems like a general approach

45cd115 Scott Taylor on 22.08.16 at 06:36

Media: add a function, `wp_get_additional_image_sizes()`, that wraps the retrieval of the global `$_wp_additional_image_sizes`. Removes 6 global imports.

Soon with WordPress 4.7 you can replace every global $_wp_additional_image_sizes with a simple wp_get_additional_image_sizes(). This is one of hopefully many commits about to come from Scott Taylor.

Functions instead of constants: wp_doing_ajax()

Plenty of nice commits about global variables and this one finally replaces the constants too:

3aee745 Scott Taylor on 23.08.16 at 16:32

AJAX: add a new function, `wp_doing_ajax()`, which can replace… (wait for it…) `DOING_AJAX` checks via the constant.

Props Mte90, sebastian.pisula, swissspidy.

So you no longer need to ask for DOING_AJAX but instead:

if ( wp_doing_ajax() ) // ...

First steps for autoloader: Classes get their own file

Some first steps were made to achieve an autoloader and better separation of concerns. Some classes have been moved into their own file:

  • _WP_Dependency
  • WP_Error
  • WP_Query
  • WP_MatchesMapRegex
  • WP_Text_Diff_Renderer_inline
  • WP_Text_Diff_Renderer_Table
  • WP_Session_Tokens
  • WP_User_Meta_Session_Tokens
  • WP_Feed_Cache
  • WP_Feed_Cache_Transient
  • WP_SimplePie_File
  • WP_SimplePie_Sanitize_KSES

and more. This is a really great change and I like to see more of these. And there is a commit that removes all require and includes of classes. They should be replaced by an autoloader but unfortunately it breaks WordPress in some PHP versions.

Keep going Core-Team! We all love to see that change.

Changes you should be aware of

Negative paging in queries leads to 404

Thanks to Boone Gorges the paging in queries now pays attention to negative or non-scalar values:

This change has been due to invalid values:

f05beeb Boone Gorges on 20.08.16 at 04:31

Query: Non-scalar and negative values for ‘p’ should always result in a 404.

Actually the problem was that negative values will be transformed into positive ones (see Issue 33372). So instead of fixing that or allowing negative numbers an error will be thrown leading to a 404 page.

If you rely on that or have a plugin that uses negative numbers or even strings for pagination then rest assured that it might break and fall into a not-found site.

WordPress consciously breaks things

Imagine you require the file “wp-includes/class-feed.php” because it has some functionality you need in your plugin. For example if you use the SimplePie Framework or just the feed cache. With some upcoming WordPress your plugin will break because the file has been deleted.

Some files with only deprecated functions still stay in the core and other almost empty files are still there. But others just got deleted without concerning any BC. Removing this file means you break something somewhere in the internet and one of the 26% could be affected.

There are more BC breaking changes like that in other classes and functions. It is the biggest fiddle (at least for me) why sometimes radical changes are made but other crap stays in the core for years.

If you know why then please leave a comment.

What the code?

While reading the code I found out, that core committer don’t really clean up things and just pass them thru. Like these little things that made my developer heart bleed:

for ( $i = 1, $c = count( $levels ); $i <= $c; $i++ ) {
 $descendant_ids = array_merge( $descendant_ids, $levels[ $i ] );
}

Oh yes. This $c has to be in the for loop. Sure – not. Anyway, how about a foreach ?

This is nothing new in the code and ignores every coding standard in the world 😛 underscore for public functions (see wpdb):

public function _escape( $data )

Sometimes you see totally unnecessary commits that turn good code into unreadable. But the codex says no magic or fancy code so please …

array(
  'url' => urlencode( $permalink ),
  'format' => ( 'json' !== $format ) ? $format : false,
  // the above was a clean if-statement before ...
)

Personal comment

Things got cleaned up and this is something every developer likes. But there are changes that break the backward compatibility, like always. On the one hand it is a principle of WordPress to keep compatibility and on the other hand commits always contain some breaking changes. I still don’t know what I should think of it except that I hope for some proper versioning semantics some day that show such changes.

But for now I look forward to WordPress 4.7 as a very cleaned up system and finally an Autoloader!

Leave a Reply

Your email address will not be published. Required fields are marked *