Observation about CMS search and filtering

[budparr]

The nature of this post makes me think it belongs here rather than in the forums.

I'm importing data. The import process is quite smooth, which is nice, but I'm seeing odd behavior with searching/filtering in the CMS. Some of this is expected based on what you guys have told me here in the forums, and none of these are complaints, just thought worth bringing up for discussion.

I hope at some point to contribute instead of these messages, but not quite there yet, but if someone wants to point me in the right direction on any of these I could try to work up a pull request.

Link to a Gist with an example JSON file. The "person" content section has 630 entries and is the subject of my observations.

General CMS 1) There is a search function on the upper left of the CMS and a filter above each content type. These two overlap a bit in their functionality (at least ultimately) and seem confusing.

Content Area 2) The filter function doesn't recognize non standard characters, so Bolano returns no results for "Bolaño." (the CMS search does return results though). Is using a definition table or adding slugs to the search criteria a possibility?

3a) So you guys warned me about the 50 item limitation filtering content, but I didn't realize how bad this would be in effect. The problem lies in the fact that filtering only filters through the 50 results so one needs to repeatedly click through page after page until their results show up.

So I understand that I can return the full list on my front-end (which I often do with static sites, using listjs for filtering) and I realize that this sort of thing is somehow outside of the functionality of Firebase, but do you think there's some better way to accomplish this more smoothly? I'd think most anyone using Webhook would have more than 50 items.

3b) Minor thing: When you load the page and click the "Load more results" button, you're taken again back to the top of the page each time, which is only a minor annoyance to me, but probably a point of confusion for a non-technical person.

4) If you load the example JSON file and use the CMS search function, try searching for "Sebald" - it doesn't show up, oddly, since other person records come up. Not a big deal, but leads me to wonder why.

No rush of course on any of these, like I said, I just figured it would be helpful to bring things up. And maybe this sort of thing belong on i

Bud

[gpbmike]

Good timing. I am at this very moment implementing Firebase's new orderBy functionality.

1. The Filter input on the content type list is changing into a search box that will return only results for that content type.
2. Filter will use Elastic search which should do a better job with non-standard characters.
3. While the page will still show only 50 items at a time, the ability to order all items by any field and also use the search box on the content type should help immensely. 3b. @snide literally pointed out the same thing to me not 5 minutes ago. Fixing it now. :)
4. I'll try out your data with the new code.

If you want to see for yourself I'm using the branch reorg: https://github.com/webhook/webhook-cms/tree/reorg

[snide]

We all laughed when you submitted this. We were testing it just as you sent it :)

Nice to see confirmation that it was worthwhile.

[budparr]

Oh, cool! on #3 - you warned me that sorting wouldn't work, which leads me to think that I should probably use the firebase push method to generate my IDs - that still true, right?

[gpbmike]

By default the items will be ordered by _sort_create_date descending. In its absence Firebase will use the default order which is just the IDs. So with that in mind, it wouldn't be a bad idea to use the push method to generate IDs.

[budparr]

I've been creating that field (and it does sort on date), but seems like the right thing to do anyway.

[gpbmike]

These changes are live now.