Posts

Been meaning to get around to doing this. This is just a list of gotchas on the API side of things. These are not bugs, but rather differences in how data are expressed.
 
ALL
 
image objects
 

 
GET /api/v1/json/images/:image_id
 

 
GET /api/v1/json/search
 

 
GET /api/v1/json/tags/:tag-slug
 

 
POST /api/v1/json/search/reverse
 
ex: https://philomena.derpibooru.org/api/v1/json/search/reverse?url=https%3A%2F%2Fderpicdn.net%2Fimg%2Fview%2F2019%2F12%2F16%2F2221988.jpg&image[distance]=0.5
 

 
I’ll update this as more things come out

Clicking on a user reply pops up “comment failed to load” above the comment

Status: FIXED  
Scope: Moderation only.  
Summary: On tag displays, the Aliases are not links to the edit window for the tag.
 
Example: On artist:ciaran there is an alias of “artist:ciaranbenson”.
 
Expected behavior: Clicking the alias should open the edit page for that tag.
 
Instead: The aliased tag is not a link.

Status: FIXED.  
Scope: Moderation only - maybe a permissions problem?  
Summary: Moderation notes are not visible on tags.
 
Example: On artist:ciaran there is a Mod Note of “Testing moderation notes. This is the moderation notes.”. It does not display on the Philomena view
 
NOTE: Philomena does edit all of the DESCRIPTION fields correctly, and the actual content of the fields show in the EDIT page. It just doesn’t display the content of the Moderation note. Permission problem maybe?

Status: FIXED  
Scope: Feature can not be accessed through normal means  
Summary: The (more info) link on Do-Not-Post listings on artist tags directs to the artist tag instead of the Do Not Post entry.
 
Example: Oh artist:phenya the DNP (more info) links to https://philomena.derpibooru.org/tags/artist-colon-phenya##
 
Instead: (more info) should link to https://philomena.derpibooru.org/dnp/868
 
WORKAROUND: Go to the DNP tool and search for the artist name.

Status: FREAKING FIXED ON PHILOMENA!  
Scope: ARTIFACT IN BOORUONRAILS - Retest on Philomena to see how it handles this problem.  
Summary: The tag count on tags can be incorrect. For some tags rebuilding the index does not help.
 
Use Case: Tags have a number associated with them that shows the number of images with that tag.
 
Expected Behavior: When aliasing artist tags (or any tag) it is desirable that when the aliasing is done the artist tag reflects all of the images on the site with that artist tag.
 
Instead: Sometimes when aliasing tags the resulting tag has an incorrect number - it does not accurately show the number of images with that have that tag.
 
Example: I see this mostly when aliasing artist tags. I aliased artist:nsfwphenya -> artist:phenya-arts -> artist:phenyanyanya -> artist:phenya and the resulting artist tag had a count of (0) images. The count has incremented as new images have been added, but the actual count should be 289 and is only 8 (as of this moment). Re-indexing the tag has not corrected the count on the tag.
 
NOTE: This artist tag took very long to alias on BooruOnRails - several hours or maybe even a day. It is possible there is something wrong in how this tag has been aliased previously, or there may be a duplicate key or something - but nothing is showing up in SIDEKIQ as failures related to this aliasing. Also, on BooruOnRails the alias jobs for this tag take hours, moving only a handful of tags every few minutes. Normally an aliasing job running for more than 5 or 10 minutes is very unusual, so something weird is going on with this tag or it’s images. It will be interesting to see what the retest on Philomena does.

Images with no source link still have the source history button.  
Example >>2220627

Status: FIXED  
Scope: Moderation Only issue  
Summary: Claiming a report opens the report.
 
Use Case: We often have to claim several reports at one time, especially when one moderator is claiming artist takedowns or spam reports or multiple reports of a single comment or image. On BooruOnRails marking a range of reports “In Progress” all happens in one screen and can be done very quickly.
 
Expected behavior: Claiming a report on the report queue screen adds it to that moderator’s “In Progress” queue and the user is returned to the report queue screen.
 
Instead: Claiming a report opens the report itself so you have to go back to the report queue and reload it to see the change and to claim another report.

Status: FREAKING FIXED ON PHILOMENA!.  
Scope: Cosmetic issue in how strike is parsed in posts and comments.  
Summary: Hyphens when used to create arrows (ex: -> as happens in the aliasing threads) results in strike if there is another hyphen later in the string from the attempted arrow to the second hyphen.
 
Use Case: In the artist aliasing thread the boilerplate for requesting aliases is X -> Y. We could change, but this has been the standard for long enough that it is undesirable to change.
 
Example raw text:  

Expected result (from Derpi On Rails):  

Instead Philomena renders it as:  

 
This is cosmetic, and doesn’t prevent any work on aliasing, but using the X -> Y format is the standard for the thread so it would be preferable to not change.

data-theme="default" at the body tag even if the theme is not “Default”.

@catlion3  
Es exactamente derpibooru; es un cambio de como funcciona bajo el capote, pero para usuarios todo deberia seguir igual… pero mas rapido.
 
Y no hay ningun plan para que derpibooru cierre mientras siga existiendo el internet.

@byte[]  
Spanish:  
Tengo una duda, es como derpiburu?, Se podrá usar igualmente para la carga y descarga de archivos jpg,svg, Photoshop, etc etc?  
Y una más, se acabará derpiburu?

-Missing “I’m feeling poni” button
 
-Names with quotation marks can’t be correctly linked in comments, the link appears as raw text
 
-Derpibooru’s images can’t be hidden with ||spoiler /spoiler ||, it works normally for images from other sources

@Luna  
Eh, makes sense to me, the default usually is ok. Plus, you don’t usually want to change the style of every single autofill on the entire site.
 
That said, I just realized the code I posted also changes the autofill of the username and password boxes at sign in, the tags search box and probably lots of other boxes, too. If you’re changing the style, you most likely should use something more specific than input, textarea and select…

@Yoshimon1  
it baffles me that autoprefixer fails to do that automatically…

@byte[]  
You can add this to the CSS
 
@input:-webkit-autofill,  
input:-webkit-autofill:hover,  
input:-webkit-autofill:focus,  
textarea:-webkit-autofill,  
textarea:-webkit-autofill:hover,  
textarea:-webkit-autofill:focus,  
select:-webkit-autofill,  
select:-webkit-autofill:hover,  
select:-webkit-autofill:focus {  
-webkit-text-fill-color: #ffffff;  
-webkit-box-shadow: 0 0 0px 1000px #62a7d9 inset;  
border: none;  
}@
 
to explicitly overwrite the autofill style and, in this case, make it look exactly like the Default header input. (Obviously adjust colors for other themes.)
 
I just adapted it from https://css-tricks.com/snippets/css/change-autocomplete-styles-webkit-browsers/, no idea if there’s a better solution.

dunno, if anybody asked, but I miss informative page titles on Philomena

@byte[]  
huh… but it’s fixed on the original Derpibooru just not the new Philomena one  
Oh well… must be different code that makes it harder

@Rainboom Dash  
I have no idea how to fix this

when Chrome gives the dropdown of previously typed things in the search bar, it turns it a …
 
you know what, I’ll just link some images  

 

@Algebroot  
fixed

“Most Commented-on Images” stops searching by “most commented” when you type anything into the search bar.

@T12  
fixed

Result numbering at the bottom of search pages is off. The first page says it shows results 1-50 of X correctly, but the second says it’s showing 49-100 instead of 51-100. There are 50 images on the second page, and no images repeated from page 1. Similarly, page 3 says 99-150, and so on.

@Stellar Dust  

 
@DBot  

fixed