Report site bugs here

Tags search is still broken. I don’t know if this is the same issue kerinova was talking about since they didn’t elaborate, but instead of returning a list of every tag containing what ever was searched as usual, it only comes back with a single tag or nothing if what was searched isn’t currently a tag on its own.

@Background Pony #7EE8  
Add wildcards.

@byte[]  
What?

@Background Pony #7EE8  
Add *s

@Background Pony #7EE8  
Example

@LightningBolt  
Okay….yeah that works…but it’s still broken. Now it the tag search can’t return tags that contain the searched info if it doesn’t come at the start of the tag.

@byte[]  
I’m trying to think of a more diplomatic way of saying this and I’m at a loss so I must be blunt: that’s a terrible change. Please revert it to normal post haste.

Not sure if related to the tag search update or if it already happened before, but searching for ! (and possibly other special characters?) results in errors.
 
Regular search gets the “Resu- uhh…” page with “Twilight Meditation: Processing error. Please report this query if this error persists.”.  
Tag search gives the PFUDOR ::CLOUDFLARE_ERROR_500S_BOX::.

@Background Pony #7EE8  
This change makes tag search consistent with image search. While it is admittedly less discoverable, we encourage you to read the search syntax documentation, because our search syntax is extensive and covers a lot of niche use cases.
 
 
@Yoshimon1  
This is a parser bug.

@byte[]  
I fear you’re making a mistake. This seems more like a change that benefits the staff far more than the average user. You’ve obfuscated the simple task of searching and are making the unreasonable expectation for every user who just wants to find a half remembered tag to become well acquainted with your advanced tag search mechanics.

@Background Pony #7EE8  
In theory maybe, but in practice, people know about wildcarding half-remembered tags for image searches, and do it all the time there. Also, the majority of tag discovery is by far through the fancy tag editor, which supports autocomplete, and that autocomplete works identically to how the old tag search did.

@byte[]  
You haven’t even provided information anywhere on the tags page about wildcards, how are you expecting the average user to know what to do?
 
Furthermore, you’re vastly overestimating how much reading the average user reads the on-screen text. Even if you were to put an example straight at the top a lot of people’s eyes are just going to pass right over it.
 
What was so wrong with making this new search functionality it’s own page or providing a tick box somewhere instead of overwriting the old system entirely?

@Background Pony #7EE8  
You can get exactly the same results as before by surrounding your search with * on either side.

@Background Pony #7EE8  
I broke your workflow, and you’re upset. I get it.
 
But consider this. The tags search page is incredibly rarely used. By our statistics, it is less than 0.03% of all requests to the site. This was of course not helped by the fact that it was kind of useless for doing anything remotely advanced and was inconsistent with the rest of the site.
 
 
In response to the checkbox: I don’t like adding optional features. Not because they exist, but because most of the time when you have them, they end up leading to an expectation that such an option will never disappear. I don’t want that to be the case here; the old behavior isn’t right.

@LightningBolt  
Once more, that’s more work than I had to do before, one more thing to remember, one more thing to teach an entire website who you’ve pulled the rug out from under for a feature that wasn’t asked for by regular users.
 
I must reiterate, if this was so important to site staff, why wasn’t it just made a separate feature feature instead? We wouldn’t be having this conversation if that’s what had happened instead.

@Background Pony #7EE8  
Please read bytes posts. Also, It would hurt no one to learn an extra character to type. It allows greater specificity too.

@LightningBolt  
I see it, I still vehemently disagree with both your reasoning. I’m still not unconvinced that you’re putting your own needs and convenience over the other users on this site and I think that’s wrong.

@Background Pony #7EE8  
Image searching has worked this way for years and now it is applying to tag searching in the same way.

@LightningBolt  
I am aware of that, I have used that functionality, but when it comes to just trying to find a tag I’m attempting to remember or don’t want to type out in that tiny search bar that was always the real use of the tags page. I can’t imagine I was the only one.
 
You keep insisting this is an improvement, but I haven’t actually heard you properly explain how yet. The immediate feedback when searching images was perfectly useful, but when I’m just looking at tags I don’t see any purpose behind it. I don’t even understand why you find this more useful than just using the image search.

@Background Pony #7EE8  
Previously, if you wanted to find images with wing(s) in them, you would type wing and in addition to tags like spread wings and colored wingtips you would find unrelated tags like glowing and with the new syntax you can type in * wing* and get only results with wing(s) thanks to the space and specific syntax. You can also forgo the first * and have only tags that start with wing or get rid of the last one and get rid of any with a plural.

@LightningBolt  
That feels like a very minor benefit from my perspective, which ties back to what I’ve been saying this whole time, this change isn’t very useful to the average user, while at the same time upending site features that haven’t changed in years, and over-estimating the technical competency and willingness to learn about these changes of most users.
 
I’m trying my best to make you understand that this change is more problematic than you’re giving it credit for while it provides little benefit to most of the people who frequent this site.

@Background Pony #7EE8  
People should be able to learn functionality. Honestly the only issues I see here is documentation and I will not ever see your perspective’s issue. Sorry.

@LightningBolt
 
It’s not just ableness, it’s willingness as well, and I still think you’re giving most people too much credit, not because you have reason to but because it would be convenient for you if they were.
 

 
But wouldn’t that make you unqualified to speak for me then, and most users for that matter?

/search.json randomly returns null instead of tags  
Happens when i try to access API through curl or python-requests. Works fine in Firefox.
 
Using this i have situation where entry 17 of images has null instead of tags  
https://derpibooru.org/search.json?q=:%3C&key=API-KEY&page=3&perpage=50&nocomments=1

@byte[]  
I didn’t even know the tags page was getting a revamp on search. Might be useful, as I was getting kind of annoyed when I couldn’t just wildcard search one half of a tag instead of every result that had those letters in it.  
Any chance you can add a checkbox to make it easier for searches for old users? Like “check/click this box/button to include wildcards to each side”, but it reads something like “old search” next to “search”?  
Just checked the page, and neat. Good to have other search options for the page.
 
@Background Pony #7EE8  
It’s less of a problem than you believe it is. This helps users like me to find tags using half-wildcards. Example:

Maybe if you could provide an example where the new search breaks finding something vs an old search?