Blissful690 
Loves Misty
I agree with the whole complex filter thing. It would save me having to look at my filter and seeing which line in the complex hidden filter is causing the image to be hidden.
Feature suggestions and discussion [READ THE FIRST POST]
JP 
I miss the show so much
Here’s a bunch of new feature ideas I’ve been collecting for a while.
Fixing malformed namespace separators if the namespace is known
We have surprisingly large number of tags that contain full-width colons. Or spaces around the colon, on either/both sides.
- If a tag starts with a known namespace, but it is followed by U+FF1A FULLWIDTH COLON, then replace the fullwidth colon with a normal ASCII “:”:
artist：foo->artist:foosomething：else->something:else(not a known namespace)artist：foobar (someone：else)->artist:foobar (someone:else)(only the first occurrence is fixed)
- If a tag starts with a known namespace, but there are spaces on either side of the colon, remove them. Examples:
artist : foo->artist:fooartist: foo->artist:fooartist :foo->artist:foofoo : bar->foo : bar(again, not a known namespace)foo : bar (something: else)->foo:bar (something: else)(again, only the first occurrence is fixed)
These could be applied to the tags when they’re saved. If this isn’t desirable (ie. changing the tags “behind the user’s back”), then a warning can be displayed below the tag editor.
Tag links
We can link to images using the >>XXXX syntax, so how about a similar syntax for linking to tags? They produce the same normal tag box that’s used everywhere. You can click it, filter it, etc. normally.
For example, typing (I’m not sure about the syntax, but that can be worked out)
>>artist:badumsquishwould produce something that looks like this (not an image, but an actual tag box):
>>2692385t
Warn about on-site image hotlinking
One of my pet peeves…
Many people actively refuse to use the embed tags and, for unknown reasons, want to hotlink to on-site images. Some of them even get hostile if you point this out. Perhaps this could be mitigated by alerting them if their posts and comments contains hotlinks, and automatically suggesting a fix.
This regexp:
https:\/\/derpicdn\.net\/(?:.+)(?:\/\d+){3}\/(\d{1,7})can detect and extract the image number from (most, see below) hotlink URLs I’ve seen around here; the image ID is in the first capture group. If the regexp matches, a warning message could be displayed before posting the comment/post and suggesting using the proper embed syntax.
However, this regexp suffers from a bug. If you put multiple hotlinks in a single line (ie. paragraph), the first
.+ will eat all content from the start of the first until the end of the last. I haven’t been able to modify the regexp to be less greedy. This is why it should be only used to detect the presence of hotlinks. If the regexp could be fixed, then it could be used to actually rewrite the hotlinks with embeds. A regexp that matches the full hotlink URL is very complex and I do not want to post it here, as it scares me. I’ve tested it and it works, but it suffers from the same greediness, so it can be very destructive. I believe the best place for actually rewriting the links is in the Markdown parser, as it knows the exact start and end position of all URLs.(This regexp does not match full image URLs, like
https://derpibooru.org/images/3122202, that some people try to use and even put them in ![] sometimes. But that can be fixed.)Oh, who am I kidding? They’ll just ignore the warning.
Miscellaneous
- Allow the image description and tags to be collapsed. The <details> HTML element would be perfect for this. They could be open by default, but you can collapse them when needed. (Some people put very long novels in the description and if you’re trying to see the tags, you have to scroll. A lot.)
- Automatically change “->” to “->” in posts and comments, like the old forum software (pre-Philomena?) did.
- Show the forum title on the new topic page. Right now, you can only see it if you look at the URL (and know the URL of each forum).
- The global duplicate reports page is a neat semi-hidden page, it should be publicly linked to in the top/bottom navigation bar
- In the tag editor, warn about new single-use tags that aren’t artist tags or OC names? This might need a roundtrip to the server to get exact tag counts (the suggestions autocomplete list does not contain everything, so it cannot be used reliably for this).
🐴 
IRL 🎠 stallion
- I love your tag embedding post. It would be massively helpful in the tagging discussion forum. Along these lines, perhaps we could have user and gallery linking. @PUBLIQ for a user link and something like >>17849g to link to the gallery with ID 17849. Two big however
- How would this handle tags with spaces in them?
- I’m not sure if there’s much use for the user page linking besides the fact that it can be done
- The fact that people get mad when you tell them to use proper on-site embeds is all the more reason to make the corrections a silent substitution after they hit submit instead of a validation warning.
saby 
Moderator
Anti Fun Officer
- Like how links already handle tags with spaces and other special characters, such as /tags/simple+background ->
simple backgroundor /tags/oc-colon-oc ->oc:oc
JP
I miss the show so much
The fact that people get mad when you tell them to use proper on-site embeds is all the more reason to make the corrections a silent substitution after they hit submit instead of a validation warning.
The problem with many people is that when they need to do something new, they develop a process for it. That process achieves the thing, and they will keep doing that process until the end of time. When the Markdown parser turns their copy-pasted image URL (that’s full of search parameter) into a jumble of bolds and italics, they’re okay with it. Because it’s their process.
Then, when someone comes along and shows them a simpler way to do the thing, a new process, they get mad because someone dares to interfere with their holy process. The fact that the new way is simpler, faster and less error-prone is irrelevant to them. The new way is not their process.
It is maddening.
(It’s also why you’re right: a mere warning isn’t enough. Because they’ll ignore it.)
Background Pony #0F89
JP
I miss the show so much
>>"riding a pony"Or maybe the syntax could be completely different from the embed, like:
!t[riding a pony]That mimics the external image link syntax (![]).
🐴
IRL 🎠 stallion
@JP
Would that be >>“riding” for tags without spaces? That may also cause problems for phoneposters if their autocorrect gives intelligence to the quotes. I like @Background Pony #2A5F’s suggestion.
Would that be >>“riding” for tags without spaces? That may also cause problems for phoneposters if their autocorrect gives intelligence to the quotes. I like @Background Pony #2A5F’s suggestion.
Yoshimon1 
yay(){ yay|yay & };yay
the first.+will eat all content from the start of the first until the end of the last. I haven’t been able to modify the regexp to be less greedy
Add ? to make a quantifier lazy and match as few characters as possible.
.+?Though I’d remove the quantifier after the image id so it doesn’t have to get changed once ids reach 8 digits and make https optional. And definitely make everything case insensitive later.
/(?:https?:\/\/)?derpicdn\.net\/(?:.+?)(?:\/\d+){3}\/(\d+)/i Example on regex101 JP
I miss the show so much
@Yoshimon1
That’s so much better than the one I came up with. That regexp could be actually used to suggest multiple replacements. Thanks, I needed a mini-tutorial on lazy matching. I can already see why my attempts didn’t work.
That’s so much better than the one I came up with. That regexp could be actually used to suggest multiple replacements. Thanks, I needed a mini-tutorial on lazy matching. I can already see why my attempts didn’t work.
Now I have the urge to try and fix the full embed URL (that I mentioned but didn’t post) regexp similarly. That’ll take a while.
JP
I miss the show so much
@JP
Okay, I crafted two separate regexps for doing regexp-based search-and-replace operations. Each of them will fix one possible hotlink format, so multiple passes are needed.
Okay, I crafted two separate regexps for doing regexp-based search-and-replace operations. Each of them will fix one possible hotlink format, so multiple passes are needed.
Both of them return the target image ID in the first capture group.
The first regexp
(?:!\[.*?\])?\(?(?:https:\/\/)?derpicdn\.net\/(?:.+?)(?:\/\d+){3}\/(\d+).*?(?:png|jpe?g|gif|svg|webm)\)?matches everything that has been formatted in any of these formats (the bracketed description “x” is optional):
https://derpicdn.net/img/view/2023/2/1/3038109__safe_artist-colon-pabbley_rainbow+dash_human_pegasus_pony_blushing_clothes_cute_dashabetes_female_floating+heart_goggles_goggles+on+head_hand_hand+on+f.jpg
or just a plain derpicdn URL:
https://derpicdn.net/img/2023/2/1/3038109/large.jpg
The second regexp
(?:\[.*?\])?\(?(?:https:\/\/)?(?:derpibooru|trixiebooru)\.org\/images\/(\d+)(?:\S*)matches to full image URLs like
https://derpibooru.org/images/3015554
but it also matches this weird format (some people really do not grasp the difference between an image and a web page):
[x](https://derpibooru.org/images/3015554)
It also matches full URLs that contain search parameters, like this:
https://derpibooru.org/images/3069967?q=twiabetes%2C+pt%2C+score.gt%3A500%2C+safe
Bonus: it also supports Trixiebooru domains.
Did I really spend almost two hours on this, searching the database dump for various failed hotlink formats, then adjusting the regexps until they match?
Yes.
Are there more weird hotlink URLs out there that these regexps don’t catch?
Almost certainly.
(I think changing the Markdown parser to automatically fix these would be a better and more robust option.)
Background Pony #0F89
I can think of one case where there’s a difference between hotlinking and direct linking an image: if it’s within a link. You can’t make a hotlinked image a link to anything else…that might actually be a good thing, though.
BTW, it looks like embedding images ends links at the image even if more things are within the link syntax:
Yoshimon1
yay(){ yay|yay & };yay
BTW, it looks like embedding images ends links at the image even if more things are within the link syntax:
Obviously that won’t work. The image embeds are (on-site) links themselves. You can’t nest a link (or other interactive content) inside another link according to the HTML specification. So I assume the markdown parser here simply ends your first link where the second link begins.
Background Pony #0F89
@Yoshimon1
I would expect it to either automatically create separated links to fill in (which of course
I would expect it to either automatically create separated links to fill in (which of course
you can do by hand), or else, fail to render the surrounding link at all, to be consistent with the way it handles nested Markdown-syntax links:
[outer inner link link](/)
Background Pony #D261
- Danbooru-style thumbnail tooltips that display a post’s tags, source, and uploader in an easy-to-read manner.
- Description boxes that become scrollable after a certain length. Danbooru also does this to keep descriptions from taking up an entire page.
- Display the size and filetype of an image when you’re uploading.
Yoshimon1
yay(){ yay|yay & };yay
Wondering if it might be useful to add a flag/checkbox to multi-url sources to show which source url the image actually came from initially. Probably should only be set by the uploader (or on merge, naturally).
radpanic 
never big enough
@Yoshimon1
Or at least a way to flag which source has the best quality version of the picture.
Or at least a way to flag which source has the best quality version of the picture.
Princess Celestia
Administrator
Devops
@JP
I thought of adding something like this with a syntax similar to hashtags, e.g.
I thought of adding something like this with a syntax similar to hashtags, e.g.
#safe, or #[twilight sparkle]. It wasn’t a priority in the initial Markdown implementation. JP
I miss the show so much
@Princess Celestia
It’s a “nice to have” feature. It would make writing posts in the tagging forum much easier.
It’s a “nice to have” feature. It would make writing posts in the tagging forum much easier.
Background Pony #0F89
Would it be out-of-scope for the site to test for equivalency of different forms of the same source? eg. condensing
https://www.deviantart.com/username/art/Name-of-art-1111111 and https://username.deviantart.com/art/Name-of-art-1111111 and http://fav.me/d{base 36 representation of 1111111} instead of allowing all to exist (such as can happen when merging dupes)? radpanic
never big enough
@Yoshimon1
Well, there are plenty of cases where the first (public) posting of the image isn’t the best quality one. Like an artist with a Patreon or other paywalled gallery will post a (possibly downsized) jpeg on Twitter to advertise their Patreon, then they’ll release the full-res PNG on Patreon to the general public a few months later. Even if there’s no paywall involved, I’ve seen artists that post to Twitter first, and wait a day or two before posting the higher quality version to a site that won’t forcibly downgrade the picture.
Well, there are plenty of cases where the first (public) posting of the image isn’t the best quality one. Like an artist with a Patreon or other paywalled gallery will post a (possibly downsized) jpeg on Twitter to advertise their Patreon, then they’ll release the full-res PNG on Patreon to the general public a few months later. Even if there’s no paywall involved, I’ve seen artists that post to Twitter first, and wait a day or two before posting the higher quality version to a site that won’t forcibly downgrade the picture.
Yoshimon1
yay(){ yay|yay & };yay
@radpanic
But if a (public, non-paywalled) higher quality version gets posted later, then I’d expect it to get uploaded and merged. And the merged image then has both sources, with the one of the highest quality aka the actual source of the image flagged. So why would someone want to just flag some source without actually uploading the image? Am I misunderstanding what you meant somehow?
But if a (public, non-paywalled) higher quality version gets posted later, then I’d expect it to get uploaded and merged. And the merged image then has both sources, with the one of the highest quality aka the actual source of the image flagged. So why would someone want to just flag some source without actually uploading the image? Am I misunderstanding what you meant somehow?
On second thought, did you misunderstand my “url the image actually came from initially”? I didn’t mean initially like the first time the image was posted, I meant it like “here’s an image with three sources that may have been added weeks later, which source is it actually from”. That’s why I also said it should get updated on merges.
On third thought, did you mean to flag it even if the uploaded image isn’t from that source because it can’t get uploaded for reasons (paywall)? That might make sense as an extended “higher res at source” kind of tag, yeah…
Interested in advertising on Derpibooru? Click here for information!
Help fund the $15 daily operational cost of Derpibooru - support us financially!