parasprite said:
I had no idea people used those (I usually just hit "back").

I'll throw that on my todo list. At the very least it would be nice to have them standardized. :P

I don't see the point in a cancel button. The "Back" button, or even just clicking any button other than the two under the post, will "Cancel" for you.

titanmelon said:
Requested feature:

Is there a simple way to copy a forum link with one click?

The post timestamp under the user rank (e.g "7 hours ago") is a link to the post.

Request: Allow tag renaming directly from the master tag list.

Why:
Because: https://e621.net/tag?name=*cu*li*gu*&type=&order=count&show_empty_tags=1

It'd make fixing obvious typos far faster. Currently we have to navigate to the post, use the tag edit, locate the typo on the list, and then fix it. The tag list already has an edit button for the tags, why not add a renaming function there?

Such feature might be abused, so it probably should be limited to low-count tags and/or higher user ranks.

Requested feature:
An 'expand/collapse all' button thing for the section tags on wikis
(and maybe forums etc.)

Maybe as a floating button thing, (personally i really dislike those because they break very easily in places)

Esme mentioned a floating something a while back too, not sure for what

Why it would be useful:
So you don't have to manually do it on larger pages, like tag group:body types

--

-
@Genjar: +1 for that, sounds useful

Requested feature: (maybe? idk)

Ability for Janitors to change tag types on posts with count:>100

Why it would be useful:

Can't really do anything about stuff like this - forum #189580

Genjar said:
Request: Allow tag renaming directly from the master tag list.

Why:
Because: https://e621.net/tag?name=*cu*li*gu*&type=&order=count&show_empty_tags=1

It'd make fixing obvious typos far faster. Currently we have to navigate to the post, use the tag edit, locate the typo on the list, and then fix it. The tag list already has an edit button for the tags, why not add a renaming function there?

Such feature might be abused, so it probably should be limited to low-count tags and/or higher user ranks.

This isn't really possible with how tags are coded. Or put another way, getting it to work would require some pretty convoluted code. :/

titanmelon said:
Requested feature: (maybe? idk)

Ability for Janitors to change tag types on posts with count:>100

Why it would be useful:

Can't really do anything about stuff like this - forum #189580

I'd be fine with that, but I think up to 500 posts would take care of most issues without risking a hit on tags with high post counts (changing those tends to both use a lot of DB resources and fail if the post count is too high).

If we limited that, I'd probably be fine with priv+ having that (though I'd prefer adding it to the mod log before doing so).

titanmelon said:
Requested feature: (maybe? idk)

Ability for Janitors to change tag types on posts with count:>100

Why it would be useful:

Can't really do anything about stuff like this - forum #189580

That feature used to exist, but long ago someone accidentally changed tag types for several tags that had 50000+ posts. And the servers couldn't handle that, the site was offline for a long while.

So the feature was disabled to prevent such accidents from happening again.

Or something like that. I no longer remember the details.

Genjar said:

omg i think i remember that

it was spectacular
-

Hm, maybe a preconfirmation thing? Or just raise the limit to something higher, but not unlimited (<1000 seems reasonable, idk how robust the servers are now)

Genjar said:
That feature used to exist, but long ago someone accidentally changed tag types for several tags that had 50000+ posts. And the servers couldn't handle that, the site was offline for a long while.

So the feature was disabled to prevent such accidents from happening again.

Or something like that. I no longer remember the details.

50000 is too much for a modern server?

titanmelon said:
Hm, maybe a preconfirmation thing? Or just raise the limit to something higher, but not unlimited (<1000 seems reasonable, idk how robust the servers are now)

That should work well. Miscategorized tags are usually (always?) spotted long before they hit a thousand.

Munkelzahn said:
50000 is too much for a modern server?

Considering we've been getting problems with just too much traffic, y es.

No point in fixing that misfeature. It's just wrong. No idea who came up with the perverted idea of unique tag with attached category, but if it brough the server down with just 50k updates its implementation must be just as perverse. And that's wrong kinda perversion (c)

Requested feature: Independent tag namespaces. Require unique (category, tag) pair instead of unique (tag) alone.

In other words, allow artist:foo, character:foo and general:foo to exist at the same time, maybe even on the same post. Make "tag category change" a non-thing.

Why it would be useful: No accidental retroactive tag changes on posts one can't see. Less egregious disabmiguation. World peace, happines and unicorns optional.

Proper category handling would allow tagging stuff character:bagheera without fucking up posts tagged artist:bagheera, instead of inventing awful character:bagheera_(character), or retagging all those hundreds of posts with equally awful artist:bagheera_(artist) and using no-disambiguated character:bagheera for like 2 or 3 posts. Or should that be character:bagheera_(kipling) eh?

Having tags like foo:bar_(foo) is a sign that screams WRONG. It's foo: already, why isn't that enough?

I really like that, but no idea how it would work in terms of searching, sorting and indexing

It would make disambiguation soo much easier though, since you wouldn't have to tack on a bunch of *_() disambiguation qualifiers at the end. Which are honestly a pain to type every time on a regular qwerty kb

Well searching and sorting on "foo" should work like *:foo, picking all posts tagged either general:foo, artist:foo or character:foo. Indexing would work just as well, why wouldn't it?

Assuming sane db structure, I could write relevant queries and such, but I'm afraid that assumption is wrong.

hslugs said:
Having tags like foo:bar_(foo)

bar_(foo) is a tag.

foo:bar_(foo) is an instruction ('foo:') to the server to set the tag type of the tag named bar_(foo)) to foo, and to apply the tag named 'bar_(foo)'.

AFAIK you shouldn't have to specify foo: unless you are actually trying to set the tag type (ie. the first time it is applied, or if the type is currently wrong).

So while I like the namespace idea, I have to point out that it seems to be prompted by a misunderstanding of tag names.
Beyond that, as long as general tags do not have to have a namespace (eg. 'big_breasts' remains just 'big_breasts' and not 'g:big_breasts' or worse 'general:big_breasts'), I think this is a good idea.

Lots more typing for taggers. But, if tag *input* was categorized (that is, you had separate areas to enter general, character, species, copyright etc tags), then the namespacing could be done without additional typing.

Making namespaced tags nice for searchers might be harder.

savageorange said:
AFAIK you shouldn't have to specify foo: unless you are actually trying to set the tag type (ie. the first time it is applied, or if the type is currently wrong).

Yeah, sure, I thought it's kinda obvious. Though maybe it's not.

Perhaps something like this: if you tag a post "foo", without category, it picks the most used *:foo tag, let's say artist:foo. And does the same when presenting the tags for edits, so it will be "foo" not "artist:foo".

If you don't like the results, you go on and replace "foo" with "character:foo", click Save, and it removed artist:foo from this post only and adds character:foo instead to this post only.

In the tags bar on the left, both would be "foo" but in different colors and in different parts of the list.

savageorange said:
foo:bar_(foo) is an instruction ('foo:') to the server to set the tag type of the tag named bar_(foo)) to foo, and to apply the tag named 'bar_(foo)'.

Yes, and that's wrong. This instruction is given for a single post, but it also affects other posts tagged bar_(foo).

Extra annoying with new tags, when they turn out not to be new.

savageorange said:
Making namespaced tags nice for searchers might be harder.

"foo" shows posts tagged either g:foo, a:foo, c:foo, or any other *:foo; "artist:foo" only shows posts tagged a:foo. Something like that I think?

hslugs has the right idea

parasprite said:
I'd be fine with that, but I think up to 500 posts would take care of most issues without risking a hit on tags with high post counts (changing those tends to both use a lot of DB resources and fail if the post count is too high).

If we limited that, I'd probably be fine with priv+ having that (though I'd prefer adding it to the mod log before doing so).

No idea how i missed your reply :\

500 sounds fine as well, (maybe even 250 it if means no slowdown)

Munkelzahn said:
50000 is too much for a modern server?

Sort of. ~5000-10000 gets a bit heavy, but anything above that tends to time out. Since tag type changes need to update spectags:, etc. on all posts affected, the number of db queries grow exponentially by post count.

The biggest problem though is that tag type changes are done on-the-fly, which is really inefficient and prone to errors when the server derps (or when the post count is too high). We mainly just need to write a background job for it.

Probably already planned, but:

Requested feature:
A way to mark wikis as 'official' and/or 'up to date'

An icon similar to the red and green creator owner labels (or whatever they were) on sets maybe?

Why it would be useful:

So you'd know if the info in the article is still relevant to current policy as of reading and/or doesn't conflict with other tags/policies

A possibly HUGE suggestion, but adding it here for the time being:

Requested feature:

Why it would be useful:

hslugs said:
Yeah, sure, I thought it's kinda obvious. Though maybe it's not.

The way you talk, saying
" tags like foo:bar_(foo)"

"inventing awful character:bagheera_(character)"
" retagging all those hundreds of posts with equally awful artist:bagheera_(artist)"

It seemed very likely to me that you thought 'character|artist|copyright|etc:' WAS part of the tag names. Since you don't tag things with things that are not tags.

The 500 Internal Error still isn't fixed by the way parasprite.

Requested feature:

Forum post edit history

Why it would be useful:

Accountability

Since someone bumped the hi-scores...
Would it be possible to change the calculations for the tag update scores? Currently an edit that adds a single tag counts for as much as an edit that adds twenty. Which doesn't seem right.

I do a lot of single-tag edits, so it kind of suspect that my ranking is too high.

Genjar said:
Currently an edit that adds a single tag counts for as much as an edit that adds twenty. Which doesn't seem right.

This always really bugged me, it's even more noticeable when you check some people's tag history, and see a wall of 20+ obscure tags in one edit, but their tag count is <2000 or so

Dunno how viable this is, but:

Requested feature:

Have the Recent Tags list that shows up when editing a post (directly editing it, not via a mode) display a list of the most recent used tags, not the most recent ones on an image..or whatever it currently displays

For clarification, this is the tag list to the right of Favorite Tags, that's displayed when clicking the Edit button beneath a post

Entire section seems to be labelled Related Tags

Why it would be useful:

You can have instant access to the last 25 tags you used

If you use a tag again on a post, it gets bumped to the 'top' of the list

---

Not really sure how much overhauling is required for that, since it's so different from the way current Recent Tags works

But there's already a Favorite Tags section next to it that is unique to each member, so I'd guess that it's not completely impossible/infeasible

I'd like means to undo flagging a post for deletion, with say a once per day limit and/or a short timeframe to do so.

The reason I ask is because I accidentally flagged post #867737 for deletion as an inferior version of post #867734, when really I meant to use post #869750, and this could have been undone were such a feature available. Already contacted NotMeNotYou to let them know it wasn't intentional, but I'd rather be able to undo my own occasional flub-ups rather than putting the hassle on admins.

Requested feature:
Script enforced 4 tags minimum limit when uploading(client side, API level implementation could work but might break scripts).
Pre form submit, check if fields["tags"].search(/\s/g) >= 4, else error with "Please add at least 4 tags before uploading!".
The following code will work if placed anywhere in the upload page:

//y r u looking here? this is obsolete code, see the link below this section.
(function(){
    "use strict";
    var upload_button = document.querySelector("input[value=Upload]"),
        tag_list = document.getElementById("post_tags"),
        err_elm = document.querySelector("#error p");
    upload_button.addEventListener("click", function(e){
        if(tag_list.value.search(/\s/g) < 4){
            err_elm.innerHTML = "Please add at least 4 tags!";
            err_elm.parentElement.style.display = "block";
            e.preventDefault();
            return false;
        }
    });
})();

See forum #190688 for updated code based on suggestions

Why it would be useful:
Prevents people from tagging badly with no/few tags.

Chaser said:
Requested feature:
Script enforced 4 tags minimum limit when uploading(client side, API level implementation could work but might break scripts).
Pre form submit, check if fields["tags"].search(/\s/g) >= 4, else error with "Please add at least 4 tags before uploading!".
The following code will work if placed anywhere in the upload page:

(function(){
    "use strict";
    var upload_button = document.querySelector("input[value=Upload]"),
        tag_list = document.getElementById("post_tags"),
        err_elm = document.querySelector("#error p");
    upload_button.addEventListener("click", function(e){
        if(tag_list.value.search(/\s/g) < 4){
            err_elm.innerHTML = "Please add at least 4 tags!";
            err_elm.parentElement.style.display = "block";
            e.preventDefault();
            return false;
        }
    });
})();

Why it would be useful:
Prevents people from tagging badly with no/few tags.

does it detect cases where lazy people use the same tag 4 times?

Requested feature:
An option to change times on e6 from relative to absolute

e.g - Immediately after posting this suggestion, its timestamp would say 0 seconds ago

Instead of Apr 16, 2016

Why it would be useful:

Bit of a pain trying to figure out when a post/forum was made at a glance, especially older ones

(An option to change the date format itself would be great too, but not really a necessity)

----

Munkelzahn said:
does it detect cases where lazy people use the same tag 4 times?

Nope

titanmelon said:
The site itself doesn't allow identical tags to be displayed, so it shouldn't be too hard to prevent that superficially (..right?)

Yes but this is a client side script

So taking those into consideration, fixed:

//You may want to closure compile this for best byte efficiency
//Should note, this should run at DOMContentLoaded or similar
(function(){
    "use strict"; //strictly speaking
    //This is sandboxed so outside variables do not get affected.
    
    //NOTE: document.querySelector is HTML5 specific, older browsers may not
    //  support this function, if backwards compatability is needed, give the
    //  upload button an ID and reference it from that.
    var upload_button = document.querySelector("input[value=Upload]"),
        tag_list = document.getElementById("post_tags"),
        err_elm = document.querySelector("#error p"),
        dumbtags = [ //Tags that do not count against the limit(lower case)
            "tag_me",
            "tagme",
            "invalid_tag",
            "invalidtag"
        ];
    
    //Hook into the button click
    upload_button.addEventListener("click", function(e){
        //Split dem tags
        var tags = tag_list.value.split(" "),
            cleaned_tags = [];
        
        for(var i=0;i<tags.length;i++){
            var tag = tags[i].toLowerCase()
            if(cleaned_tags.indexOf(tag) == -1){
                //If tag not in cleaned_tag
                if(dumbtags.indexOf(tag) == -1){
                    //Runs if not in the dumb tags list
                    cleaned_tags.push(tag);
                }
            }
        }
        
        if(cleaned_tags.length < 4){
            //Runs when tag count is less than 4, also hacky error display
            err_elm.innerHTML = "Please add at least 4 tags!";
            err_elm.parentElement.style.display = "block";
            e.preventDefault();
            return false;
        }
        //Else continue successfully
    });
})();

How about a preview function for tickets? Often times I misspell something and as a result the formatting gets screwed up.

Requested feature:
Dynamic pagination. I was writing code for my private local booru* and though E621 could benefit from this as well(speed wise).
Basically:
On load of /posts/*, instead of sending the entire list of images to the browser, request /posts/*.json instead, applying the blacklist when creating each entry for the thumbnails.
This also allows for infinite scrolling.

Also, only load the thumbnail once the browser can actually see the thumbnail image, EG:

# # # # # <-- From here
# # # # #
# # # # # <-- To here is the browser's view port, these images are loaded
X X X X X <-- This is out of view, and not loaded yet.

Why it would be useful:
Blacklisted thumbnails will not be requested, reducing overhead request count per thumbnail.
Also loading time/requests of 320 result pages will be significantly reduced with viewport only thumbnail loading.

*Not to replace e621, e621 is too big to attempt that and as such isn't worth trying. I just got bored and decided to take a whack at writing one for fun.

Chaser said:
Requested feature:
Dynamic pagination. I was writing code for my private local booru and though E621 could benefit from this as well(speed wise).
Basically:
On load of /posts/*, instead of sending the entire list of images to the browser, request /posts/*.json instead, applying the blacklist when creating each entry for the thumbnails.
This also allows for infinite scrolling.

Also, only load the thumbnail once the browser can actually see the thumbnail image, EG:

# # # # # <-- From here
# # # # #
# # # # # <-- To here is the browser's view port, these images are loaded
X X X X X <-- This is out of view, and not loaded yet.

Why it would be useful:
Blacklisted thumbnails will not be requested, reducing overhead request count per thumbnail.
Also loading time/requests of 320 result pages will be significantly reduced with viewport only thumbnail loading.

Infinite scrolling is a bad idea in most situations for a number of reasons:

• It gets laggy and/or unwieldy when you're many "pages" down because the page has thousands of image elements and the scroll bar is two pixels high.

• There's no way to go directly to a page of results, you just have to keep scrolling and scrolling and scrolling if you need to go back to a certain point in history.

• Related to the above, it's almost impossible to go any appreciable distance back in history, as you're limited to manually scrolling through every single "page" of results instead of being able to click a pagination link to jump back hundreds of pages.

• If the page refreshes, your browser is restarted, or your browser crashes while you're more than a handful of pages back, then you'll have to scroll for a very long time to find your spot again.

• The page is gonna be laggier because the browser is responding to scroll events, firing off AJAX requests, and inserting new DOM elements constantly as you scroll.

Some of these issues can be prevented by allowing you to go to a specific page via direct URL modification and just load infinitely from that point, but that's still far from user-friendly and all of the other caveats still exist.

Thumbnails that only load when you scroll to them is a less annoying suggestion, but with CloudFlare we have zero worries about bandwidth, and it's annoying when the thumbnails refuse to load in or take longer to load in, and it just adds more potential for browser incompatibility.

HotUnderTheCollar said:
How about a preview function for tickets? Often times I misspell something and as a result the formatting gets screwed up.

Sure. I'll make a note to update that tonight.

How's about "Add to blacklist" button near the "Add to favorites" button?

Requested Feature:
Show image previews when uploading images even if the url doesn't end in .jpg/jpeg/gif/png. Not sure if this is a browser thing or a conscious design decision, either way it doesn't really make sense when you consider that whatever you are putting in the "upload from url" box must be an image readable by your browser, right?

Why it would be useful:
Right now if I upload a url like www.sofurryfiles.com/std/content?page=591124 I won't see any image preview. If I add some useless querystring that just happens to end in .jpg (or any image extension) like so:
www.sofurryfiles.com/std/content?page=591124&previewpls=thankyou.jpg
I can see the preview fine. I don't think I should have to do that.

SoFurry is having trouble right now so the links themselves might not work, but where the links go isn't important. Both links work fine and point to the same image when SoFurry isn't dead.

asw_xxx said:
either way it doesn't really make sense when you consider that whatever you are putting in the "upload from url" box must be an image readable by your browser, right?

The reason it was done that way was so that it would only fetch the image once the entire URL was typed in (if it was being manually typed in) rather than firing off a request every time a key was released. But seeing as probably >99% of URLs are just pasted rather than actually typed in, there shouldn't be a problem switching it over to something like what you suggested.

TonyLemur said:
The reason it was done that way was so that it would only fetch the image once the entire URL was typed in (if it was being manually typed in) rather than firing off a request every time a key was released. But seeing as probably >99% of URLs are just pasted rather than actually typed in, there shouldn't be a problem switching it over to something like what you suggested.

Maybe fire on the blur/focusout event? And/or have a button to (re)generate the preview?

Requested feature:
disable blacklist button. to be specific a button that functions much like the current thing where you click to unhide specific blacklisted content from your search results but instead of having to click each of them unhidden separately, there would be an option to unhide all the hidden items with one click.

Why it would be useful:
i have nearly 2500 word worth of shit in my blacklist but i still like to help around this site. it gets extremely frustrating to try do some sort of larger tagging project or to find that original post of a repost when i have like 10 pages to go through and half of the content is hidden by like 30 different blacklisted things and i need to unhide each of them separately every time i open new page. this gets twice as frustrating when im on mobile. and i dont think that im the only one with this issue.

Mutisija said:
i have nearly 2500 word worth of shit in my blacklist but i still like to help around this site. it gets extremely frustrating to try do some sort of larger tagging project or to find that original post of a repost when i have like 10 pages to go through and half of the content is hidden by like 30 different blacklisted things and i need to unhide each of them separately every time i open new page. this gets twice as frustrating when im on mobile.

Wow, that's a big blacklist! lol

What I would do for now (assuming this feature will get added, it does sound useful) is copy - paste the blacklist into notepad and a text. That way when you want to do a large project on either PC or mobile you can just delete your blacklist and copy - paste it back in again when you're done. It would save you from having to manually unhide each post separately.

DragonFox69 said:
Wow, that's a big blacklist! lol

What I would do for now (assuming this feature will get added, it does sound useful) is copy - paste the blacklist into notepad and a text. That way when you want to do a large project on either PC or mobile you can just delete your blacklist and copy - paste it back in again when you're done. It would save you from having to manually unhide each post separately.

You can also put a # in front of the line. It doesn't do anything special but since # is so rare in tags (and is now automatically removed) it effectively disables it because the line will never match anything.

I just came here to say that I would like a feature where rather than clicking each individual element on the blacklist to show posts containing that, you could click a "show all" button or something. But it looks like I was beaten to the punch.

Odd, considering how long I've been considering bringing this up.

Request: Change the title of the login page from "Login" to something site specific, like "Login to e621".

Why: Password managers like Keepass use the page title to decide which account details to fill in when you activate them. Since the page title is nonspecific, Keepass can't tell between e621 and every other site whose login page is titled "Login".

Requested feature: Custom alias and implication list

Why it would be useful: This would let the users get around aliases that corner cases prevent from implementing (e.g. char->species aliases) and fixing the mistags that are caused by one never remember which tag is correct (waving_penis v. swinging_penis in my case) as well as typos that are peculiar to someone (e.g. in my case abus for anus, cum_while_penetration for cum_while_penetrated)...

Clearly this should only be for uploads and probably not apply to edits to reduce the risk of it causing undue problems

Wyvrn said:
Request: Change the title of the login page from "Login" to something site specific, like "Login to e621".

Why: Password managers like Keepass use the page title to decide which account details to fill in when you activate them. Since the page title is nonspecific, Keepass can't tell between e621 and every other site whose login page is titled "Login".

Why use a plugin when your browser can do it for you? Your browser has a built in password keeper that goes based on website, not title, so https\:/\/e621\.net is what it looks for.

Furrin_Gok said:
Why use a plugin when your browser can do it for you? Your browser has a built in password keeper that goes based on website, not title, so https\:/\/e621\.net is what it looks for.

If the browser is remembering the pw -- once you started the browser, if anyone has access to your computer for a minute, they can effortlessly login as you. Keywallet programs can be set up much more securely -- requiring a master password / keyfile before you can do anything is standard for KeepassX (the program I use).[1]

That said, security is not everything, it's a judgement call whether to use a simpler system or a more secure one.

[1] keywallet programs also typically use much heavier encryption. Oh, BTW, they are typically not plugins but separate applications -- their autologin features work by sending synthetic keypress events to the target window.

@ Wyvm:
Would this addon help?

https://addons.mozilla.org/en-US/firefox/addon/keepass-helper/

It seems to be directed at exactly the problem you mention. FYI I haven't personally tested it though.

There are also more general addons like foxreplace, which can be used to change title etc via automatically running search/replace operations on the HTML.

Wyvrn said:
Request: Change the title of the login page from "Login" to something site specific, like "Login to e621".

Why: Password managers like Keepass use the page title to decide which account details to fill in when you activate them. Since the page title is nonspecific, Keepass can't tell between e621 and every other site whose login page is titled "Login".

I've never used Keepass, but I doubt it actually relies on the title that much because it would be way easier, safer, and more reliable to use urls.

If it is actually relying on the title that much you should probably get a different password manager. Using the page title is just a really shitty way to detect pages because there's no guarantee that the title will be the same as before. Even ignoring false negatives like this, it would also make phishing more of a problem (make a site with the title "Log in to your PayPal account").

That being said, standardizing page titles is definitely on my todo list.

Gok, I use Keepass instead of the browser password manager because it lets me sync up accounts across all browsers on all devices, and lets me manage logons for things besides websites.

Savage, that plugin would let me change the page title of the e621 logon page and thus fix the problem here, but it would only work for me. It would help everyone if the admins made the change.

Para, Keepass uses the window title to be compatible with every program, not just web pages. Since browsers put the page title in the window title, this works fine with 99% of sites, except for ones with generic titles.

It would be safer against phishing if it identified sites by the URL, but it's not such a big risk that I'd abandon the program. I just check what site I'm on before hitting the keyboard combo.

Glad to hear standardized titles are on the way!

Wyvrn said:
Savage, that plugin would let me change the page title of the e621 logon page and thus fix the problem here, but it would only work for me. It would help everyone if the admins made the change.

I felt that was self evident. Admins are busy, so a stopgap solution is necessary.

Para, Keepass uses the window title to be compatible with every program, not just web pages. Since browsers put the page title in the window title, this works fine with 99% of sites, except for ones with generic titles.

It would be safer against phishing if it identified sites by the URL, but it's not such a big risk that I'd abandon the program. I just check what site I'm on before hitting the keyboard combo.

If anything, I'm not sure that a password manager that reads URIs directly would be an improvement. because it would be pretty kludgey:

• How to determine that a url CAN be read? There's no protocol for this, you'd just have to have a whitelist of valid browsers (which might have to be by binary name to work crossplatform, which is pretty ugh).
• how to read the url? Simplest way is to abuse the clipboard by synthesizing Ctrl+L, Ctrl+C events. This would trash whatever's currently on clipboard though, and you have no guarantee that Ctrl+L / Ctrl+C bindings will work as expected (Firefox, at least, allows rebinding keys)

Requested feature:
Add the avatar post ID to the user/ API response OR
Add both avatar post ID and user level to the comment/ API response
Why it would be useful:
There is currently no way to get a users profile picture through the API.
I'd just like to make comments in my app look similar to the websites, and currently I'm getting (to view one post) the image, comment/index and user/index (< only for user level, no avatar).

Requested feature:
A way to search the Reason field for tag alias / implication listings

Why it would be useful:
Finding forum links

edit: or particular reasons

I briefly talked about this with parasprite, but I wanted this one out on the forum nevertheless for feedback.

Requested feature:

A metatag for filtering posts that you have edited (e.g. edit:hotunderthecollar).

Why it would be useful:

When it comes to certain tagging projects, you have to check posts if the tags are correct, lacking or incorrect. Doing so, you either fix the tags or add a random (but relevant) tag or two so that post has your edit on it, and then, when you add -edit:hotunderthecollar, it won't show up, so the posts that you have checked and or fixed won't clog up the first page anymore.

That's the main thing but I think more good can come from this.

HotUnderTheCollar said:

Sounds really great

\+1 for HUTC's suggestion, FWIW. Even cutting out the "oops, screwed up the tags" edit fixes, I still have a lot of edits under my figurative belt, and it's not always obvious if I've been by an image before.

HotUnderTheCollar said:
Requested feature:

A metatag for filtering posts that you have edited (e.g. edit:hotunderthecollar).

Filtering by sets works now.
You could add the ones that you've checked into a private checklist, and then search for -set:<yourprojectname>. For example, I'm currently using a set to clean out the mistagged posts from orgy. Which often gets mistagged for gangbang, and groups smaller than five.

Once I'm done adding the valid ones to the set, it'll be easy to search for new additions that need checking, and for tag wars.

rebane said:
Requested feature:
Add the avatar post ID to the user/ API response OR
Add both avatar post ID and user level to the comment/ API response
Why it would be useful:
There is currently no way to get a users profile picture through the API.
I'd just like to make comments in my app look similar to the websites, and currently I'm getting (to view one post) the image, comment/index and user/index (< only for user level, no avatar).

First one queued up for the next update.

Edit: We're going to do some more work on this one. I have a better idea.

Requested feature:

An Edit reason (optional) field for Wiki editing, similar to that of tag editing.

Why it would be useful:

It would improve the communication about why you or someone else added, changed or removed something in a Wiki page.

[unfinished]

Addendum to this request based partially on what NMNY mentioned about highlighted linking to specific comments [here] (copyright NMNY & Ratte, all rights reserved)

-
Requested feature:

Ability to link to highlighted forum posts in a similar way to the Respond function below a post, but with highlighting hahah these are 2 different functions

example

Why it would be useful:

Reasooons [tba]

titanmelon said:
[unfinished]

Addendum to this request based partially on what NMNY mentioned about highlighted linking to specific comments [here] (copyright NMNY & Ratte, all rights reserved)

-
Requested feature:

Ability to link to highlighted forum posts in a similar way to the Respond function below a post, but with highlighting hahah these are 2 different functions

example

Why it would be useful:

Reasooons [tba]

Isn't that exactly what the example link does? Links to that forum post, highlighted?

Yeah, but you can't easily get that link, like with the basic Respond | [Other] buttons

You have to:

• click on the individual post's timestamp
• get the url for the link that takes you back to the original forum with the post highlighted

..unless..there's another way to do that I'm not aware about?

Requested Feature: Stop downloading the thumbnails of blacklisted images

Useful because: It takes longer for the page to load, wastes site bandwith; and, as a user, I don't even want to see the stuff I have blacklisted, even if it's during its loading

It looks like you download the tags for every single image on a page at once, but you register them to the page immediately, and then hide them later? Couldn't that be done in the reverse order, so the image is never even downloaded?

I know this would make it harder to then display images when the blacklists are removed, when people have conditional blacklists; but, I think that problem could be solved, maybe register them to the bottom of the page? It's out of order, sure, but maybe order isn't as important in those cases. I don't know...

Thanks a ton!

Requested feature: A note at the bottom of edited forum posts that shows who last edited it, and when.

"Edited by Knotty Curls, Thursday 8 August 2013, 02:12 PM."

Why it would be useful: It may help cut down on abuse of the edit feature.

ruerator said:
Requested Feature: Stop downloading the thumbnails of blacklisted images

Useful because: It takes longer for the page to load, wastes site bandwith; and, as a user, I don't even want to see the stuff I have blacklisted, even if it's during its loading

It looks like you download the tags for every single image on a page at once, but you register them to the page immediately, and then hide them later? Couldn't that be done in the reverse order, so the image is never even downloaded?

I know this would make it harder to then display images when the blacklists are removed, when people have conditional blacklists; but, I think that problem could be solved, maybe register them to the bottom of the page? It's out of order, sure, but maybe order isn't as important in those cases. I don't know...

Thanks a ton!

For the time being, try opening a blank image and maximizing it, then when you load up a page, alt-tab over to it immediately so that the page still loads while you aren't seeing it. (Alternatively, make the blank image not actually maximized, with just the tabs at the top showing so you can see when the icon changes from the loading circle to the Esix icon)
Obviously this is only necessary if you have background loading off--If it's on, you can ctrl+Pg to another tab and let Esix finish loading that way.

As for a solution to the conditional blacklist problem, could always have a checkbox for "I want to be able to turn blacklisted items on and off" so that they can still be loaded the old way if it's ticked.

I'm currently trying to add a forum-thingy to my app and the API is somewhat uninformative.
The following additional information for the /forum/index API would be really nice :)

• count tag (like for /post/index/) for the forum-posts root element - usefull for pagination
• creation time-stamp for forum-post elements - to see if you'd necro
• last post time-stamp for forum-post elements* - get the last post time
• last post user / last post user-id* - mainly for quick and nice display.
• number or responses or response pages* - to quickly jump to the last page / maybe see if new responses were posted

with ?parent_id= set fields marked with * would be empty, maybe skip them in a /forum/show API
without the * marked fields I'd have to send 31 requests per forum page list to get the data I'd like to display. otherwise I'd only be 1

Also, the current /forum/show API is somewhat useless and some APIs like forum/create or dmail/inbox seem to exist but are undocumented

How about a button to turn the blacklist on and off on the posts page? Useful for tagging schedules/projects, otherwise you have to turn every tag off that you have blacklisted.

HotUnderTheCollar said:
How about a button to turn the blacklist on and off on the posts page? Useful for tagging schedules/projects, otherwise you have to turn every tag off that you have blacklisted.

There is a "button" on the side, that both tells you how many posts you have blacklisted and gives you the option to turn them off, via clicking on it and clicking the blacklisted name, but I don't know if that is what you mean.

rebane said:
I'm currently trying to add a forum-thingy to my app and the API is somewhat uninformative.
The following additional information for the /forum/index API would be really nice :)

• count tag (like for /post/index/) for the forum-posts root element - usefull for pagination
• creation time-stamp for forum-post elements - to see if you'd necro
• last post time-stamp for forum-post elements* - get the last post time
• last post user / last post user-id* - mainly for quick and nice display.
• number or responses or response pages* - to quickly jump to the last page / maybe see if new responses were posted

with ?parent_id= set fields marked with * would be empty, maybe skip them in a /forum/show API
without the * marked fields I'd have to send 31 requests per forum page list to get the data I'd like to display. otherwise I'd only be 1

Also, the current /forum/show API is somewhat useless and some APIs like forum/create or dmail/inbox seem to exist but are undocumented

This is on my priority list. :)

Siral_Exan said:
There is a "button" on the side, that both tells you how many posts you have blacklisted and gives you the option to turn them off, via clicking on it and clicking the blacklisted name, but I don't know if that is what you mean.

They mean a quick global on/off button. For instance, if you have 100 blacklisted tags in the sidebar, you need to click 100 times to completely disable the blacklist. The on/off button would temporarily disable parsing of the blacklist and unhide all posts on the page.

I forget if I've requested this before, but I would love it if the edit field when using "Edit Posts" mode would actually show up just above or below the specific row you're editing.

Also it would be nice if it would place the caret at the beginning or end of the tags every time you open a post in edit posts mode.

Siral_Exan said:
There is a "button" on the side, that both tells you how many posts you have blacklisted and gives you the option to turn them off, via clicking on it and clicking the blacklisted name, but I don't know if that is what you mean.

Yeah but you have to turn all of them off, and if you look at how many tags some people have on their blacklist (forum #193019), that is going to take a little while each time, especially in collaboration posts...

i don't suppose theres a way to filter out the "http:" or "https:" part of links when you click respond to quote someones post is there? it tends to break your post and if not removed manually the resulting response you try to post gets cut off at the first mention of http: or https: in any quoted links.

the links in the "What is your favorite "irreverent" humor..." thread for example. if left as plain text when quoting such as https: //www.youtube.com/watch?v=a1AHDNTXYSA. if that space between the : and / wasn't there then any text after that point in the post would get cut off (it's still there if you try to edit the post but it's not visible otherwise).

an example of the issue: there is text below this link https://www.youtube.com/watch?v=a1AHDNTXYSA

hello there

treos said:
i don't suppose theres a way to filter out the "http:" or "https:" part of links when you click respond to quote someones post is there? it tends to break your post and if not removed manually the resulting response you try to post gets cut off at the first mention of http: or https: in any quoted links.

the links in the "What is your favorite "irreverent" humor..." thread for example. if left as plain text when quoting such as https: //www.youtube.com/watch?v=a1AHDNTXYSA. if that space between the : and / wasn't there then any text after that point in the post would get cut off (it's still there if you try to edit the post but it's not visible otherwise).

an example of the issue: there is text below this link https://www.youtube.com/watch?v=a1AHDNTXYSA

hello there

Actually, that's the same problem as spaces not showing up after punctuation. It's only visible to you, and only immediately after generating the comment; refreshing the page fixes the problem.

Requested feature: Each subject in a post has a separate list of character tags describing them.

Why it would be useful: This feature would allow incredibly specific searches and blacklists to be made, especially in regards to particular characters and fetishes.

With our current tagging system, if someone wanted to search for female elephants, they could enter the "female" and "elephant" tags, but many of the posts would be needlessly irrelevant to their intended search. They would get many male elephants, and females of other species, so long as both tags were in the post. They could add the "solo" tag to their search, but this would exclude a vast amount of artwork that includes female elephants.

While this would make correctly tagging a post more difficult, once correctly tagged, the entire database would become much more accurate and precise.

The system would be rather simple. The subject closest to the top-left corner (this corner is arbitrary) is Subject 1, the next closest is Subject 2, and so on, and when tagging, similar to how there are artist and species tags, you could associate tags as a subject, using a similar format: "subject1:green_eyes". This tag would denote the subject closes to the top-left corner to have green eyes. More tags would be associated with that subject, such as name, species, gender, colors, current sexual roles and positions, as well as visible body parts. The result would allow users to search the site for tags grouped under the same subject, allowing for specific searches to be made, which would be incredibly useful for finding art that matches ones tastes, searching for a particular character in a particular situation, or easily locating an unknown character or artist simply by knowing a basic description of a subject in a post. This system would also apply to blacklists, allowing users to be incredibly exact in the posts they don't wish to see.

It would be a daunting task, but with the sheer amount of posts that are made here, more organization is critical to maintaining a user-friendly database, and the longer we wait, the harder it will be to implement organizational measures in the future.