Skip file_exists check for core blocks in register_block_type_from_metadata

[spacedmonkey]

In the register_block_type_from_metadata function, there is a call to file_exists to see if the metadata file existing before registering. However, it is extremely unlikely the core blocks would not exist. As file lookups are expensive, saving 91 file_exists would improve site performance.

Trac ticket: https://core.trac.wordpress.org/ticket/58385

[spacedmonkey]

@gziolo Do you mind taking a look at my PR. It is very simple.

This makes sense to me. In the same vein of avoiding unneeded file_exists it looks like there’s one nearby in register_block_type:

​https://github.com/WordPress/wordpress-develop/blob/f5e657c281c28c1cbda5a71201f3f014fbe4e599/src/wp-includes/blocks.php#L539-L541

The check is extraneous there since it's going to be done in register_block_type_from_metadata. Does that seem right? Core blocks aren’t using that code path but plenty of third parties may be.

This makes sense to me. In the same vein of avoiding unneeded file_exists it looks like there’s one nearby in register_block_type:

​https://github.com/WordPress/wordpress-develop/blob/f5e657c281c28c1cbda5a71201f3f014fbe4e599/src/wp-includes/blocks.php#L539-L541

The check is extraneous there since it's going to be done in register_block_type_from_metadata. Does that seem right? Core blocks aren’t using that code path but plenty of third parties may be.

@stokesman Already done in ​https://github.com/WordPress/wordpress-develop/commit/537eb2145a356b471f474927ab8458ddef6802c1

True that it’s now side-stepped by core blocks but any calls to register_block_type with a string for the first parameter are checking file_exists and forwarding directly to register_block_type_from_metadata where it again checks file_exists. It seems like the first one can be dropped, no?

Do excuse me if it's not really related enough to be bringing up on this PR but it did seem so.