Donmai

[Userscript] ValidateTagInput

Posted under General

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

Project page
Main script
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

Show
  • (2017-09-24)
    • Version 2 - Initial release
    • Version 3 - Removed tagtype tags as a consideration for tag add validation <kittey: forum #136421>
  • (2017-09-25)
    • Version 4 - Added support for uploads page
    • Version 5 - Added remove tag validator
  • (2017-09-26)
    • Version 6
      • Added alias check to add tag validator
      • Normalize tags to lowercase <nonamethanks: forum #136522>
    • Version 7
      • Fixed a bug in data model, causing the submit process to hang
      • Restyled the warning messages
      • Saves all alias results regardless if an alias is found or not
  • (2017-09-27)
    • Version 8 - Rebound return key to use tag validator
  • (2017-09-28)
    • Version 9 - Fixed bug with final tag list calculation <nonamethanks: forum #136678>
  • (2017-09-29)
    • Version 10 - Negative tags can now be used to fix a prior mistake <nonamethanks: forum #136752>
    • Version 11 - Fixed bug with uploads page involving pre-edit tags <nonamethanks: Discord>
  • (2017-09-30)
    • Version 12 - Fixed timing bug with script <Unbreakable: forum #136728>
  • (2017-10-08)
    • Version 13 - Added check rating exists validator
  • (2017-10-10)
    • Version 14 - Changed data model and added data model validator
  • (2017-10-13)
    • Version 15 - Added tag validation to quick edit mode
  • (2017-10-16)
    • Version 16 - Added reset cached data link to user settings
  • (2017-10-21)
    • Version 17 - Migrated to IndexedDB for data storage
      • Uses Session Storage to mitigate DB penalty
    • Local Storage is used as a fallback for IndexedDB
      • It now gets pruned when it reaches a certain size
    • Fixed issue with quoted source metatag
  • (2017-10-22)
    • Version 18 - Made debug info conditional
      • Bug fix with pruning function
  • (2017-11-13)
    • Version 19 - Accounted for new Meta tag category (ref topic #14678)
  • (2017-11-18)
    • Version 20
      • Bug fix with data model check
      • Rating validator now checks for the rating in the tag box
  • (2017-11-19)
    • Version 21 - Bug fix on post index page for Member/Anonymous <evazion: Discord>
  • (2017-11-21)
    • Version 22 - Removed rating exists validator (issue #3362)
  • (2018-01-13)
    • Version 23 - Full validation of client data
  • (2018-06-04)
    • Version 24
      • Updated to use library
      • Major code refactor
      • Add a button that just checks instead of submitting
  • (2018-09-04)
    • Version 25 Add settings menu
  • (2019-01-29)
    • Version 26
      • Added additional validators (artist, copyright, general)
      • Added cache editor to menu
  • (2019-02-13)
    • Version 27 Updated to newest library
  • (2019-12-26)
    • Version 28 Updated library version
  • (2022-02-19)
    • Version 29 Updated library version
    • Added approval submit check (contributors only)

Updated

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... (ใƒ„)

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.

Updated

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?

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.

Updated

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.

1 2 3