WordPress.org

Making WordPress.org

Opened 2 months ago

Closed 2 months ago

#4159 closed defect (invalid)

Short echo tag ("<?=") tag must be allowed for use in templates

Reported by: KestutisIT Owned by:
Milestone: Priority: normal
Component: General Keywords:
Cc:

Description

In the MVC+Templating world, all new code does have template separation from the code.
So in templates with template-like syntax, which uses "if(STATEMENT):", "endif;", "foreach(..):", endforeach;" - and that does make the code more compact and easier to read for web-designers, the short echo tag - "<?=" have to be allowed as well. It as endorsed by the Rasmus Lerdorf - the creator of the PHP language - that's why it is always available since PHP 5.4.0. And WordPress is officially announced that it is dropping the support of all older versions prior PHP 5.6.0 since this April.

So in a template file with template-like syntax, i.e.
/wp-content/plugins/<PLUGIN_NAME>/UI/Templates/Admin/Item/Shared/ItemsPartial.php
this should be allowed:

<?php foreach($items AS $item): ?>
<div class="item-title"><?=esc_html($item['item_title']);?></div>
<div class="item-description"><?=esc_br_html($item['item_description']);?></div>
<?endforeach; ?>

And in this the Core Contributors handbook there has to be changes made to the Shorthand tags section: https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#no-shorthand-php-tags

Motivation

  1. The creator of PHP language - Rasmus Lerdorf - endorses the shorthand <?= tag. He claimed that in public in one of his talks on the (then soon to be released) PHP 5.4. If not the Rasmus, we would never have the PHP as most popular language in the world, and it became so popular just because of the Rasmus needs to get things start easy, easy to read, and feel happy - all the coding standards has to help us, not to make us hate them.
  1. That is why since PHP 5.4.0 the <?= tag is always available.
  1. It was mostly done because by over-viewing many of projects with pre-PHP 5.4, the <?= tag is used in the View of an MVC application but <?php ... ?> is used in the non-view files.
  1. The primary issue with tag (<?) was because was used by another syntax, XML. With the option enabled, you weren't able to raw output the xml declaration without getting syntax errors for this code: <?xml version="1.0" encoding="UTF-8" ?>.
  1. Although <? causes conflicts with xml, <?= does not.
  1. Prior to PHP 5.4 - the php.ini options to toggle it on and off were tied to [short_open_tag](http://www.php.net/manual/en/ini.core.php#ini.short-open-tag), which meant that to get the benefit of the short echo tag (<?=), you had to deal with the issues of the short open tag (<?). The issues associated with the short open tag were much greater than the benefits from the short echo tag.
  1. Starting from PHP 5.4 - the short echo tag has been re-enabled separate from the short_open_tag option. I see this as a direct endorsement of the convenience of <?=, as there's nothing fundamentally wrong with it in and of itself.
  1. Last December WordPress core contributor officially announced that starting this April, WordPress is dropping the support for all older versions prior PHP 5.6.0. For more information please read the post at w.org named "[Updating the Minimum PHP Version](https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-version/)".
  1. The oldest version of PHP that still gets security fixes is the PHP 5.6. In 2020 the majority of hosting providers and stacks like XAMPP will start offering only offer the PHP7. The PHP.net fully supports only PHP 7.2+ as of today.

Additional notes

  • The BAD is only the <? tag.
  • The GOOD are both - <?php and the <?= tags. Just first one is dedicated to use on code files, and the second one - in template files to output quickly single elements in a compact & easy-to-read, manner.

Change History (7)

#2 follow-up: @Otto42
2 months ago

  • Milestone Q1 deleted
  • Resolution set to invalid
  • Status changed from new to closed

This is the meta.trac, where we track tickets related to changes on WordPress.org or other properties. We don't determine the standards used here.

Core standards and such should be discussed on the relevant make blogs or in team chats.

#3 in reply to: ↑ 2 @KestutisIT
2 months ago

  • Keywords 2nd-opinion added
  • Resolution invalid deleted
  • Status changed from closed to reopened

@Otto42 , I understand that you are many years commiter here, but for other people you can give more support/help. It took A LOT of time to create this ticket and write it's content, as well as I did read the manual about meta trac and core track, and I did not found any better place to fit this request. I don't use chat apps, and it is hard for me to be on scheduled time.

So you say:

" on the relevant make blogs "

Which blogs exactly? There is no blog for coding standards. There is some posts that are couple years old, will anybody read the 'comment' out there?

I also check the core trac - it allows me to add a tag on 'coding-standards' but that place is for report of some kind of WordPress feature that is not compliant to given standard, it is not about issues that are in between PHP.net, where Rasmus endorses something, and W.org, where the coding standards page was last updated probably before PHP 5.4.0 release date, and that's why that scope is outdated.

I don't mind that you would close the ticket once again, but please then clearly give me a link of exact place where should I create this exact ticket with ALL the resolution described with all these steps.

Thank you.

P.S. Just feeling a bit depressed after putting so much effort to suggest something, when that gots rejected by 1 sentence without any links or so.

P.P.S. I've added "2nd Opinion" keyword, if you don't mind, as I personally don't see a place where would the ticket about issues with coding standards would fit perfectly, what would sum up to solution, that you may need to be more flexible and allow this ticket to be in a place, where it is closest for that task (but may not be a perfect fit for it).

Replying to Otto42:

This is the meta.trac, where we track tickets related to changes on WordPress.org or other properties. We don't determine the standards used here.

Core standards and such should be discussed on the relevant make blogs or in team chats.

Last edited 2 months ago by KestutisIT (previous) (diff)

#4 follow-up: @Otto42
2 months ago

Well, I would say that you would likely want to discuss changes to the coding standards with the core team, probably in one of the scheduled developer chats.

You're free to reference this ticket, and reopen it when you have actual tasks to be done by the meta team. However, you're referring to changing the core handbook, which isn't something the meta team maintains, as it's in the purview of the core team. All handbooks are owned by their respective teams and they have the ability to change their contents directly.

More to the point, as far as changing the actual standard goes, this type of change isn't a technical change, nor it is something you simply do "with a ticket" in the first place. You talk to the actual people involved, and have a discussion, and come to agreement over time. Your proposal to allow short tags is understood, but it goes against what the current standards are and have been for the past 15+ years of WordPress history. So yes, talking to others about it during regular discussions would seem more appropriate than simply making a ticket for it. Tickets aren't the best place to decide policy, they're places where we discuss technical details and implementation.

I won't close this ticket, if that somehow upsets you, but since tickets can be re-opened when necessary, then you shouldn't take a closed ticket as upsetting. Instead, you should go and participate in the discussion and development process, and come back here if and when you have an actual agreed upon plan of action. At that time, when there is widespread agreement on the change, then yes, a ticket for discussing what specific changes to make to implement the new standards and policies would be appropriate.

#5 @Otto42
2 months ago

If it helps, the meetings list can be found here:

https://make.wordpress.org/meetings/

If I was proposing something along these lines, then I'd probably join the next "Core Development Weekly Chat" happening next Wednesday, in the #core channel on the WordPress Slack, and bring it up there.

#6 in reply to: ↑ 4 @KestutisIT
2 months ago

Replying to Otto42:

Well, <..>

Thank you, @Otto42 for your feedback and information. It is valuable to me. :).

Last edited 2 months ago by KestutisIT (previous) (diff)

#7 @dd32
2 months ago

  • Component changed from Handbooks to General
  • Keywords needs-codex 2nd-opinion removed
  • Resolution set to invalid
  • Status changed from reopened to closed

I'm closing this ticket for reasons previously outlined, and there being no Meta tasks needed here.

  • In the event the Core team decides to change the coding standards for WordPress Core they can update the Core Handbook.
  • Plugin authors can use short tags if they wish already, they're not held to the same PHPCS rules of Core unless they choose to, they may use whatever MVC framework they want, and can require the usage of PHP 7.3 if they so desire.

Replies can still be added to this ticket if needed, and if required the ticket will be re-opened by a meta team member, but please consider adding a comment outlining why a meta ticket is needed prior to doing so.

Note: See TracTickets for help on using tickets.