Posts

@Rene_Z  

 
While we’re at it, what about .gif representations? Will this hack still work?
 
Also, another question. The old API returns tags with their respective namespaces, the new API returns just tags and more tag data has to be fetched per-tag. That makes it so that an image with, say, 50 tags will now take 51 requests should I want every tag to have a namespace and/or color.
 
Should I just fetch those as they come, and simply cache for reuse, or is there some other method for handling it?

The new API no longer returns the mp4 representation for images uploaded as WEBM.
 
Example: Old API, New API
 
For images uploaded as GIF, the new API still returns both the webm and mp4 representation as before (Example).
 
Is this intended behaviour? WEBM still isn’t as widely supported as MP4, so I’m relying on the MP4 representation (in my case sending the image to Telegram, which supports sending MP4 videos but not sending WEBM videos). Of course I could just change the file extension in the URL, but that would be quite hacky and I’d have to check if the MP4 actually exists each time.
 
EDIT 2: I noticed a second issue. The API now always returns the mp4 and webm fields for GIFs, even if the video versions don’t actually exist on the server (for old uploads where no video version was generated). The URLs just return 404. This was not the case before, it would just not include the video representations in the response. However, it seems that even the old API now returns those non-existant representations.
 
Example: Old API, New API
 
EDIT: And a minor issue with the API documentation, the format field of an image response can also return jpeg (instead of jpg), depending on the original file extension of the image. The behaviour is the same as with the old API, it’s just missing from the documentation.

@byte[]  
Is there no UI remaining that could be re-used to more explicitly form the search string for you?

@byte[]  

 
Yeah, that’s the one. Noted for future reference too, thanks.
 

 
Appreciate it!

@Barhandar  
It’s not that I wouldn’t revert it in some cases, it’s just that in this particular case, I have nothing to revert it to.

@Wellwater  
You were never able to search for topics, they’re not indexed.
 
What you are probably thinking of is a query for the topic title  
subject:philomena open beta  
Or, what the code used to do if you selected “Topic Openers Only”:  
subject:philomena open beta,topic_position:0
 
(yeah, I know that’s terrible UX)
 
Author thing fixed now. Sorry about that

@Barhandar  
It’s less expressive because it is (as far as I can tell) no longer possible to search for threads (only posts) and it’s no longer possible to specify a forum to search in.
 
For that matter, while the documentation below the search results says you can use author to search by post author, it doesn’t actually work. So there isn’t even any way to search for posts by a given user.
 
(That’s a bug, of course, not a design flaw, but still.)

@Jarkes  
That’s incomprehensible to any software developer.
 
@Wellwater  
Clunkier, yes, less expressive, no. It’s basically nerd option, just like command line vs GUI (which it effectively is): extremely more powerful if you know how to use it, but trash for the averaged person who just want predetermined fields to put what they want into and get results.

@Joey
 
Or, you know, just go back to how forum searching worked before.

@Joey  
@Boxless  

 
So it just happened again.

@byte[]  
What are your thoughts on having a seperate page/section for forum/comment searching? That page is mostly for imeage searching, and spends a lot of time talking about attributes that communications don’t have.
 
There is that little guide at the bottom of the forum search, but most people probably don’t think to look there

@Wellwater
 
Yeah, that.

@byte[]  
Yes, but that wasn’t previously necessary for searching the forums, and for forum search it’s a lot clunkier and less expressive than the previous search form. I suspect that’s what Jarkes meant.

@Wellwater  
I’m talking about this syntax. It’s the same parser with the same rules.

@Background Pony #F414  
Huh? The syntax (and general interface) for searching for forum posts/threads? You are talking about that syntax, right?
 
Of course, technically that might actually be right, but if so, there was a lot of syntax I was able to push off on the much more sophisticated search form with no loss of expressiveness, so I’m not sure that counts for much.

@Background Pony #F414  
Dammit.

@Jarkes  
the search syntax hasn’t changed

…I’m just going to say it. I hate how the search syntax is so much more complicated now, especially when it comes to searching posts.

@Ajedi32  
I actually mostly wrote it in 2 months (see my commit history) but yes

Wait, you rewrote the entire backend in a completely different language, with a completely different development framework? In 6 months? With pretty much zero impact to the UI? That’s seriously impressive.

@Parcly Taxel  
Merged

@byte[] I made a pull request.

@Parcly Taxel  
Couldn’t you?

@byte[] Could you set it to false so as to suppress the field?

@Parcly Taxel  
Because I didn’t set enforce_utf8 to false