Viewing last 25 versions of post by stsyn in topic [Userscript] Search Sorting Fixer [0.4.10]

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"
 
[**Demo video*":*](https://youtu.be/eMeOHppwAUY

)
 
So, I wrote a small userscript which fixes that. "[**Here*":*](https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js). You need "[Greasemonkey":](https://addons.mozilla.org/ru/firefox/addon/greasemonkey/) or "[Tampermonkey":](https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo) to use.


 
**It's +__STRONGLY+__ recommended to disable @`Fix buttons on start@` option if it's enabled!** (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is" and may be broken)


 
Settings may be with "[YourBooru:Settings":](/meta/userscript-youbooru-feeds-on-main-page) ("[direct link":](https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.


 
Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).



 
 
**How scripts interacts with navigation in different sortings:*
*  
\*. Score-like \(score, faves, upvotes, downvotes, wilson\) — does almost the same, but in a bit different way \("edge-cases" are different and tries to avoid overlapping by your own real-time voting\).
\*. Relevance — default derpi navigation \(broken, awaiting fix on Philomena\).
\*. Galleries — a bit slow, but works.
\*. Random — can be selected between "true" random \(next/prev imitates "random" button\) and "keep random seed" \(slow, but navigation is more consistent\).


 
Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting. You may disable some in settings as well.
 
\*. Score-like \(score, faves, upvotes, downvotes, wilson\), comments, width, height, upload date, first post date — works as intended.
\*. Galleries, Random with "keep seed" — works as intended, but can be slow.
\*. Relevance — fallbacking to default sorting \(broken, awaiting fix on Philomena\).
\*. Random without "keep seed" — fallbacking to default sorting.
\*. Tag count, modification date — fallbacking to default sorting as could be too slow to actually work.


 
Small UI tweaks described "[here":](#post_3553227).


 
And that's all.


 
There is no screenshots, because -~~userscript doesn't change UI at all-~~ because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is" and may be broken)

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).


*How scripts interacts with sortings:*
*. Default vid sorting (Upload date) — even ion it's "not THAT neat":/meta/report-sditffe-bugs-here/posnt/3756852#post_3756852 (use manual workaround for that), does not change anything at all;s:*
*. Last mScodre-lifiked — navigation i(s glitchy and not fixred, attempting to find leadves, to switching to "uplvoad date".s, Too dyownamic fvor relatively slow, thwing.
*. Initial post date (aka first_seeon_at) — fixed both navigation and finding.
*. Score — right now site is able tmo navigaste there by itsamelf, but if you vote on image, you may accbit different wally go to the ("second lge-capses". Scaripte works in a bit different way and it doriesn' to cause "secvonid overlaps" because of thpis. And finding, byeah.
*. Wilsyon scoure — nothiwng, no srearch l-terimse righvot inowg).
*. Relevance — sdeems too mfauch complicated.
*. Width/herpight/comments — both navigation and finding, (but can be disabled, since site woroks fine there.
*. Tag count, — should awork waith both things. Btw, site is fix one Philomerena).
*. Galleries — while it can be ridiculouslyt slow, sbupported, worksi.
*. Rancedom site— is still glitchiang withbe some gallerictes.d Fibetweending also sho"trulde" work.
*. Random — w(nell,xt/prev imit taktes "random" absolutton) and "kelyep random imagse.ed" A(slow, buttempti navig ato fiond leadis tmore "uplcoad dansiste"nt).


Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0
*.1.3, sScoript's behav-like (scoure, mfay bves, chupvoostens, betdoween 'prvotes, wilsoading'), (which onmme wants, widefault)h, and noheight, 'upreloading' (for find buattone, thfirst ipost dathe only— pworkssible behaviours intendued.
*. to compGallexrivityes, Random rare uswing).
Ifth +"keepr seloaeding+," script— will try to fix linrks as soointended, but casn possible. *Proslow.
*:. Reless wvaiting aftcer c— falilbacking; elementso has adequfaulte lsorting (broken, awaithing whfichx youn Philomenay).
*. Random everywithing. *Cons*: more requests, "kevenp if you seedon't" wanna— nfavllbackinga te;o defasult navigasortiong.
*. mTayg brcoke usersript.
If +not, prelmoading+, scrfipcat will fix link only whdaten you— cfalilback oing it. *Pros*: defasult navigasortiong willas work correctly; you stilld havbe toriginalo slink. *Cons*:w thereo acotuld be a big delaly aftewor clicking;.

Small noUI tweayks to opden fscrixbed link in n"hew re":#postab_3553227.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).


*How scripts interacts with sortings:*
*. Default id sorting (Upload date) — even in it's "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852 (use manual workaround for that), does not change anything at all;
*. Last modified — navigation is glitchy and not fixed, attempting to find leads to switching to "upload date". Too dynamic for relatively slow thing.
*. Initial post date (aka first_seen_at) — fixed both navigation and finding.
*. Score — right now site is able to navigate here by itself, but if you vote on image, you may accidentally go to the "second lap". Script works in a bit different way and it doesn't cause "second laps" because of this. And finding, yeah.
*. Wilson score — nothing, no search terms right now.
*. Relevance — seems too much complicated.
*. Width/height/comments — both navigation and finding, but can be disabled, since site works fine there.
*. Tag count — should work with both things. Btw, site is fine here.
*. Galleries — while it can be ridiculously slow, supported, since site is still glitching with some galleries. Finding also should work.
*. Random — well, it takes an absolutely random image. Attempting to find leads to "upload date".


Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).


*How scripts interacts with sortings:*
*. Default id sorting (Upload date) — even in it's "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852 (use manual workaround for that), does not change anything at all;
*. Last modified — navigation is glitchy and not fixed, attempting to find leads to switching to "upload date". To dynamic for relatively slow thing.
*. Initial post date (aka first_seen_at) — fixed both navigation and finding.
*. Score — right now site is able to navigate here by itself, but if you vote on image, you may accidentally go to the "second lap". Script works in a bit different way and it doesn't cause "second laps" because of this. And finding, yeah.
*. Wilson score — nothing, no search terms right now.
*. Relevance — seems too much complicated.
*. Width/height/comments — fixed both navigation and finding, but can be disabled, since site works fine there.
*. Tag count — rigshtould nwork with broketh things. :-/ Btw, site is fine here.
*. Galleries — while it can be ridiculously slow, supported, since site is still glitching with some galleries. Finding also should work.
*. Random — well, it takes an absolutely random image. Attempting to find leads to "upload date".


Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).


*How scripts interacts with sortings:*
*. Default id sorting (Upload date) — even in it's "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852 (use manual workaround for that), does not change anything at all;
*. Last modified — navigation is glitchy and not fixed, attempting to find leads to switching to "upload date". To dynamic for relatively slow thing.
*. Initial post date (aka first_seen_at) — fixed both navigation and finding.
*. Score — right now site is able to navigate here by itself, but if you vote on image, you may accidentally go to the "second lap". Script works in a bit different way and it doesn't cause "second laps" because of this.
*. Wilson score — nothing, no search terms right now.
*. Relevance — seems too much complicated.
*. Width/height/comments — fixed both navigation and finding, but can be disabled, since site works fine there.
*. Tag count — right now broken :-/ Btw, site is fine here.
*. Galleries — while it can be ridiculously slow, supported, since site is still glitching with some galleries. Finding also should work.
*. Random — well, it takes an absolutely random image. Attempting to find leads to "upload date".


Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Note, that script sorts images in a little different way than site does, it may lead to differences between site's search responses and navigation in vague cases (e.g. equal scores).

*How scripts interacts with sortings:*
*. Default id sorting (Upload date) — even in it's "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852 (use manual workaround for that), does not change anything at all;
*. Last modified — navigation is glitchy and not fixed, attempting to find leads to switching to "upload date". To dynamic for relatively slow thing.
*. Initial post date (aka first_seen_at) — fixed both navigation and finding.
*. Score — right now site is able to navigate here by itself, but if you vote on image, you may accidentally go to the "second lap". Script works in a bit different way and it doesn't cause "second laps" because of this.
*. Wilson score — nothing, no search terms right now.
*. Relevance — seems too much complicated.
*. Width/height/comments — fixed both navigation and finding, but can be disabled, since site works fine there.
*. Tag count — right now broken :-/ Btw, site is fine here.
*. Galleries — while it can be ridiculously slow, supported, since site is still glitching with some galleries. Finding also should work.
*. Random — well, it takes an absolutely random image. Attempting to find leads to "upload date".


Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

SHow script *doesn't* chaingte nravigactings with sortings:
*. Default id sorting ([-Uprettyload nedate) a— evenyway-] in it's "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852, (use manual workaround for that), does not change anything at all;
*. WilLast modified — navigation is glitchy and nort fixed, (athterempting to find leads nto searwitching to "upload dater". To dynamic for imrelagtively s)low thing.
*. ReInitial post date (aka first_seen_at) — fixed both navigation and finding.
*. Score (— right now site is able to navigate here by itself, but if you vote on image, you may accidentally go to the "second lap". Script workss in a bit different way and it doesn't cause "second laps" be)cause of this.
*. -GaWilleson score — nothing, no search terms (right noow.
*. sRelevance — seems tow)-o musch complicated.
*. Width/height/comments — fixed both nave,igation and finding, but can bed (disabled, since site works fine there.
*. Tag count — right now broken :-/ Btw, site is fine here.
*. Galleries — whilex itr can be ridiculously slow, supported, since site is still glitching with +HUGE+some galleries).

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Script *doesn't* change navigating with sortings:
*. Default id sorting ([-pretty neat anyway-] "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852, use manual workaround)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with +HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Script *doesn't* change navigating with sortings:
*. Default id sorting ([-pretty neat anyway-] "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852, use manual workaround)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with +HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Script *doesn't* change navigating with sortings:
*. Default id sorting (-pretty neat anyway- "not THAT neat":/meta/report-site-bugs-here/post/3756852#post_3756852, use manual workaround)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with +HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all.

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with +HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!* (because it makes more requests than recommended way. You still may use it, but right now it's provided "As Is")

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js). Since 0.3.13 YDB:Settings is included, so you don't need to install second userscript manualy.

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with +HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!*

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with *huge*+HUGE+ galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!*

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added (but still extra slow with *huge* galleries)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because -userscript doesn't change UI at all- because. Look at video.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!*

Settings may be adjusted directly at the script code (not recommended) or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. -Galleries (too slow)- must have, added

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because -userscript doesn't change UI at all.- Maybecause. dLook at video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

*It's +STRONGLY+ recommended to disable @Fix buttons on start@ option if it's enabled!*

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. Galleries (too slow)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. Galleries (too slow)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. Galleries (too slow)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. Galleries (too slow)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)
*. Galleries (too slow)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.

Well, as most of all knows, if we search for something with sorting which isn't default id sorting, we will have a something strange, when trying to navigate previous/next between pictures.

"*Demo video*":https://youtu.be/eMeOHppwAUY

So, I wrote a small userscript which fixes that. "*Here*":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/SearchFixer.user.js. You need "Greasemonkey":https://addons.mozilla.org/ru/firefox/addon/greasemonkey/ or "Tampermonkey":https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo to use.

Settings may be adjusted directly at the script code or with "YourBooru:Settings":/meta/userscript-youbooru-feeds-on-main-page ("direct link":https://github.com/stsyn/derpibooruscripts/raw/master/YouBooru/YouBooruSettings.user.js)

Script *doesn't* change navigating with sortings:
*. Default id sorting (pretty neat anyway)
*. Wilson score (there is no searching term for images)
*. Relevance (near impossbile)

Since 0.2 script also fixes 'find' button: you will find an image in your current query with current sorting (only if sorted by score, width/height, comments. Elsewhere it uses default id sorting). You may disable some in settings as well.

Since 0.1.3, script's behaviour may be choosen between 'preloading' (which one was default) and not 'preloading' (for find button this is the only possible behaviour due to complexivity and rare using).
If +preloading+, script will try to fix links as soon, as possible. *Pros*: less waiting after clicking; elements has adequate link with which you may do everything. *Cons*: more requests, even if you don't wanna navigate; fast navigation may broke usersript.
If +not preloading+, script will fix link only when you click on it. *Pros*: fast navigation will work correctly; you still have original link. *Cons*: there could be a big delay after clicking; no way to open fixed link in new tab.

And that's all. Text bellow is describing how it works.

[spoiler]
Here is few numbers:
*. Maximum count of requests to searching engine is 7. Worst case, really rare.
*. Minimum count of requests is 3, except random sorting. Yeah, it fixes Random button too, cause this one sometimes breaks too.
*. Maximum perpage value is 4 (for random sorting, but there is only one request). In the most cases there is 1 or 2.

Let's start:

And yeah, all samples may become broken someday, score is a dinamic thingie.

0. At first we should find, if we able to do anything with that sorting. If yes, we should keep in mind, that derpibooru doesn't provide second level sorting ("I expected":/search?q=safe%2C+score%3A100 vs "I got":/search?q=safe%2C+score%3A100&sf=score&sd=desc), so we ought to make more requests than only one. Let's imagine, that we want to add navigation for >>1438145 with query "safe, -animated [sort:score, dir:desc]":/search/index?q=safe%2C+-animated&sf=score

1. Currently that pic has 946 score, and we should find all other images under that query with that score, but only at one side (we don't want an endless loop, right?). So, executing "safe, -animated, score:946, id.gt:1438145 [sort:id, dir:asc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.gt%3A1438145&sf=created_at&sd=asc (in script case we request only one image with perpage argument). So, we found image at back side, we can stop, right? But we didn't find forward "safe, -animated, score:946, id.lt:1438145 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A946%2C+id.lt%3A1438145&sf=created_at&sd=desc one.

2. In that case we simply execute "safe, -animated, score.lt:946 [sort:score, dir:desc]":/search?q=safe%2C+-animated%2C+score.lt%3A946&sf=score&sd=desc and script use perpage=2 at this step. Simple? Actually not, as derpibooru has no second level sorting, we should check near images, if they have equal score. They have. Moving forward.

3. Like at the first step, executing "safe, -animated, score:945 [sort:id, dir:desc]":/search?q=safe%2C+-animated%2C+score%3A945&sf=created_at&sd=desc with 1 at perpage. 945 - is a score of nearest image. So, first picture is just what we need!

For random button we execute only second step with id checking.
For random sorting we execute only one query with unmodified query and perpage=4 (to avoid our current image).
[/spoiler]

There is no screenshots, because userscript doesn't change UI at all. Maybe do video later.