[Userscript] ValidateTagInput

ValidateTagInput checks all tag adds and removals on a post edit. For tag adds it validates that no new tags are being created via mistaggings or mispellings. For tag removes it checks the implication hierarchy to validate that no existing tags will readd that tag once it is removed.

Installation

• Chrome/Firefox: Install Tampermonkey

Project page

• https://github.com/BrokenEagle/JavaScripts

Main script

• https://raw.githubusercontent.com/BrokenEagle/JavaScripts/master/ValidateTagInput.user.js

Usage notes

There are two buttons: Submit and Check. Both will perform tag validation, but only submit will go on to submit the tags.

If one of the validations fail, it presents an error notice. For tag adds, it lists all of the new tags that will be created. For tag removes, it lists all of the hierarchy relationships that will cause a tag removal to be readded.

Additionally, it will display a Skip Validation checkbox below the Submit button. Selecting this will cause the userscript to ignore any validation failures and submit the tag changes as is.

One way to cause the tag validator to ignore a particular tag, especially if it is intentional, is to preface it with the metatag for its character type (example: general:this_is_a_new_tag).

Final

Any suggestions or feedback is appreciated.

Latest edits

• (2022-09-04) Updated script link in OP

Versions

For tag adds, allow newly created tags if they contain a colon? That way, char:someone will be let through. It only saves clicking the Skip Validation checkbox, though, I guess.

Yeah, that makes sense. It's more of a deliberate action anyways, so should be less prone to spelling errors and the like. On the plus side, it makes the code a bit easier not having to strip off those typetags... (ツ)

Any chance you could make its detection case insensitive, to match danbooru's tags? I often end up getting blocked because I typed ":D" instead of ":d". It's just a minor annoyance, though.

Yeah, no problem. I didn't even know that Danbooru's tag search didn't account for uppercase tags... <__< I added the check for uppercase tags into the latest version.

Looking into this, it seems like when search[name] is used instead of search[name_matches], case is sensitive. Since all tags are stored lowercase, I don't see any reason to have case sensitivity there. I'll go ahead and submit an issue for it.

Edit:

Created issue #3312 for the case sensitivity with tag searches.

There is something odd about aliased tags.
For post #2869759, I uploaded it with hairtie. Normally, this tag is aliased to hair tie. But it still gave me the warning that a new tag will be created.

Chiera said:

There is something odd about aliased tags.
For post #2869759, I uploaded it with hairtie. Normally, this tag is aliased to hair tie. But it still gave me the warning that a new tag will be created.

Probably because aliased tags are at 0 post count so the script doesn't check if it will be changed over after upload?

I updated the version earlier today to account for tag aliases (Version 6). You need to update your script.

Pushed Version 7 mostly because it fixes a pretty critical bug with the last version.

Also, a known issue I recently discovered is that using the Return key in the text box will cause the tag validator to be bypassed. The Danbooru Javascript code doesn't appear to be binding the Return key for this purpose, so it may not be an easy or quick fix... :/

Edit:

Nevermind... I figured it out. I'll push something out hopefully by tomorrow.

Pushed Version 8 which mostly was about rebinding the Return key to use the tag validator instead. There were also several other changes under the hood to reduce code and use better selectors for triggers. Finally, I changed the language for bad tag removes to be a Notice instead of a Warning to indicate that it's more of an advisory. Nothing bad will happen with it, but you might not be making the changes you think you are.

Another thing I noticed: while warning for implied tags not being removed, the script doesn't consider eventual tag removals done directly in-edit. For example:

The post has "frilled_panties panties"; you open the tagging interface and remove "panties", and then you keep editing before submitting. After a while you add "-frilled_panties" and press enter.
The script will still warn you that the panties tag won't get removed because of the presence of frilled_panties.

I understand that the solution to this is to just remove it manually, but it's not that easy in posts such as post #2871794.

nonamethanks said:

Another thing I noticed: while warning for implied tags not being removed, the script doesn't consider eventual tag removals done directly in-edit.

Yeah, thanks for pointing that out. Sometimes you can be blind to the most obvious things when you're checking out out your own code... :p

Regardless, I pushed Version 9 that has the fix added.

BrokenEagle98 said:

Yeah, thanks for pointing that out. Sometimes you can be blind to the most obvious things when you're checking out out your own code... :p

Regardless, I pushed Version 9 that has the fix added.

Man, you're amazing. Thank you!

Sometimes when adding a few missing tags and then pressing enter to submit, I get the warning that new tags will be created even if they are existing ones like blush and smile, but the warning barely has time to appear before Danbooru goes ahead and adds the tags to the post as usual which makes me think there's something weird going on.

Unbreakable said:

Sometimes when adding a few missing tags and then pressing enter to submit, I get the warning that new tags will be created even if they are existing ones like blush and smile, but the warning barely has time to appear before Danbooru goes ahead and adds the tags to the post as usual which makes me think there's something weird going on.

Which version of the userscript are you using? Which browser are you using? Also, does it occur after you hit Submit, when you hit the edit button, or when the page loads? Are there steps taken that will reliably reproduce the error...?

I haven't experienced that error for myself (yet)... so the more information you can provide, the more likely I'll be able to track down the bug... (ツ)

BrokenEagle98 said:

Which version of the userscript are you using? Which browser are you using? Also, does it occur after you hit Submit, when you hit the edit button, or when the page loads? Are there steps taken that will reliably reproduce the error...?

I haven't experienced that error for myself (yet)... so the more information you can provide, the more likely I'll be able to track down the bug... (ツ)

It has occurred both in version 8 and 9 and on Firefox. It occurs after I add tags in the tag window and press enter to submit the changes, for less than a second before the page re-loads.

Unbreakable said:

It has occurred both in version 8 and 9 and on Firefox. It occurs after I add tags in the tag window and press enter to submit the changes, for less than a second before the page re-loads.

Okay... I'll do some tag gardening on Firefox sometime later today or tomorrow to see if I can reproduce this error.

BrokenEagle98 said:

Yeah, thanks for pointing that out. Sometimes you can be blind to the most obvious things when you're checking out out your own code... :p

Regardless, I pushed Version 9 that has the fix added.

Just wanted to point out that I discovered today that while this is fixed, there's still the case of typos you manually fix (ie "black_shirth -black_shirth still returns an error).

nonamethanks said:

Just wanted to point out that I discovered today that while this is fixed, there's still the case of typos you manually fix (ie "black_shirth -black_shirth still returns an error).

Pushed Version 10 which fixes this.

Additionally, I added and adjusted several print statements in response to Unbreakable's issue up above. The potential fix for that issue though is in another branch I'm working on.

Pushed Version 11 to fix a bug reported by nonamethanks on Discord.

The bug involved loading the pre-edit tags differently on the uploads page to account for page reloads caused by errors such as not setting the rating. Long story short, I changed things to always set the pre-edit tags to blank with uploads since that's the way uploads always start.