|#401 by beliar|
2020-05-30 at 18:57
|That's not really an error as such. It's just dead links, so it's better to post such things in the relevant thread the next time. For traits we have: t3314.|
Edit: FixedLast modified on 2020-05-30 at 19:03
|#402 by naiohoras|
2020-05-31 at 10:32
|whenever I tagged an already existing tag, the screen always scroll back to the top of the page. I think it's better to either highlight the tag or just make the screen stays still.|
|#403 by rampaa|
2020-06-06 at 23:57
|Either the edit summary (sometimes) fails to show the differences between revisions or the editing system allows revisions that change nothing: c61989.6|
|#404 by naiohoras|
2020-06-07 at 00:49
|although it isn't shown on the front page, there's a deleted tag Tongue-in-cheek still showing up when you visit the modify tag page link.Last modified on 2020-06-07 at 00:50|
|#405 by naiohoras|
2020-06-07 at 03:11
|I don't know if this is an error but in the new trait edit form, when the something-token expired i.e. editing too long without submitting, the unsubmitted traits will be lost and I need to re-add all the traits again. in the old form, the traits are usually still there even when I reload the pageLast modified on 2020-06-07 at 03:12|
|#406 by yorhel|
2020-06-07 at 09:25
|@403: Yeah, the no-change detection was broken so it allowed empty revisions. Fixed.|
@404 (appropriate post number): That's intentional, kind of. It used to not be possible to have any votes on deleted tags at all, but that's been changed a while ago so we can keep old votes around for a while, to allow users to browse, edit and migrate off to whatever new tag should replace the old one - similar to "not applicable" tags. Deleted tags should be marked properly, though, I'll see if I can fix that.
@405: That's browser behavior that I don't have much influence on. I have been considering adding a big warning when the token is about to expire, or to have the token refresh itself, etc. But all of that is fairly tricky, considering that the token also expires when you log out and in again. I wonder if I should just get rid of that token altogether, it's not strictly necessary nowadays.
EDIT: Either way, you really don't want to keep edit pages open for so long, there's also the risk that you'll be reverting an edit someone else made while you kept the page open and there's the risk that I break submission of old forms after pushing some changes to the server.Last modified on 2020-06-07 at 09:30
|#407 by eacil|
2020-06-07 at 10:10
|Why don't you timestamp the form when it is opened and check it against the newest edit's timestamp when it is submitted to see if a new edit was made in the meantime? Some forums do that to prevent you from being ninja'd and it's pretty useful.|
Keeping a page for too long happened to me more than once because some search asks you to go real deep inside the wayback machine or some obscure Japanese web corner, or just because I write comments way too long...
This feeling when you hit the warning, you didn't save the wall of text and you don't know if it will still be there. *sweat*
Edit: while I am at it: why are you rendering the forum's textarea with JS? It's... weird.Last modified on 2020-06-07 at 10:26
|#408 by yorhel|
2020-06-07 at 12:07
Why don't you timestamp the form when it is opened and check it against the newest edit's timestamp when it is submitted to see if a new edit was made in the meantime?Detecting that should be easy to implement, the problem is: what to do when there indeed has been an edit? Can't really do more than just show a warning, I'm not going to implement functionality to merge two divergent revisions...
Edit: while I am at it: why are you rendering the forum's textarea with JS? It's... weird.Heh, it is. All new forms are rendered with JS because (almost) all forms need some extra interactivity stuff (in the forum case, bbcode preview). It's much less messy to standardize on a common way to implement forms and if they're going to need JS anyway, might as well go all the way.
...but then you get stupid little quirks like the page flickering a bit during rendering. Fuck I hate JS, if only there was a sensible way to implement this stuff.
|#409 by eacil|
2020-06-07 at 20:59
|The warning should be enough to prevent us from overwriting other people's edit. Show the last diff to prevent the user from opening a new tab to check what was changed. I doubt the case where two or more edits will pile up during your session will show its nose, but unless you want to bother by merging diffs, a more verbose warning should do the job for that 0.00001% use case.|
The forum could benefit from that. You append the new comments (not reload the page or the pagination could hide some of them) above the textarea and highlight them.
And just to be clear about the second point: without JS, the textarea doesn't appear.
Well, I also tried to edit my message, forgot I disabled JS and it was empty too.
I know people without JS are rare, most of them are just selectively blocking it and could enable it per domain. That's why I said it was weird as a fallback for a more "plain" textarea without all the shiny bells and whistles of modern and dynamic vndb is not something that should be hard to have. Not that I really care, I was just curious as I thought you made vndb to be workable without JS (not counting the contribution zone).Last modified on 2020-06-07 at 22:58
|#410 by yorhel|
2020-06-08 at 06:13
Not that I really care, I was just curious as I thought you made vndb to be workable without JS (not counting the contribution zone).Forms are the exception here in that they have always required JS, even the old mostly-plain-html forms had JS-based anti-bot protection. Even on the login form. For most other parts of the site you're right.
|#411 by gvbn|
2020-06-09 at 16:29
|My custom CSS broke partially today. The cause seemed to be the > selector (e.g. .elm_dd > a)|
|#412 by yorhel|
2020-06-09 at 18:51
|My bad, should work again.|
(Also, @eacil: classes added)
|#413 by foiegras|
2020-06-11 at 05:48
|Link detection in messages doesn't include the exclamation mark.|
link!! should include them in the 'link'. Or is this a percent-encoding issue in the URL?
|#414 by gvbn|
2020-06-12 at 08:32
|In r66005 the description falls outside of <p class="description"></p> where it should be, making the margins look awful. There's also an empty trailing <p></p>. Probably caused by the quote?Last modified on 2020-06-12 at 09:24|
|#415 by rampaa|
2020-06-13 at 18:26
|♡ is being displayed as ≡, instead of a ♥ both in the messages and in the "Original title" section of VNs (see Hakui no Tenshi wa Osewa-zuki! ~Love Love ♥ Ecchi na Nyuuin Seikatsu~ for example). I think the culprit is the font named Tahoma.Last modified on 2020-06-13 at 18:34|
|#416 by beliar|
2020-06-15 at 16:55
|Not sure if Yorhel saw the post by Gvbn on another thread, but I'm throwing it here too just in case t8242.244. There seems to be a bug with character instances. When one of the instances end up being deleted, the other instance doesn't lose the instance flag and become permanently bound to non-existent character entry.|
For example: Ellis Xillia and Shinki Ixseal. As the latter is deleted, the former is left permabound to it.
|#417 by yorhel|
2020-06-15 at 17:07
|t2520.380 regarding release resolutions:|
A treatment similar to how the engine field is handled might be a better approach than a static list.Has now been implemented.
EDIT: Also, I have yet again not really updated the filters. The release -> resolution filters still work as they used to, but they don't allow you to select resolutions not in the list. It'll work if you edit the URL though.
There seems to be a bug with character instances.I saw, then forgot about it, then remebered it again an hour ago and made a note to fix that. The fix is trivial, but I'll need to do some automated edits to remove those instance relations and that'll need some testing.
EDIT#2: Turns out I had already fixed the code some time ago to prevent this from happening in the future, I just hadn't removed the instance from the old deleted entries. Done now.Last modified on 2020-06-15 at 17:36
|#418 by beliar|
2020-06-15 at 17:41
|Yorhel, have you by chance created a dedicated list of resolutions, like we currently have one for engines link? If there isn't one, I think it would be a good idea to create one. Could be used as a consistency tool to see if someone has added a resolution that is clearly nonsensical and also as a statistical measure.|
|#419 by yorhel|
2020-06-15 at 17:46
|Don't think that'll require a separate list. I'll write a query for that tomorrow, when the query DB has been updated.|
(Honestly, the dedicated engine list isn't really necessary either, the query DB is better suited for such things)
|#420 by beliar|
2020-06-15 at 18:02
|Okay, something got borked. Now when I enter the Screens tab on the Vn edit form, it only displays one screenshot out of however many were added and a message about loading. The Staff tab is even more broken, as it doesn't display any members, even if they were added. :-)|
|#421 by yorhel|
2020-06-15 at 18:07
|Just pretend that didn't happen. It's not like I break completely unrelated site functionality when adding a new feature.|
|#422 by kumiko1|
2020-06-16 at 07:06
|With resolution I feel like when you click on the empty box it should have a drop-down list displaying the most commonly used ones, given how almost all of the time it'll be one of them.|
|#423 by shining17|
2020-06-16 at 13:36
Dunno why this res throws me an error.
|#424 by yorhel|
2020-06-16 at 13:37
|Is that an actual 'x' or a unicode character you copy-pasted?|
(In either case it'd be good to support the latter)
|#425 by shining17|
2020-06-16 at 13:39
|I retyped the x, still causing the same error strangely.|