Bug: Searching the database and downloading

Expected behavior:
1. Able to search and see all the what available under what what I'm searching. Ex: Like searching vulpix and get 15 pages.

2. Actually saving the webpage

Actual behavior:
1. when Im not log on, I can see all the search hits like 15 pages for vulpix but when I'm login on, I only get 5 pages.

2. Its fails to download and save the page or looks like when I save it as a partial save web page.
Steps to duplicate:
1. Tried different search words like tom_smith and others, keep getting the same result.

2. Tried many times now.

Bug: +favorite icon doesn't work
Expected behavior: save picture to favorites
Actual behavior: refreshes the page

Could this be real? Ghost posts? In post #248285, neither the resized version nor the full image load and going to the direct file URL returns a 404 (internal e621 page, not CF's). The thumbnail works fine, though: post #248285

(The comment you see there was because I had to see it from the source, otherwise I wouldn't commented)

Xch3l said:
Could this be real? Ghost posts? In post #248285, neither the resized version nor the full image load and going to the direct file URL returns a 404 (internal e621 page, not CF's). The thumbnail works fine, though: post #248285

(The comment you see there was because I had to see it from the source, otherwise I wouldn't commented)

I just uploaded something and it doesn't appear to several people.

Xch3l said:
Could this be real? Ghost posts? In post #248285, neither the resized version nor the full image load and going to the direct file URL returns a 404 (internal e621 page, not CF's). The thumbnail works fine, though: post #248285

(The comment you see there was because I had to see it from the source, otherwise I wouldn't commented)

That's been happening to quite a few images in the last 20 or so minutes (most of them were uploaded years ago). The image doesn't load, but the thumbnail and everything else works fine. Just no way to view the image, not even through the download link. Only happening with some images, seems random for which images are affected. ETA: The same symptoms are showing up on a relatively small number of thumbnails as well. Just took me a little while to run into one.

I've also been getting a lot of error messages when trying to submit tag edits, having to retry between 2-5 or so times before it will go through. (Error is a page of text starting with "ActiveRecord::StatementInvalid in PostController#update" at the top, in case that helps).

So my guess is something is either breaking and/or being worked on behind the scenes. Hopefully they're on top of it and it'll iron itself out soon. *hopefully*

ETA: in all irony, I got an error message the first time I tried to post this comment, it popped up saying "nobody here but us chickens" claiming this page doesn't exist or the url might be bad. As if. Obviously something is glitched.

Fixed

furrypickle said:
That''s been happening to quite a few images in the last 20 or so minutes (most of them were uploaded years ago). The image doesn''t load, but the thumbnail and everything else works fine. Just no way to view the image, not even through the download link. Only happening with some images, seems random for which images are affected.

I''ve also been getting a lot of error messages when trying to submit tag edits, having to retry between 2-5 or so times before it will go through. (Error is a page of text starting with "ActiveRecord::StatementInvalid in PostController#update" at the top, in case that helps).

So my guess is something is either breaking and/or being worked on behind the scenes. Hopefully they''re on top of it and it''ll iron itself out soon. *hopefully*

ETA: in all irony, I got an error message the first time I tried to post this comment, it popped up saying "nobody here but us chickens" claiming this page doesn''t exist or the url might be bad. As if. Obviously something is glitched.

Yep, I got an error when first submitting the comment on that post. Apparently, they're pushing a new update. I think, because I've noticed these things:

• The "You have mail" notification bar is thinner and has a dismiss button

Viewing posts now have "Post #xxxx: [Artist]". That's random, though. Sometimes that appears or the old "e621 [tags]".

Apparently, it's caused because the site wants to store two IPs where the controller expects one.

PGError: ERROR:  invalid input syntax for type inet: "xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx"
LINE 1: ..., 'active', 0, 'f', '2014-06-10 01:36:45.724205', 'xxx.xxx.x...
-------------------------------------------------------------^

Also, I got that error again like 4 times trying to post this

Bug: Thumbnail-Error
Expected behavior: It should show the "Deleted" thumbnail
Actual behavior: It shows the normal thumbnail of the deleted pic.
Steps to duplicate: Looking at comments page/Search yourself in comments.

Bug: Posting after previewing leaves the preview still visible.

Expected behavior: It should hide the preview.

Actual behabior: What I've said.

Steps to duplicate: Write -relevant- stuff on the response box, click preview and then post

Bug: Wraparound on long name on posts.
Expected Behaviour: Name all one one line.
Actual Behaviour: Name is wrapped around to the next line if it's too long.
Steps to duplicate: Have a long username and post a comment, or just look at any of my posts, it'll probably happen on this one too.

Arimah said:

Password reset email missing reset key

Bug: The password reset email has no reset key.

Expected behavior: The link in the email should contain the reset key.

Actual behavior: The full link URL is:

http://e621.net/user/reset_password?key=#(@reset_keys[0][1]}

Note the #( instead of #{.

Steps to duplicate: Request a password reset.

Simple fix here. Pushed to our our repo. This will be resolved in the very near future.

Sorry for the inconvenience. :(

Jatix said:
Bug: Thumbnail-Error
Expected behavior: It should show the "Deleted" thumbnail
Actual behavior: It shows the normal thumbnail of the deleted pic.
Steps to duplicate: Looking at comments page/Search yourself in comments.

I still have no idea why, but the deleted-preview image keeps getting... deleted

Xch3l said:
Yep, I got an error when first submitting the comment on that post. Apparently, they're pushing a new update. I think, because I've noticed these things:

• The "You have mail" notification bar is thinner and has a dismiss button

Viewing posts now have "Post #xxxx: [Artist]". That's random, though. Sometimes that appears or the old "e621 [tags]".

Apparently, it's caused because the site wants to store two IPs where the controller expects one.

PGError: ERROR:  invalid input syntax for type inet: "xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx"
LINE 1: ..., 'active', 0, 'f', '2014-06-10 01:36:45.724205', 'xxx.xxx.x...
-------------------------------------------------------------^

Also, I got that error again like 4 times trying to post this

That issue should be taken care of now. I'm just dumb and forgot that XFF headers could have multiple IP addresses in them.

ThatBloodySquirrel said:
Bug: Wraparound on long name on posts.
Expected Behaviour: Name all one one line.
Actual Behaviour: Name is wrapped around to the next line if it's too long.
Steps to duplicate: Have a long username and post a comment, or just look at any of my posts, it'll probably happen on this one too.

Consider it fixed. Just need to push it out after I fix a few other bugs.

I'm not sure that this is a bug per se, but it's not correct behaviour:

"bug": When you post to a forum thread, it is marked unread
Expected behaviour: the thread is not marked unread; clearly you must have read the post that you composed.
Actual behaviour: Thread is marked unread

@Staff:
I love you so much right now.
Thank you for fixing the API.

Bug: "Tags" page displaying tags ordered by number/count of uses (least to greatest) instead of ordering by date created order under "order by date".

Expected Behaviour: that selecting it show tags order by date, will show them actually ordered by date, most recent first.

Actual Behaviour: same as ordering by # count of tag uses, except arranged from least to greatest instead of greatest to least.

Steps to duplicate:
1. go to https://e621.net/tag/index?order=date
2. It's set on ordering by date on default, but instead of doing it by date, it shows tags in order of # of tag uses from least to greatest. Been doing it for a good day or so now. https://e621.net/tag?name=&type=&order=date[/s]Fixed.

furrypickle said:
Bug: "Tags" page displaying tags ordered by number/count of uses (least to greatest) instead of ordering by date created order under "order by date".

Expected Behaviour: that selecting it show tags order by date, will show them actually ordered by date, most recent first.

Actual Behaviour: same as ordering by # count of tag uses, except arranged from least to greatest instead of greatest to least.

Steps to duplicate:
1. go to https://e621.net/tag/index?order=date
2. It's set on ordering by date on default, but instead of doing it by date, it shows tags in order of # of tag uses from least to greatest. Been doing it for a good day or so now. https://e621.net/tag?name=&type=&order=date

Can confirm. Going to one of the later pages -- eg 2500 or so, makes it fairly obvious.

However, this bug doesn't manifest if you tick 'show empty tags'. So I'm guessing it may be a problem with the parsing of the submitted parameters.

Bug: Tag Implication page seems to be broken

Expected Behaviour: Webpage to load

Steps to duplicate:
1. Click on the implications button form the Tags page

Bug:
Invalid response when creating a post comment via the API:
/comment/create.json

Expected behavior:
When I use the API to create a comment on a post, e621 should
1) create the comment
2) return a valid response

Actual behavior:
e621 creates the comment
but the response text consists of a single space

Steps to duplicate:
Use the API to add a comment to a post

Bug:
Odd spacing in the fade-in preview when you post a comment.

Expected behavior:
In the new comment system, a posted comment fades into view without refreshing the page. It is expected that the comment seen represents the comment actually posted.

Actual behavior:
Some spaces are missing in the "preview" comment. The missing spaces seem to revolve around punctuation. Spacing is missing around the Reply/Report/Upvote/Downvote region as well.

Steps to duplicate:
Post a comment and do not manually refresh the page.

trevorlanch said:
Bug:
Odd spacing in the fade-in preview when you post a comment.

Expected behavior:
In the new comment system, a posted comment fades into view without refreshing the page. It is expected that the comment seen represents the comment actually posted.

Actual behavior:
Some spaces are missing in the "preview" comment. The missing spaces seem to revolve around punctuation. Spacing is missing around the Reply/Report/Upvote/Downvote region as well.

Steps to duplicate:
Post a comment and do not manually refresh the page.

Can confirm. Been noticing this for a few days now. Have also seen a few other users mentioning it.

Except just to clarify, it's not happening when you hit the actual "preview" button. But it happens after you actually post the comment and it's magically added to the page without refreshing it. It has spacing errors until you manually refresh the page, at which point the comment will appear as normal. Happens to both comments and when posting in forums.

ETA: Fixed, as far as I know.

Bug:
Usernames can consist of a single space

Expected behavior:
Usernames should not be able to consist only of a single space

Actual behavior:
Usernames can consist of a single space

Steps to duplicate:
https://e621.net/user/show/140590

^ Reminds me of this story of using '[escape][escape][escape]' (ie. press Escape three times) as your login password. Only works on ttys or terminal emulators, but kind of funny.

Bug:
type:gif no longer works

Expected behaviour:
type:gif returns a list of gif posts, much as type:jpg returns a list of jpg posts (I have confirmed type:jpg still works).

Actual Behaviour:
E621 generates a 404 page. Not even an empty search results page, a 404 page. Rather bizarre.

Steps to duplicate:
Compare type:gif results with type:jpg results

savageorange said:
^ Reminds me of this story of using '[escape][escape][escape]' (ie. press Escape three times) as your login password. Only works on ttys or terminal emulators, but kind of funny.

Bug:
type:gif no longer works

Expected behaviour:
type:gif returns a list of gif posts, much as type:jpg returns a list of jpg posts (I have confirmed type:jpg still works).

Actual Behaviour:
E621 generates a 404 page. Not even an empty search results page, a 404 page. Rather bizarre.

Steps to duplicate:
Compare type:gif results with type:jpg results

That's weird.
https://e621.net/post/index/1/type:gif works for me
https://e621.net/post/index/1/type:jpg displays a 404 page

edit: now both display a 404 page :-/

savageorange said:
type:gif

Munkelzahn said:
https://e621.net/post/index/1/type:gif works for me

What I find weird is that the link by savageorange gives me 404, but the link by Munkelzahn doesn't. Even though they show exactly same address. Tried multiple times to same result. One works, other doesn't.

Bug:
Blacklisted thumbnails in the "popular" section not displaying the "blacklisted" thumbnail correctly.

Expected Behaviour:
Thumbnails of blacklisted images should either not show at all or display the special "Blacklisted" thumbnail.

Actual Behaviour:
thumbnail doesn't show instead the image's tags appear over it and bleed out over the rest of the page.

Steps to duplicate:
Having images that are on your blacklist while browsing through popular_by_day/week/month section?

Edit : Blacklisted users avatars appear to be afflicted with same bug.

Munkelzahn said:
That's weird.
https://e621.net/post/index/1/type:gif works for me
https://e621.net/post/index/1/type:jpg displays a 404 page

edit: now both display a 404 page :-/

Tony suggested that this is an issue with Cloudflare caching.
I responded by changing https to http in the url bar, which mysteriously seemed to fix it.. even though the page that actually loaded was shown as https. This sort of sounds like it could be a cache issue (and definitely sounds similar to the behaviour you report Nyteshade), but I'm not really clear why type:gif would have ever produced a 404 (as opposed to no search results).

savageorange said:
Tony suggested that this is an issue with Cloudflare caching.
I responded by changing https to http in the url bar, which mysteriously seemed to fix it.. even though the page that actually loaded was shown as https. This sort of sounds like it could be a cache issue (and definitely sounds similar to the behaviour you report Nyteshade), but I'm not really clear why type:gif would have ever produced a 404 (as opposed to no search results).

It was (is still? dunno) a bug with our server setup that treated links ending in a common file extension like gif as a static file, which obviously doesn't exist. But I'm fairly sure we fixed it.

Bug: https://e621.net/takedown/new, the second sentence says [email protected] but the mailto: link links to [email protected]

Expected behavior: mailto: should link to [email protected] as well.

Actual behavior: It doesn't.

Steps to duplicate: Click link.

I'm not sure if this is a bug or not, but I noticed that one of ippiki_ookami's comments had a -1 rating. I thought we were unable to downvote admin comments. Is it a bug?

JoeX said:
I'm not sure if this is a bug or not, but I noticed that one of ippiki_ookami's comments had a -1 rating. I thought we were unable to downvote admin comments. Is it a bug?

At one point admin comments couldn't be downvoted at all. This was changed in a recent update so that admin comments can be downvoted, but the admin's comment will always be displayed, regardless of what you have your comment score threshold set to in your account settings.

Thank you for the clarification, Char!

Something I just happened to notice.

Bug: Thumbnails of deleted images used as avatars show the image's actual thumbnail instead of the "Deleted" placeholder thumbnail after showing hidden comments on the comments page.

Expected behavior: The deleted thumbnail remains as the deleted thumbnail.

Actual behavior: After clicking "X comments hidden." to show the hidden comments, deleted images used as avatars will change to their original thumbnail. This only happens to deleted image avatars on the post that you show the hidden comments on. Deleted image avatars on other posts on the comments page are unaffected.

Steps to duplicate:

1. Go to the comments page and find a post that has enough comments that there are some hidden (unsure if this also applies to showing comments below the vote threshold) and one of the comments that isn't already hidden is from a user who has a deleted image set as their avatar.

2. Show the hidden comments.

I did my best to make sense explaining that, though my brain melted a bit reading it back....

The comments that I noticed this happening on were the comments on post #89969, with Morp's avatar (post #382342) being the one that showed it's original thumbnail, if that helps at all.

Bug:Empty page in query. This may possibly boil down to 'deleted images matching a query are wrongly included when calculating page count'

Expected behaviour : all pages in a query contain at least one result, even if said result is blacklisted. In the particular test case, the correct behaviour seems to be to return 2 pages of results, rather than 3.

Steps to duplicate: Visit this link . No posts are listed.

Other irregularities exist with this query -- for example, the number of posts shown on each page is inconsistent, even after unhiding blacklisted images. (page 2 shows 70 images, page 1 shows 75 images). I have images per page set to 75.

savageorange said:
Bug:Empty page in query. (...)

Let me show you something a little more interesting. I don't know who pointed it out, but you get less results when you're logged in. So, for me, even page 4 has posts while I'm not logged in.

EsalRider said:
Let me show you something a little more interesting. I don't know who pointed it out, but you get less results when you're logged in. So, for me, even page 4 has posts while I'm not logged in.

Maybe you're using different "posts per page" setting while logged in?

...that reminds me: the description for that setting says that the max is 320. But it seems to cap out at 150 images per page. Seems like a bug.

savageorange said:
Bug:Empty page in query. This may possibly boil down to 'deleted images matching a query are wrongly included when calculating page count'

Correct, this is because there are several deleted images for that query. The dev team is aware of it, but I'm not sure that there's going to be a good fix for it.

EsalRider said:
Let me show you something a little more interesting. I don't know who pointed it out, but you get less results when you're logged in. So, for me, even page 4 has posts while I'm not logged in.

This is because your account settings are set to show a higher number of posts per page than what anonymous users see, which is 45 posts per page. You'll see the same number of pages if you adjust your posts-per-page setting to 45.

Char said:
This is because your account settings are set to show a higher number of posts per page than what anonymous users see, which is 45 posts per page. You'll see the same number of pages if you adjust your posts-per-page setting to 45.

Oh... Didn't notice that... Though it's a bit strange that default values differ for guests and users. Strange for me, at least.

And for the record, I'm using the default 75 posts per page value.

Bug
Moderation queue: no # in flag reason

Expected behavior
If the flag reason contains a #, it should be displayed in the moderation queue.

Actual behavior
For post #500819, it's not.

Steps to duplicate
Go to the moderation queue.

Moderation queue: http://imgur.com/BRx12CP
Post: http://imgur.com/YFCUoVB

I'm not sure if this is a bug, but everyone's tag edit counts seem to have gone down by about 10%. That seems a bit odd.

Genjar said:
I'm not sure if this is a bug, but everyone's tag edit counts seem to have gone down by about 10%. That seems a bit odd.

From the recent major update's changelog:

Post tag histories no longer generate blank edits, and existing blank edits will soon be purged from the database

EsalRider said:
From the recent major update's changelog:]
Well, yes. But I'd be surprised if everyone had that many blank edits. I'd wager that I didn't have more than ~500 myself, but my count has gone down by 10000.

Genjar said:
Well, yes. But I'd be surprised if everyone had that many blank edits. I'd wager that I didn't have more than ~500 myself, but my count has gone down by 10000.

Now that's a pretty nice amount of tag edits missing. I'm still saying they were blank edits, though. I've seen cases of priv+ users having a nice long stack of blank edits on posts for no apparent reason. Maybe a tag script glitched and sent multiple requests or something.

EsalRider said:
Now that's a pretty nice amount of tag edits missing. I'm still saying they were blank edits, though.

Nah, I don't think that's possible. It has even gone down for member-level users, who don't have access to the scripts. And for users like loc0, who I've never seen make blank edits.

It has definitely pruned more than just the blank ones, though I have hard time figuring out what.

Noticed my tag edits dropped too.

Was around 1315 or so. Down to 1273.

Genjar said:
Nah, I don't think that's possible. It has even gone down for member-level users, who don't have access to the scripts. And for member-level users like loc0, who I've never seen make blank edits.

It has definitely pruned more than just the blank ones, though I have hard time figuring out what.

Yeah, me too. I lost a couple thousand (I was around 17k, now around 15k). I don't know where all the "missing" tag edits went to either. I'm trying not to worry about it, but I'm hoping it doesn't mean some of that work was lost somehow.

ETA: Unexplained but not a major issue

Genjar said:
Nah, I don't think that's possible. It has even gone down for member-level users, who don't have access to the scripts. And for users like loc0, who I've never seen make blank edits.

It has definitely pruned more than just the blank ones, though I have hard time figuring out what.

I've lost about 400-500 as well, and i never do blank edits. The only thing I can think of if it deleted ones where you edit the post's parent field before it gets deleted.

pc-king said:
I've lost about 400-500 as well, and i never do blank edits. The only thing I can think of if it deleted ones where you edit the post's parent field before it gets deleted.

I'm pretty sure I haven't done enough parent/child edits (both deleted and non-deleted) to explain all the missing ones for me. But maybe if it also stopped counting the source edits too? I don't know. I hope that's not the case because those types of edits count too. Source edits are usually even more work in my experience.

Another theory I wondered about is whether it retroactively ignored all the tag edits to images that have since been deleted? Though I don't know why that would make any sense when it still counts the tag as being in use by the deleted image, so surely it would still count the edit that put it there as well.

ETA: Unexplained, but not a major issue.

Bug:
/post/update.xml API, given tag edits, returns HTML rather than XML when hourly tagging limit has been reached.

Expected behaviour:
A standard XML response is given, with a 'reason' attribute describing the problem, per the API help page.

Actual behaviour:
An HTML page is sent, AFAICS this page is the same as what you would see when attempting to make the tag edit through a browser.

Steps to reproduce:
1. Use a standard 'member' account
2. Make 151 tag edits in an hour (eg. tagging missing solo/duo/group in the search -solo -duo -group)

Comment:
For now I am treating any HTML response as an indication that the hourly tagging limit is reached. This is functional but probably incorrect.

In case it is not clear, post/update.xml returns actual XML the rest of the time (eg. when tags are successfully updated).

When an exception is encountered by the server, it also always returns HTML; This is a more understandable behaviour.

Bug: When attempting to save a tag edit, it will sometimes stall for over a minute and then eventually show one of several error messages. Refreshing over and over will sometimes get it to save the tag edit eventually. Does not happen on every image or every time a tag edit is attempted, but has been occurring maybe half the time in the last two hours or so. When it decides to act up, the problem is persistent for that image for awhile, even if starting over from a new window.

Expected behavior: That a tag edit will be quickly saved with no failures, no error message and no long hanging while thinking about it.
Actual behavior: Inconsistent results. Some tag edits save with no problem and quickly. The very next one might stay hanging for a few minutes and then give an error message without saving the edit. Persistent refreshing often returns the same hanging and then error message scenario 4-10 times. Might eventually save the tag edit successfully. Earlier today was tagging with none of these problems, but tonight it's been nearly impossible to tag much at all. The first error message example is usually the error message I get. The 2nd example I've only noted once tonight but thought it might be useful to know what it said.
Steps to duplicate: It's inconsistent, seems to have good moments and bad moments. But trying to do more than a handful of tag edits should be enough luck to run into it. It's not happening on every tag edit attempt, but it has been happening frequently during the last couple hours.

Between this and the "website under heavy load" errors, trying to tag tonight has been especially slow.

Fixed

furrypickle said:
Bug: When attempting to save a tag edit, it will sometimes stall for over a minute and then eventually show one of several error messages. Refreshing over and over will sometimes get it to save the tag edit eventually. Does not happen on every image or every time a tag edit is attempted, but has been occurring maybe half the time in the last two hours or so. When it decides to act up, the problem is persistent for that image for awhile, even if starting over from a new window.

Think I can confirm this, I encountered it a few times today. Fortunately, it was as part of the process of running my tagging de/queuer, so the edits were only temporarily deferred rather than lost.

Bug: Blacklisted tags still appear in the search

Expected behavior: Blacklisted tags are supposed to be hidden during search. Every image associated to that tag must be hidden.

Actual behavior: The images associated to the blacklisted tags still appear in my search

Steps to duplicate: Go to e621 where the search function is. Type the blacklisted tag. Images will appear instead of being hidden

jsno said:
Bug: Blacklisted tags still appear in the search

Expected behavior: Blacklisted tags are supposed to be hidden during search. Every image associated to that tag must be hidden.

Actual behavior: The images associated to the blacklisted tags still appear in my search

Steps to duplicate: Go to e621 where the search function is. Type the blacklisted tag. Images will appear instead of being hidden

Works for me (eg searching 'nezumi' returns 8 pages, each of which contain no images.). Have you installed a script blocker like NoScript recently?

savageorange said:
Works for me (eg searching 'nezumi' returns 8 pages, each of which contain no images.). Have you installed a script blocker like NoScript recently?

No I didn't install any script blocker in my browser. I tried with different browsers and didn't help. Is something wrong with my account or the site?

savageorange said:
Works for me (eg searching 'nezumi' returns 8 pages, each of which contain no images.). Have you installed a script blocker like NoScript recently?

I found a way to fix the issue for now. Search in the search engine, and when the results appear use the options "back to previous page" and then "to next page" on the browser...

Blacklist appears to not be working.
No "Hidden" section on the left side of the site, it seems just not to be working atm.

Peekaboo said:
Blacklist appears to not be working.
No "Hidden" section on the left side of the site, it seems just not to be working atm.

Looks like something broken with javascript. Whenever the news header still shows up at the top of the page (assuming you've previously hidden it), blacklisting doesn't work. Refresh the page enough times until the news header hides itself, and suddenly blacklisting is working as well. I've alerted the devs about it.

Char said:
Looks like something broken with javascript. Whenever the news header still shows up at the top of the page (assuming you've previously hidden it), blacklisting doesn't work. Refresh the page enough times until the news header hides itself, and suddenly blacklisting is working as well. I've alerted the devs about it.

I'm glad this is already being looked at. I almost had a shitfit when I saw "10 untagged pony pictures on the front page" but it was just the blacklist.

I'm only having issues with the blacklist on page 2. Works fine everywhere else on the index thus far.

Noooo now I have to see girlyparts :C

Blacklist not working here either (though, the above posters are right, sometimes it works.)

Char said:
Looks like something broken with javascript. Whenever the news header still shows up at the top of the page (assuming you've previously hidden it), blacklisting doesn't work. Refresh the page enough times until the news header hides itself, and suddenly blacklisting is working as well. I've alerted the devs about it.

Weird. What has to do the news box with the blacklist? I have not hidden it yet (since the last update) but now that I know that, I won't hide it either... (curiosity, y'know?)

Maybe it's a cookie problem (the blacklist and last hidden news notice are stored there)...

Xch3l said:
Weird. What has to do the news box with the blacklist? I have not hidden it yet (since the last update) but now that I know that, I won't hide it either... (curiosity, y'know?)

Maybe it's a cookie problem (the blacklist and last hidden news notice are stored there)...

No, I was only pointing out the newsbox because it also depends on javascript to hide it if you've set it to be hidden. So if the newsbox is showing up at the same time that the blacklist isn't working, and the blacklist IS working at the same time that the newsbox is hidden, then that means it's not a problem with just the blacklist functionality, but rather a problem with javascript itself on the site. Both are affected when javascript doesn't work.

Char said:
No, I was only pointing out the newsbox because it also depends on javascript to hide it if you've set it to be hidden. So if the newsbox is showing up at the same time that the blacklist isn't working, and the blacklist IS working at the same time that the newsbox is hidden, then that means it's not a problem with just the blacklist functionality, but rather a problem with javascript itself on the site. Both are affected when javascript doesn't work.

It's too bad you aren't a dev, because you seem to already know half of the problem. I can't even browse with the amount of things I have blacklisted.

Bug: Searching for inpool:true returns an exception.

PGError: ERROR:  canceling statement due to statement timeout
: SELECT COUNT(*) FROM posts p WHERE true AND p.status <> 'deleted' AND ((SELECT COUNT(*) FROM pools_posts WHERE post_id = p.id) > 0)

It also takes a while to load.

Edit 2: Nevermind. It's just the timeout that causes it. Maybe giving it more time could fix it?

. . .

Edit: I have found the error for the missing blacklisted preview. Currently, it points to ''/blacklisted-preview.png'' which does not exist. It should be pointing to ''images/blacklisted-preview.png'' :)

Aurali said:
Found something that's broken or doesn't work how it should? Post it here!.

If you wish you can use the template below for easier structuring.

[b]Bug:[/b]

[b]Expected behavior:[/b]
My screen keeps freezing when I click to go back 

[b]Actual behavior:[/b] 

[b]Steps to duplicate:[/b]

If I choose to unhide hide a forum post, it tells me "error, you are already logged in"
Don't know if you can duplicate.
Get drunk, try to unhide a forum post, see if "error, you are already logged in." appears.
forgive me for getting drunk, as admins, you can check the time stamp of events, right?

edidaf said:
If I choose to unhide hide a forum post, it tells me "error, you are already logged in"

Only admins can unhide posts, even the ones that you've hid yourself.
Though it used to say "access denied", so that error is kinda odd..

Genjar said:
Only admins can unhide posts, even the ones that you've hid yourself.
Though it used to say "access denied", so that error is kinda odd..

The thing about being drunk, do I want it hidden, or not? I will let our awesome e621 staff decide whether or not it should be hid or not. If I get a neutral, or worse, it simply means don't grt drunk and MSG at the same time.

Another bug, I think. When the last person to update a topic, posts, it's not supposed to show as a forum update for that person. At least, I think I read that in one of the change log updates. It really does not bother me, but if it isn't supposed to, I thought I'd mention it.