Everything is already scoped to the approver. Switching to the creator doesn't make much sense here.
In addition, this sent the success message 5 times because the rename happened at the wrong place
I tested this since it looked weird to me and arrived at the conclusion that this always has been this way.
That conclusion was wrong, I probably looked at something cached.
This previously had whitespace that I unintentionally removed. This also has the unintentional sideeffect
of not breaking up individual prev/scale/next links which I see as an improvement.
Remove a margin override for the first entry, this wasn't properly centered for some reason.
Still not quite there but much better now.
* Address the baraag/mastodon icon situation
* Add a blogspot.com icon
* Add a yiff.life icon
* Add a nijie.info icon
* Add an f-list.net icon
* Fix the issue with the AO3 icon
* Add a couple of aliases for existing icons
* Misnamed AO3 file
* Add a wordpress.com icon
* Add a wikimedia.org icon
* Add a furbooru.org icon
* Add an alias to the Patreon CDN
* Remove the t.co - t.me alias
* Misnamed wikimedia.org file
* Add a fandom.com icon
* Add an exhentai.org alias
This doesn't have the same issue as mass updates, but
it doesn't hurt to change this away from tag_string_diff as well
Aliases/Implications still do this but considering this has been the case
for 4 years now I don't believe this to be a problem
Resolving aliases here is not great. Just mass update nothing in these cases, that's much safer.
Using tag_string_diff also wasn't a very bright idea, this too can result in both tags being removed
* [Misc] Add favicons to some external links
* RuboCop changes from master
* Use packs for favicon images
This works better with caching.
If the file changes, the url changes
* Add favicons to an artists domain list
* Fix aliases
The lookup is done by strings, the keys were symbols
* Add old deviantart cdn alias
* Guard against links with that parse down to no host
http:twitter.com for example
* Tweak flow
* Add basic tests, fix some of what I probably broke
---------
Co-authored-by: Earlopain <14981592+Earlopain@users.noreply.github.com>
https://api.jquery.com/data/
> Every attempt is made to convert the attribute's string value to a JavaScript value (this includes booleans, numbers, objects, arrays, and null)
Why
Since its introduction 3 years ago, it got used once I believe
I can't even say if this properly works anymore.
If something like that is actually desired in the future, it should just be a whitelist instead
