I was auditing a custom theme for a high-traffic WooCommerce store recently, around 5k transactions a day, and the template files were painful to look at. Every line carried the full <?php echo esc_html( $var ); ?> syntax. The look of it was the smaller problem. Finding a logic error in those files took far longer than it should have, and with hundreds of template overrides, readability is part of keeping the code safe.
For years the WordPress coding standards flatly banned the PHP short echo tag, and the reasoning held up at the time. Before PHP 5.4 that tag could be switched off in the server configuration, so a site that moved to a host with short_open_tag disabled would print its own code as plain text on the front end. On a project back in 2013 I spent a whole weekend “fixing” those tags in a legacy plugin to get it past a linter, and deleted a closing brace somewhere along the way. That was a weekend spent on a problem already on its way out.
Why the WordPress coding standards are changing
PHP moved on. Since version 5.4 the short echo tag <?= is always available, whatever your php.ini says. WordPress now requires PHP 7.2 at minimum, and plenty of us are pushing for 8.0 and up, so the old security argument has nothing left behind it. A proposal on the Make WordPress Core blog, at https://make.wordpress.org/core/2025/12/05/coding-standard-proposal-allow-the-use-of-the-php-short-echo-tag/, would finally allow the tag for single statements.
This is not about laziness. It cuts the noise in a template. When there is one variable to print, the shorthand reads cleaner and leaves less to mistype. In practice:
<?php
/**
* Example of the bbioon_display_price function.
*/
?>
<div class="bbioon-price">
<?= bbioon_get_formatted_price( $product_id ); ?>
</div>The proposal is pragmatic. Nobody has to go back and rewrite existing core files, which would only produce merge conflicts for no benefit. It stops penalizing developers for using something the wider PHP community has treated as normal for over a decade, and it applies to new official themes and patches.
Managing standards in your own projects
If you manage a team and want one consistent style, none of this forces your hand. Keep the short echo tag forbidden by adding a rule for it to your phpcs.xml, and the linter carries on rejecting it.
- The short open tag
<?stays forbidden, and should. - The short echo tag
<?=is for single statements only. - Existing core code is left alone so nothing breaks.
Running legacy systems and modern standards at once gets complicated fast. If you are tired of debugging someone else’s mess and want clean modern code behind your site, drop my team a line. We have probably seen it before.
Are you switching to shorthand echo tags on the next project, or staying with the full syntax out of habit?
