I don’t really understand why the isparent:* and ischild:* tags are the way that they are. e621:cheatsheet#ParentsAndChildren

As they are now ischild:true and ischild:false are both valid tags, instead of there just being one identifier being “ischild”. I don’t understand the need for both.

Also I’ve been having issues with these tags in general, when searching in my own favorites for parent or child posts it consistently gives me posts that are neither, or the opposite when I’m searching for oneor the other. Any reason behind this? Any fixes?

Well I don't use these too often, but as far as I understand it:

isparent:true = only showing you posts that ARE a parent post
isparent:false = only showing you posts that are NOT a parent post
isparent:* = shows you both ones that are and also ones that are not, which is kind of meaningless. Using that wildcard * instead of using either TRUE or FALSE could make your results seem confusing if you actually just wanted only one of those things to show in your search.

Testing those right now, I'm not seeing any incorrect results for using them in a regular search. They behave as expected to.

However, I do see some seemingly "incorrect" results when combining it with a favorites search. This is probably because trying to use more than one metatag in the same search is not quite as reliable. they don't always play nice together. It used to be they wouldn't even work together, but these days some will work but it can be a little more unreliable in exactly HOW it will work.

So in this case if you use isparent:true in combo with fav:yournamehere, then it is pulling up images which have a deleted child post. Technically they are a parent post, just not in a way that is helpful for normal searching. These types of parent/child links are fairly common to have on the site actually, since we child a post before deleting it, to let our system be able to move the favorites from a lower quality version to the higher quality version which we are keeping. And it is helpful for staff to always be able to see linked all of the deleted versions of a post together with the public version, so we make sure to keep them linked even after the deleted posts are hidden from public view. It doesn't normally cause any problems, because a normal search ignores the existence of all the deleted posts, so most users never know they are there anyway. But staff can see them.

But when searching in your favorites (which uses a metatag to do fav:yournamehere) and then adding another metatag to the search like isparent:true, it is a little less reliable to combine metatags in the same search. In this case it is working mostly correctly, but with the added quirkiness of it failing to ignore the existence of deleted posts when searching. So it's telling you the link exists, even though that isn't useful to you if the link is to a deleted post.

So that is what is happening here. And I don't see any easy fix for it. But I would suggest maybe using ischild:true instead, since there are less child posts that have a deleted child connected to them. So it would give you less 'seemingly incorrect' results. Which makes the few that do show up, a lot easier to ignore. And having deleted parents is very uncommon, because the system doesn't autohide those, so we tend to not do it that way. So most of those 'incorrect' results are from finding parent posts with a deleted (which is mostly invisible) child post. Searching for ischild:true would mostly avoid this problem, since child posts on child posts is a lot less common, so it would give you a lot fewer ghost results. So that is my suggestion.

As for why we have both: Having both parent and child options, means if you have a specific post that you're trying to find and you know it was a child post, then this can help you narrow your search to only child posts. etc. Or if you know it was a parent post, then using isparent:true in your search can exclude all of the non-parented posts from your search and help you narrow things down. But yeah, if you just wanted 'any post that is in a parent or child relationship' then you only need to pick one of them and set it to "true". But if you're using it to search in your favorites (or in combination with any other metatag), then I would suggest using ischild:true because it will detect less links to deleted posts that way. And to just ignore anything which doesn't have the parent/child border around the thumb, because those would be ones which have a deleted parent/child link and that is not what you are looking for.

Testing those right now, I'm not seeing any incorrect results for using them in a regular search. They behave as expected to.

Yea it is likely due to the deleted child posts. Also more than one meta tag never seems to be an issue… even just searching up “isparent:true” by itself yields the same false posts showing up, ones with no child, same with the ischild… :/

As for why we have both: Having both parent and child options, means if you have a specific post that you're trying to find and you know it was a child post, then this can help you narrow your search to only child posts. etc. Or if you know it was a parent post, then using isparent:true in your search can exclude all of the non-parented posts from your search and help you narrow things down. But yeah, if you just wanted 'any post that is in a parent or child relationship' then you only need to pick one of them and set it to "true". But if you're using it to search in your favorites (or in combination with any other metatag), then I would suggest using ischild:true because it will detect less links to deleted posts that way. And to just ignore anything which doesn't have the parent/child border around the thumb, because those would be ones which have a deleted parent/child link and that is not what you are looking for.

Even still I don’t see a reason to have both isparent:true and isparent:false as tags instead of one isparent, same with ischild… i get why you’d want both parent and child but I don’t see the reason to have true and false for both… it just seems redundant.

thatsmygayfettish said:
Even still I don’t see a reason to have both isparent:true and isparent:false as tags instead of one isparent, same with ischild… i get why you’d want both parent and child but I don’t see the reason to have true and false for both… it just seems redundant.

At a guess, it's a constraint that metatags have to have a colon and something after, so even a simple-to-use boolean metatag like isparent has to have :true/:false.

thatsmygayfettish said:
Even still I don’t see a reason to have both isparent:true and isparent:false as tags instead of one isparent, same with ischild… i get why you’d want both parent and child but I don’t see the reason to have true and false for both… it just seems redundant.

Because people might also want to search for when a post isn't a parent or child? For example, isparent:false ischild:false inpool:false should only return images that have no relationship with other images.

faucet said:
Because people might also want to search for when a post isn't a parent or child? For example, isparent:false ischild:false inpool:false should only return images that have no relationship with other images.

Not really, but I think rather this would make sense:

animperfectpatsy said:
At a guess, it's a constraint that metatags have to have a colon and something after, so even a simple-to-use boolean metatag like isparent has to have :true/:false.

But I don’t see anywhere that is established