WordPress.org

Make WordPress Core

Opened 22 months ago

Closed 22 months ago

Last modified 11 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:

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 22 months ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @birgire
22 months 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
22 months 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
22 months 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
22 months 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
22 months 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
22 months 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
22 months 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
22 months ago

  • Keywords needs-unit-tests removed

It doesn't look like there's a particular need for unit tests here. Thanks for the patch, @campusboy1987!

Last edited 22 months ago by SergeyBiryukov (previous) (diff)

#9 @johnbillion
11 months ago

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