Donmai

Danbooru 2 Issues Topic

Posted under General

This topic has been locked.

Moonspeaker

reiyasona said:

Quick / temp fix: Click on your HTTPS Everywhere symbol while being on the pixiv.net domain and deactivate the "pixiv (partial)" rule (written in green letters).

This may prevent the issue from occurring in posts one uploads or commentary one pastes in after following the above steps. However, I followed the directions, then opened an existing commentary, and the "�" symbols were still generated. I tried logging out and then back in to Danbooru with HTTPS Everywhere now active, and got the same results.

reiyasona

Moonspeaker said:

reiyasona said:

Quick / temp fix: Click on your HTTPS Everywhere symbol while being on the pixiv.net domain and deactivate the "pixiv (partial)" rule (written in green letters).

This may prevent the issue from occurring in posts one uploads or commentary one pastes in after following the above steps. However, I followed the directions, then opened an existing commentary, and the "�" symbols were still generated. I tried logging out and then back in to Danbooru with HTTPS Everywhere now active, and got the same results.

@Moonspeaker

My temp fix (and post) was related to the problem described by @Dbx.

The � issue has already been fixed (issue #2617). The fix will most likely be deployed with Danbooru v2.104.0

Updated

Moonspeaker

reiyasona said:

@Moonspeaker

My temp fix (and post) was related to the problem described by @Dbx.

The � issue has already been fixed (issue #2617). The fix will mostly likely be deployed with Danbooru v2.104.0

Ah, my misunderstanding. I thought Dbx was describing an associated problem/potential root cause of the � issue and simply left out any post-quoting segues. Sorry for the confusion, and I'll look forward to the next Danbooru version deployment, then.

BrokenEagle98

In topic #13023, I tried to swap one alias for another by creating a new bulk update request as such:

unalias robot_arms -> mechanical_arm
unalias robotic_arms -> mechanical_arm
alias robot_arms -> mechanical_arms
alias robotic_arms -> mechanical_arms

which gave me the error, "Antecedent is already taken". However, if I create a new bulk update request with only the remove aliases as such:

unalias robot_arms -> mechanical_arm
unalias robotic_arms -> mechanical_arm

and then edit that request afterwards to add in the create aliases (as shown in the first quote), then it allows me to create the original request I wanted.

It'd be nice to skip step B though and go straight from A -> C, i.e. the update request from the first quote works when creating a new request.

reiyasona

BrokenEagle98 said:

It'd be nice to skip step B though and go straight from A -> C, i.e. the update request from the first quote works when creating a new request.

The question is: Where exactly lies the bug?

Is it A -> C: Not being able to create a single complete BUR with unalias and alias operations applying to the same tag.
Or is it A -> B -> C: Being able to circumvent a possibly much needed regulation by inserting part B into an existing BUR (see forum #117591).

BrokenEagle98

reiyasona said:

The question is: Where exactly lies the bug?

Is it A -> C: Not being able to create a single complete BUR with unalias and alias operations applying to the same tag.
Or is it A -> B -> C: Being able to circumvent a possibly much needed regulation by inserting part B into an existing BUR (see forum #117591).

Same bug that existed for BUR 774. The original creator in topic #12924 originally was only able to create the request with the remove aliases/implications. I went in afterwards and added the "create implications".

Granted it's not a one-for-one example, since it was swapping aliases for implications, but it was the same bug that prevented the original request from including the "create implication" and "remove alias"/"remove implication" in the same request.

The bottom line though, is that the above request went through without any problem.

Edit:

Disregard the above... see forum #117604 for Type-kun's explanation of the problem.

Updated

Moonspeaker

Upon translating some commentary tonight, I was pleasantly surprised to see the addition of optional choices in the commentary dialog box to remove/add the commentary, commentary_request, and/or check_commentary tags. However, upon my attempt to use them, while the dialog box closed, the commentary didn't post, nor did the tags change. I had to un-toggle the selections to get the commentary to post properly (It was still saved in the closed dialog box, at least.) and change the tags manually as usual.

If it helps, I'm currently accessing the site on a Mac running OSX Yosemite using Firefox 47.0.

BrokenEagle98

Confirmed the behavior of the commentary checkboxes as noted by Moonspeaker above...

  • Similar behavior on different browsers (Firefox 47.0 & Chrome 51.0, on Windows 7)
  • The add tag checkboxes work with any and all other add tag checkboxes combinations. Ex:
    • Add commentary & Add commentary_check
    • Add commentary & Add commentary_request
    • Add commentary & Add commentary_check & Add commentary_request
  • The inclusion of any remove tag checkbox causes the behavior Moonspeaker noted to happen. Ex:
    • Add commentary & Remove commentary_request
    • Add commentary & Remove commentary_request & Add commentary_check
    • Remove commentary & Add commentary_check

So it appears as if there is something going on with the remove checkboxes that prevents the changes from going through.

user 460797

It happens again. Not with the same artist, though, but whenever I try to upload something from deviantart with the bookmarklet, the artist that shows up is always ladyfish and this isn't right. For example when I upload a dandonfuga artwork, not dandonfuga appears, but ladyfish. Could this be fixed?

user 166417

Provence said:

It happens again. Not with the same artist, though, but whenever I try to upload something from deviantart with the bookmarklet, the artist that shows up is always ladyfish and this isn't right. For example when I upload a dandonfuga artwork, not dandonfuga appears, but ladyfish. Could this be fixed?

It happens when there is a wrong link, for example a link directly to an image, in the artist URL page.

Same thing happens with Twitter.
If there in an artist URL that links to the :orig or whatever it will mess up the bookmarklet until that link is removed.

That's at least what I have gathered from my experience.

Nitrogen09

Provence said:

It happens again. Not with the same artist, though, but whenever I try to upload something from deviantart with the bookmarklet, the artist that shows up is always ladyfish and this isn't right. For example when I upload a dandonfuga artwork, not dandonfuga appears, but ladyfish. Could this be fixed?

Works normally for me. Maybe you got some other things wrong?

1 125 126 127 128 129 130 131 132 133 315