tapnek said:
You mean tags that nobody should use or tags that are in the default blacklist?
Tags like the female tag, like I said^^. (First scenario)
Posted under General
This topic has been locked.
Provence said:
Do we have a wiki page where blacklisted tags are listed?
Such tags like female etc.(Not really an issue, but is probably a shorter question)
List of disambiguation pages is the closest I can think of. Otherwise, there really isn't one. We can either create a new one, or roll disallowed tags into the List of disambiguation pages wiki.
BrokenEagle98 said:
List of disambiguation pages is the closest I can think of. Otherwise, there really isn't one. We can either create a new one, or roll disallowed tags into the List of disambiguation pages wiki.
I'd suggest to put them into the howto:tag wiki.
That wiki is acessible from the upload page and should be read anyway^^.
@evazion
I think that in that account something broken (I don't know if it exclusive for this, though):
user #13793
Here an image (http://i.imgur.com/j3bn8RA.png) what I mean (or where this bug works).
When clicking "Uploads", then everything is fine, because I get user:Not_One_Of_Us (with underscores)
When clicking "Favorites", I get an error message, because i get ordfav:Not_One Of Us (no underscore)
When using the same option in the statistics above, then everything works. So there is something broken with the Favorite search in the image.
Provence said:
@evazion
I think that in that account something broken (I don't know if it exclusive for this, though):
user #13793
Here an image (http://i.imgur.com/j3bn8RA.png) what I mean (or where this bug works).
When clicking "Uploads", then everything is fine, because I get user:Not_One_Of_Us (with underscores)
When clicking "Favorites", I get an error message, because i get ordfav:Not_One Of Us (no underscore)When using the same option in the statistics above, then everything works. So there is something broken with the Favorite search in the image.
Seems like a bug with the Danbooru EX script you're using.
Nitrogen09 said:
Seems like a bug with the Danbooru EX script you're using.
Can confirm. Just tried it out myself, and it exists only when DanbooruEx is turned on. The standard "Favorites" link redirects to the favorites page, e.g. http://danbooru.donmai.us/favorites?user_id=13793.
Regardless, this conversation should be in topic #13167 instead...
I didn't see these problems mentioned within the last two pages, so...
For the past week, at least once a day, an attempt to go to or refresh a Danbooru page returns the following error:
ActiveRecord::StatementInvalid exception raised
PG::QueryCanceled: ERROR: canceling statement due to statement timeout : SELECT "dmails".* FROM "dmails" WHERE "dmails"."owner_id" = $1 AND (is_read = false and is_deleted = false) ORDER BY dmails.id desc LIMIT 1
app/views/layouts/default.html.erb:88:in `_app_views_layouts_default_html_erb___4319382528528581785_69888694139880'
app/controllers/pools_controller.rb:18:in `index'
Refreshing again fixes things, but I'm wondering if this may just be a symptom of something else.
In addition to the above, my subscriptions haven't updated for the past week. This may be a totally unrelated issue, of course, but it doesn't hurt to mention.
Moonspeaker said:
I didn't see these problems mentioned within the last two pages, so...
For the past week, at least once a day, an attempt to go to or refresh a Danbooru page returns the following error:
Refreshing again fixes things, but I'm wondering if this may just be a symptom of something else.
In addition to the above, my subscriptions haven't updated for the past week. This may be a totally unrelated issue, of course, but it doesn't hurt to mention.
Subscriptions don't update anymore topic #13612
edit: wrong link
The issue Moonspeaker is describing is related to the DMail checking mechanism that occurs whenever you go to a different page to see whether you have new DMail or not. I've seen similar timeout errors with other searches when there is a large time duration since the last occurrence. So if the last unread/undeleted dmail was a while back, it increases the likelihood of the above occurring.
Regardless, there should be a graceful failing mechanism so that the above doesn't occur. Will create an issue on GitHub.
Created issue #2886.
Updated
Randeel said:
Subscriptions don't update anymore topic #13612
edit: wrong link
<Smacks forehead> I even saw the notice about that change, and I completely forgot about it. I've migrated my subscriptions now, so we'll see what that does.
BrokenEagle98 said:
The issue Moonspeaker is describing is related to the DMail checking mechanism that occurs whenever you go to a different page to see whether you have new DMail or not. I've seen similar timeout errors with other searches when there is a large time duration since the last occurrence. So if the last unread/undeleted dmail was a while back, it increases the likelihood of the above occurring.
Regardless, there should be a graceful failing mechanism so that the above doesn't occur. Will create an issue on GitHub.
Edit:
Created issue #2886.
Appreciate it.
@Provence: Bug noted, thanks. I haven't had much free time to devote to Danbooru lately though, so it will be a while before I can get to it.
@Moonspeaker: As BrokenEagle said, this happens because the server is taking too long to find your last unread dmail. Therefore, as a workaround, if you keep a recent unread dmail in your inbox I think it will stop it from timing out.
BrokenEagle98 said:
Not sure this is worth filing an issue, but I noted the following with the updating of a particular wiki...
I added a red circle highlighting the issue. Basically, very long tags/wikis play havoc with the site layout. The tag/wiki is Kuouzumiaiginsusutakeizumonokamimeichoujin Mika if you have trouble reading the text.
One solution, if one were to be pursued, could be to add Zero Width Spaces every 25 characters or so to break up very long character strings like that.
A similar problem occurs with long usernames in comment sections. Observe the comments for commenter:GiantCaveMushroom and notice how his name is too long, so the final 'm' wraps around onto a new line by itself.
There are a few possible solutions:
I actually experimented with the "insert zero width spaces at potential word breaks" approach in my userscript a while back. It turns out though that hyphenating words in an optimal manner is a difficult problem. See https://github.com/mnater/Hyphenopoly; note the complex algorithm and how it requires large pattern files for each language. Also, inserting invisible zero-width spaces inside tags could cause issues with people copy-pasting these tags to other locations.
All in all I think it would be simplest to use `word-wrap: break-word`.
evazion said:
@Provence: Bug noted, thanks. I haven't had much free time to devote to Danbooru lately though, so it will be a while before I can get to it.
@Moonspeaker: As BrokenEagle said, this happens because the server is taking too long to find your last unread dmail. Therefore, as a workaround, if you keep a recent unread dmail in your inbox I think it will stop it from timing out.
As there doesn't appear to be a "Mark as unread" option, I'll try to remember not to read the next Dmail I get, thanks. :-) Meanwhile, it's not a terrible site-breaker, just an annoyance.
jmm said:
While I'm not sure if this thread is the best for this error, I'm sure it's ok to suggest here to do and run some script from the admin side which ensures that every single file which must exist does actually exist, and can be publically accessed (when it should be). My unix days were like a century ago, but I'm sure among the admins and devs there are some people capable of doing this if you think it's worth it. Think of it as part of that 2%.
I finished scanning through all of the images and didn't find any other images that gave any kind of HTTP error.
KyteM said:
This is a tiny issue but email notifications forget to add the domain name to links, so for example a mail about getting a user record will point to http://user_feedbacks/?search[user_id]=186589
I assume it's because it simply mirrors the dmail, which has the domain name implicit.
That must have been an error introduced within the last 12 days, since I received a record on 5 Feb that is linked correctly. Will report an issue on GitHub.
Created issue #2887 on GitHub.
Updated
Normally, when uploading from Twitter, you can upload the image by simply copy&pasting the Tweet URL.
But sometimes this doesn't work. This Tweet is an example:
https://twitter.com/k0koro_091/status/834046213674577922
When copy&pasting this URL into the source field, you'd get an error message.
Provence said:
Normally, when uploading from Twitter, you can upload the image by simply copy&pasting the Tweet URL.
But sometimes this doesn't work. This Tweet is an example:
https://twitter.com/k0koro_091/status/834046213674577922
When copy&pasting this URL into the source field, you'd get an error message.
Danbooru tries to use the Twitter API to look up posts, but sometimes these lookups fail. In those cases, it's necessary to use the image link.
