To be honest, now that the git hash is displayed on the web site I've been leaning towards not versioning stuff anymore.
There are still "releases" as you can see when you click the version number hyperlink, but they are categorized by release date instead of version number.
Then we should probably go by revision number or commit number or maybe even dates just to see that the code is progressing. A hash is a little bit too vague.
Are inactive user's change logs (history) deleted automatically?
By some chance, I was trying to remember where I'd seen a particular image (ended up being post #1718701), turns out I couldn't find it because user #370576 / @user_370576 removed the copy/character tags from it.
Curious, I went to browse their Post Changes history, only to get the following error page:
ActiveRecord::StatementInvalid exception raised PG::QueryCanceled: ERROR: canceling statement due to statement timeout : SELECT "post_versions".* FROM "post_versions" WHERE (true) AND (updater_id = 370576) ORDER BY updated_at desc, id desc LIMIT 20 OFFSET 0 app/views/post_versions/_listing.html.erb:20:in `_app_views_post_versions__listing_html_erb__4066017601970213085_70301151608260' app/views/post_versions/index.html.erb:8:in `_app_views_post_versions_index_html_erb___2990999107213905252_70301151342480' app/controllers/post_versions_controller.rb:7:in `index'
Searches can time out depending on how they're indexed, especially if the last time the person did a post change was a while ago. Therefore, you need to search around the area that they last changed posts.
Note: The b or a modifier before the page number tells the search engine to search above or below that post version. That is, it is not inclusive, so the value needs to be incremented or decremented to include it as seen above. Without the limit addon, the amount of posts returned will default to 20
Searches can time out depending on how they're indexed, especially if the last time the person did a post change was a while ago. Therefore, you need to search around the area that they last changed posts.
Note: The b or a modifier before the page number tells the search engine to search above or below that post version. That is, it is not inclusive, so the value needs to be incremented or decremented to include it as seen above. Without the limit addon, the amount of posts returned will default to 20
Uncategorised searches show all my searches rather than, well, the uncategorised ones. I have a couple blank search categories, and I'm fairly sure the searches within them aren't blank.
New hotkeys: E to edit, shift+D to delete, left arrow / right arrow for prev/next page, shift+R for read all in the forum. See the help.
Changes
issue #2851: Previous usernames are now hidden for deleted accounts (except to admins).
issue #2853: It's no longer required to give a reason when submitting a name change.
The menu items in the subnav bar on /posts now have HTML IDs (useful for custom css / userscripts).
The version number in the footer was removed.
Fixes
The removal of /post/index.xml was reverted.
order:comment_asc now correctly lists posts that were least recently commented on first.
issue #2853: An exploit with name change reasons being visible in the API was fixed.
issue #2849: IP search should be fixed. For real this time. Hopefully.
issue #2850: A bug with sending dmails to users who had email notifications turned on but didn't have a valid email was fixed.
issue #2415: A bug with the random post feature sometimes returning "RecordNotFound" was fixed. /posts/random and order:random should also be noticeably faster.
issue #2846: The broken vote up / vote down mode on /posts was fixed.
issue #2835: Upload count on profiles is tracked more accurately (although I notice existing counts haven't been regenerated so they're still off).
Have done some initial testing, and am getting some weird results with this. I first checked the tag girls_und_panzer with both comment bumping turned on and off, and a lot of the same results were returned.
Is it possible that the search doesn't account for users that never choose to not bump their posts, i.e. they never set the "Do not bump" option...? So when it gets no results back, it instead gives all results back...?
Uncategorised searches show all my searches rather than, well, the uncategorised ones. I have a couple blank search categories, and I'm fairly sure the searches within them aren't blank.
Filed it as issue #2859. It looks like there's no way to search just uncategorized saved searches right now. You have to use search:all, which searches everything.
Have done some initial testing, and am getting some weird results with this. I first checked the tag girls_und_panzer with both comment bumping turned on and off, and a lot of the same results were returned.
After beating my head against a wall for a while I realized it was a simple typo. do_not_bump_post=true returns everything because I misspelled it as do_no_bump_post. Derp.
Always wanted something like this :3 That said, it seems somewhat broken - when switching between pages on score-ordered comments, same posts can appear. Is there no secondary order clause in the query besides score?
Do you have NoScript or some other addon that is blocking Javascript?
No I don't. But mentioning to check for a conflicting addon gave me the idea to see if there was a conflicting setting in Danbooru.
Now I think I had disabled keyboard shortcuts prior to the site update (it's not a setting I look at often). Switching between tag scripts still worked and those were the only shortcuts I used. Today, only the new hotkey "E to Edit" worked (but I only looked at listing shortcuts). Enabling the shortcuts again allowed me to switch between tag scripts and have access to the other keyboard shortcuts including new hotkey. Disabling the keyboard shortcut keys again disabled tag all of the keyboard shortcuts including tag scripts and the new hotkey.
Have tag scripts always been tied to the keyboard shortcut setting?