WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 14 months ago

#42629 closed defect (bug) (fixed)

The function the_meta () outputs an empty list

Reported by: campusboy1987 Owned by: dd32
Milestone: 5.1 Priority: normal
Severity: normal Version: 1.2
Component: Options, Meta APIs Keywords: has-patch
Focuses: template Cc:
PR Number:

Description

Hello. The problem is that if the post has only protected arbitrary fields, the function the_meta () displays a list without li elements, which is not correct. I propose the following changes:

<?php
function the_meta() {
        if ( $keys = get_post_custom_keys() ) {
                $li_html = '';
                foreach ( (array) $keys as $key ) {
                        $keyt = trim( $key );
                        if ( is_protected_meta( $keyt, 'post' ) ) {
                                continue;
                        }
                        
                        $values = array_map( 'trim', get_post_custom_values( $key ) );
                        $value  = implode( $values, ', ' );
                        
                        $html = sprintf( "<li><span class='post-meta-key'>%s</span> %s</li>\n",
                                /* translators: %s: Post custom field name */
                                sprintf( _x( '%s:', 'Post custom field name' ), $key ),
                                $value
                        );
                        
                        /**
                         * Filters the HTML output of the li element in the post custom fields list.
                         *
                         * @since 2.2.0
                         *
                         * @param string $html  The HTML output for the li element.
                         * @param string $key   Meta key.
                         * @param string $value Meta value.
                         */
                        $li_html .= apply_filters( 'the_meta_key', $html, $key, $value );
                }
                
                if ( $li_html ) {
                        echo "<ul class='post-meta'>\n$li_html</ul>\n";
                }
        }
}

Attachments (1)

the_meta.patch (1.4 KB) - added by campusboy1987 2 years ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @birgire
2 years ago

  • Keywords needs-patch needs-unit-tests added
  • Version changed from trunk to 1.2

@campusboy1987 thanks for the report and welcome to WordPress trac.

This sounds reasonable, have you considered writing a patch for this?

#2 in reply to: ↑ 1 @campusboy1987
2 years ago

Replying to birgire:

@campusboy1987 thanks for the report and welcome to WordPress trac.

This sounds reasonable, have you considered writing a patch for this?

Thank you for your attention! I made a patch in PhpStrom. I hope that I did everything right.

#3 @birgire
2 years ago

@campusboy1987 great, thanks for the patch.

I noticed that the path in your patch is:

wp-includes/post-template.php 

but I've seen many patches here on trac relative to:

src/wp-includes/post-template.php

where src comes from the wordpress-development repository

https://github.com/WordPress/wordpress-develop

This is also helpful to check the coding standards of patches:

https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

I usually check it to fix my white spaces ;-)

#4 @dd32
2 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to 5.0
  • Owner set to dd32
  • Status changed from new to accepted

Thanks for the patch @campusboy1987! The approach looks good to me.
I see no reason why this shouldn't be pushed into the next major WordPress release.

@birgire Thanks for reviewing the patch too :) FYI we generally don't mind where the patches come from, as long as they have enough path in the filename for context (ie. wp-includes/post-template.php and src/wp-includes/post-template.php is okay, but just media.php is discouraged).
Creating patches from the develop repo instead of the build repo is especially helpful when CSS is involved though, as it then modifies the originals rather than the built files - that's the only scenario where the develop repo is really a requirement for contributions, and even then, we can usually make it work!

#5 @birgire
2 years ago

thanks @dd32 for clearing that up, I had indeed followed a CSS ticket (#42596) recently that required src root level path for a patch and assumed that was also the preferred way in general ;-)

As I marked the ticket for a unit test, it was my main reason for mentioning the wordpress-developement repository and hopefully encourage @campusboy1987 to write one. Not wanting to make it overwhelming, I first wanted to introduce the WPCS, as it has helped me a lot ;-)

#6 @campusboy1987
2 years ago

Thank you, friends, for comments and advice. This is my first ticket, because your opinion is very important to me. I want to thank @mihdan and @Tkama for their help.

#7 @dd32
2 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 42225:

Template: Don't output an empty <ul> in the_meta() when a post only has protected metas.

Props campusboy1987, birgire.
Fixes #42629.

#8 @SergeyBiryukov
2 years ago

  • Keywords needs-unit-tests removed

It doesn't look like there's a particular need for unit tests here.

Version 0, edited 2 years ago by SergeyBiryukov (next)

#9 @johnbillion
14 months ago

  • Milestone changed from 5.0 to 5.1
Note: See TracTickets for help on using tickets.