I personally find it easier to tell if I have a post favorited just by looking at the list of users who have it favorited.
I've temporarily disabled rating changes from the post menu to see if that makes the random rating changes from unrelated users go away. For now if you want to do that, use the tag script option instead (same thing, just can't do it accidentally).
Sorry for the downtime; update took longer than expected (because Rails is miserably slow--4 SQL queries per objection creation, and incapable of batching inserts...)
Tag history has been replaced with general history. Posts, pools and tags are versioned.
This is a major new block of code, so let me know what breaks.
Artists aren't versioned, because we don't really use that here. (Having an artist db is useful, but there's already at least Danbooru's and http://doujinshi.mugimugi.org, though neither are directly linked from posts, which would be nice...)
Wiki and notes are still versioned as before. Those should be integrated, but we don't use those either, so I didn't bother.
Even though changes to large text fields (pool descriptions) are displayed as diffs, undoing them will always undo to the version before it, like any other field. It doesn't attempt to merge out the diff.
Adds "redo", which does what you'd expect: applies the changes you've selected if they've been undone.
Removes "revert" (revert all changes after a change). This is difficult to implement and I've never found it useful.
post_tag_history still exists and is being updated as a backup but will go away.
You can click on the id (or name), change or user columns to auto-fill-in the search box. This is a little goofy, since the id often almost completely fills the table column, so there's not much space to click on the box without clicking on the id (a link somewhere else). It's also not very obvious. I don't like having multiple search boxes, though.
Searching only works with type:id, user:id or change:id; nothing else will do anything interesting. This could be extended for a change search, but I don't have any plans to implement that right now.
Tag history has been replaced with general history. Posts, pools and tags are versioned.
This is a major new block of code, so let me know what breaks.
Artists aren't versioned, because we don't really use that here. (Having an artist db is useful, but there's already at least Danbooru's and http://doujinshi.mugimugi.org, though neither are directly linked from posts, which would be nice...)
Wiki and notes are still versioned as before. Those should be integrated, but we don't use those either, so I didn't bother.
Even though changes to large text fields (pool descriptions) are displayed as diffs, undoing them will always undo to the version before it, like any other field. It doesn't attempt to merge out the diff.
Adds "redo", which does what you'd expect: applies the changes you've selected if they've been undone.
Removes "revert" (revert all changes after a change). This is difficult to implement and I've never found it useful.
post_tag_history still exists and is being updated as a backup but will go away.
You can click on the id (or name), change or user columns to auto-fill-in the search box. This is a little goofy, since the id often almost completely fills the table column, so there's not much space to click on the box without clicking on the id (a link somewhere else). It's also not very obvious. I don't like having multiple search boxes, though.
Searching only works with type:id, user:id or change:id; nothing else will do anything interesting. This could be extended for a change search, but I don't have any plans to implement that right now.
By the way, I'm planning on setting all pools public again. There's no more need to lock them. If you have a pool and you have a real reason to lock it (can't think of any, myself), just re-lock it.
I thought the whole idea of locking them was to stop the idiots from screwing around? (Which they have done before)
Are you thinking of tracking pooling history then?
Are you thinking of tracking pooling history then?
I agree..this is the internet..there are too many fags out there that would mess up the pools.Radioactive said:
I thought the whole idea of locking them was to stop the idiots from screwing around? (Which they have done before)
Are you thinking of tracking pooling history then?
That's what I just posted about. http://moe.imouto.org/history
Not being rude, but it wasn't in plain English.petopeto said:
That's what I just posted about. http://moe.imouto.org/history
I assume you are talking about the 'Posts, pools and tags are versioned.' ?
Seemed plain enough: anyway, just load the link, or http://moe.imouto.org/history/pool for just pools. Pool changes can be reverted as easily as post changes.
Also, if anyone can think of a good reason to keep the "do not bump" option, speak up. I can't think of any reason to post something and not want people to know about it, and it's breaking the new-comments notice in a way that's a pain to fix, so I'd sooner disable it than waste time working around it.
No problem, it's not like we're on 4chan and we need to sage comments.
I've changed the login sequence. Most people won't care, since they only log in once and just stay logged in. The main goal is to streamline creating accounts.
If you select an action that requires an account, instead of cancelling and redirecting to login, it just pops up a login, where you can create an account immediately (or log in); then it automatically finishes what you did.
In IE6, or any browser with javascript disabled, it'll fall back on the old login form. IE7 looks a little funny (the dialog doesn't center vertically), but otherwise seems to work.
If you select an action that requires an account, instead of cancelling and redirecting to login, it just pops up a login, where you can create an account immediately (or log in); then it automatically finishes what you did.
In IE6, or any browser with javascript disabled, it'll fall back on the old login form. IE7 looks a little funny (the dialog doesn't center vertically), but otherwise seems to work.
I've disabled comment "post as anonymous" and "do not bump".
Is fixing the pop-up notifications on your work list? It can be a bit irritating if you are uploading something in a FF tab and it fails. By the time you go back to the tab, the notice would have disappeared.
Is it possible to keep the notification up until the window/tab is focused? So it'll stay there until you focus, then disappear after the normal length of time. Assuming that wouldn't lag things to hell or anything else negative anyway.
Quickest fix would be to put it back to a permanent notification.
Can we be notified on the Post screen if the Similar search is offline?
Only http://moe.imouto.org/post/similar tells you when the services are offline.
Only http://moe.imouto.org/post/similar tells you when the services are offline.
I can try making notices show separately on post/upload (which is where you should end up if there's an error uploading), but I don't want to make overlay notices stick around forever.
I've also disabled lock rating/notes from the edit menu, since a few people keep locking posts in random-seeming ways. I don't know if those were accidental or if they're just locking posts for no discernable reason. (Some people have randomly locked several dozen posts, which doesn't seem so much like "turning on the edit menu, not knowing what happened and clicking randomly", but we'll see.)
Obviously, disabling things in the edit menu isn't really the best fix, but I'm not sure what else to do. Have a "click here if you can actually read English to turn on stuff that non-English speakers seem to click randomly" option? heh...
Obviously, disabling things in the edit menu isn't really the best fix, but I'm not sure what else to do. Have a "click here if you can actually read English to turn on stuff that non-English speakers seem to click randomly" option? heh...
I moved post/upload notices to a fixed location on the screen, leaving other notices in the overlay. It only does this if it fails in a way that goes back to post/upload (eg. bad URL, download timed out), not if it goes to post/show. The only case that does that that I can think of is "post already exists", so I think that's obvious enough.
I tried to make it so the notice timer doesn't start ticking if the tab/window doesn't have focus, but Opera's blur/focus events seem broken; I couldn't find a reliable way to determine whether the window currently has focus. (It tells JS when a tab receives and loses focus, but not whether it has focus when a page first opens. FF does this correctly and sends focus events when the page loads.)
I tried to make it so the notice timer doesn't start ticking if the tab/window doesn't have focus, but Opera's blur/focus events seem broken; I couldn't find a reliable way to determine whether the window currently has focus. (It tells JS when a tab receives and loses focus, but not whether it has focus when a page first opens. FF does this correctly and sends focus events when the page loads.)
Added a link to pool history to pool/show.
Added comment searching and editing.
Use reverse implications to help search engines. If an alias dog_ears -> inumimi exists, posts tagged inumimi will also have "dog ears" tucked away in the HTML, so Googling for "louise dog ears" can find it more easily.
Added an automatic "hentai" tag to the post/show titlebar and URL for rating:e posts.
Fixed importing into a pool not adding posts in the order they were displayed in the search UI.
Added comment searching and editing.
Use reverse implications to help search engines. If an alias dog_ears -> inumimi exists, posts tagged inumimi will also have "dog ears" tucked away in the HTML, so Googling for "louise dog ears" can find it more easily.
Added an automatic "hentai" tag to the post/show titlebar and URL for rating:e posts.
Fixed importing into a pool not adding posts in the order they were displayed in the search UI.
Had a hard drive die, but we're back. Sorry for the downtime.
Posts with only deleted children shouldn't show up as having children now. You can still see a post's deleted children if you want to (parent:123 deleted:true).
Deleted posts are indicated in history (the post ID is grayed).
If you've had posts deleted, you'll get a notification the next time you open post/upload. This is mostly because we end up with new users who don't realize their posts keep getting deleted, and just keep uploading low-res stuff until someone gets annoyed enough to mail them to tell them to stop. (I'm not sure post/upload is enough, since people probably often just hit back in the browser to get back there to upload the next post, so it won't reload and show the message; but hopefully it's an improvement.)
Deleted posts are indicated in history (the post ID is grayed).
If you've had posts deleted, you'll get a notification the next time you open post/upload. This is mostly because we end up with new users who don't realize their posts keep getting deleted, and just keep uploading low-res stuff until someone gets annoyed enough to mail them to tell them to stop. (I'm not sure post/upload is enough, since people probably often just hit back in the browser to get back there to upload the next post, so it won't reload and show the message; but hopefully it's an improvement.)
Holding shift over a post now shows short post details.
Dope!petopeto said:
Holding shift over a post now shows short post details.
Any thoughts on making that the default hover-over pop-up? Holding shift isn't user-friendly.petopeto said:
Holding shift over a post now shows short post details.
I was thinking that as well!Radioactive said:
Any thoughts on making that the default hover-over pop-up? Holding shift isn't user-friendly.
I did that on my site, petopeto didn't put it as default because he though it would be annoying but I don't really think it is imho.Radioactive said:
Any thoughts on making that the default hover-over pop-up? Holding shift isn't user-friendly.
http://konachan.com/post that's how it works if it's set as default. The code has been hacked to do it on an inverted way so it isn't working properly yet. But I was too lazy to continue fighting against javascript...
I didn't want to make the index too busy, but I can try it. It was originally written as a mouse hover (instead of docking above the thumbnail), which was more annoying...
Shuugo