Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 7 years ago

#8603 closed defect (bug) (wontfix)

post_parent default in get_children

Reported by: jdub's profile jdub Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: General Keywords: has-patch dev-feedback
Focuses: Cc:


Much like #8348, the default behaviour of get_children has changed as a result of #8085 being fixed. The default value of 0 should be removed from this function.

I found this bug as it broke Viper007Bond's excellent regenerate-thumbnails plugin. :-)

(By the way, this appears to be the last bug of its kind in the 2.7 tree.)

Attachments (1)

get_children-post_parent-default.diff (368 bytes) - added by jdub 13 years ago.

Download all attachments as: .zip

Change History (12)

#1 follow-up: @filosofo
13 years ago

What is the situation in which one would call get_children without specifying a parent?

#2 in reply to: ↑ 1 ; follow-up: @Viper007Bond
13 years ago

Replying to filosofo:

What is the situation in which one would call get_children without specifying a parent?

I use it to get all attachments. Is there a better method?

#3 in reply to: ↑ 2 @filosofo
13 years ago

Replying to Viper007Bond:

I use it to get all attachments. Is there a better method?

What about

get_posts(array('post_type' => 'attachment', 'showposts' => -1))

#4 @Viper007Bond
13 years ago

I ended up using this:

$attachments =& get_children( array(
			'post_type' => 'attachment',
			'post_mime_type' => 'image',
			'numberposts' => -1,
			'post_status' => null,
			'post_parent' => null, // any parent
			'output' => 'object',
		) );

I think we should default to null rather than 0 to maintain backward compatibility.

#5 @filosofo
13 years ago

In my opinion, the problem with an empty parent argument for get_children is that it's semantically ambiguous: is it requesting everything that is a child, all orphaned children, or all top-level objects?

Besides, since its inception in 2.0 get_children has returned false if no arguments are specified and it's not within the Loop. The behavior you describe has worked only inconsistently (other parameters must be specified) and only since 2.1.

#6 @Viper007Bond
13 years ago

It worked very reliably for me pre-2.7. Leaving the post_parent parameter blank resulted in essentially a wildcard. What would be the harm in keeping it as it was? Yes, best to specify (as I have now done), but no sense in changing it just for the sake of changing it IMO.

#7 @Denis-de-Bernardy
13 years ago

  • Keywords dev-feedback added

#8 @Denis-de-Bernardy
13 years ago

  • Keywords has-patch added

#9 @filosofo
13 years ago

I think this should be "won't fix."

If you want all attachments, there's a clearer, more direct way of getting them.

If you're trying address problems for plugins that were relying on pre-2.7 behavior of get_children to get all attachments, those plugins have already had to make changes for 2.7.x. So it's too late to help them. Not to mention that the behavior they relied on worked only when just the right arguments were supplied (in other words, even back then having an empty post parent didn't produce all attachments for every possible set of arguments; that's what I mean by "inconsistent").

And there's the semantic stuff I mentioned above: "children" or "child" everywhere else in WP implies a hierarchical relationship that doesn't exist in the "get all attachments" scenario. If null really acted as a wildcard, that would be one thing, but it behaves only somewhat like a wildcard and only in certain situations. The harm in reverting to the previous behavior is that it eliminates a default and introduces inconsistent behavior to get_children.

#10 @Denis-de-Bernardy
13 years ago

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

+1 to that

#11 @DrewAPicture
7 years ago

  • Milestone 2.7.2 deleted
Note: See TracTickets for help on using tickets.