WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#9094 closed defect (bug) (fixed)

posts_nav_link() vs. empty <p></p>'s

Reported by: jidanni Owned by:
Milestone: 2.8 Priority: lowest
Severity: normal Version: 2.7.1
Component: Template Keywords: has-patch tested
Focuses: Cc:

Description

Gentlemen, observe all the back bending one needs to do if one
doesn't want the possibility of making empty <p></p>'s:

ob_start(); posts_nav_link(); $z=ob_get_contents(); ob_end_clean();
  if($z){echo "<p>$z</p>\n";}

This is all because there is no way around the 'echo' in
posts_nav_link(), in order so one can test its output before using it.

You may say "ho hum, so what if you make an empty <p></p>".

But I think that is very stupid.

Attachments (2)

9094.1.diff (3.2 KB) - added by sivel 6 years ago.
get_posts_nav_link.9094.diff (2.3 KB) - added by filosofo 6 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 @jidanni6 years ago

  • Cc jidanni@… added

comment:2 @jidanni6 years ago

  • Cc jidanni@… removed

comment:3 @jidanni6 years ago

  • Cc jidanni@… added

comment:4 @sivel6 years ago

  • Cc matt@… added
  • Version set to 2.7.1

An empty <p></p> will not validate as XHTML 1.0. Would it be acceptable to return &nbsp; if a link would not returned? This would keep the page validating correctly.

comment:5 @jidanni6 years ago

  • Priority changed from normal to lowest

Holy moly, if now it becomes <p>&nbsp;</p>, well, that tells me that me
reporting bugs only can make matters worse!

Anyway, I stuck a <p></p> into one of my
http://abj.jidanni.org/articles/ mom's pages, and ran it thru

$ validate --version
Offline HTMLHelp.com Validator, Version 1.2.2
by Liam Quinn <liam@htmlhelp.com>

and it worked fine, XHTML header and all.

So at least it is still vaild, no?

comment:6 @sivel6 years ago

I'm thinking adding $before, $after args to the function may be a good way to go. You could include the <p> tags in the $before and $after which would only be output if the links are output. I need to look at the code more carefully, but seems feasible.

What is your opinion?

@sivel6 years ago

comment:7 @sivel6 years ago

Patch attached to give $before and $after args to posts_nav_links and next/previous posts links functions.

comment:8 @filosofo6 years ago

  • Keywords has-patch get_posts_nav_link posts_nav_link added

For other functions like this we've added a complementary get_* function. Patch attached.

comment:9 @sivel6 years ago

  • Keywords dev-feedback added; get_posts_nav_link posts_nav_link removed

comment:10 @sivel6 years ago

  • Keywords tested added; dev-feedback removed

please use filosofo's patch.

comment:11 @azaozz6 years ago

The second patch looks good but what's the point in using optional args (non-translatable too) then creating $defaults array and running it through wp_parse_args()? The optional args will always overwrite the defaults.

Changed it a bit so the defaults aren't overwritten when calling posts_nav_link() without arguments.

comment:12 @azaozz6 years ago

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

(In [11049]) Add a complementary get_* function for posts_nav_link(), props filosofo, fixes #9094

Note: See TracTickets for help on using tickets.