feat(search): enhance playlist search with type filtering and badge styles

[sreeshanth-soma]

Closes #118

Summary

Adds playlist-type aware search in the sidebar and introduces a visual type indicator for playlist search results.

Changes

Backend

• core/models/playlists_model.php
  • Enhanced playlist search query handling to recognize type aliases and map them to playlist types:
    • basic, b, pl b, playlist basic -> standard
    • advanced, a, pl a, playlist advanced -> advanced
    • live assist, liveassist, live_assist, la, pl la, playlist live assist -> live_assist
  • Type matching is additive to existing name/description search.

Frontend

• public/js/sidebar.js
  • Added playlist type badge rendering in sidebar rows:
    • PL + B for standard/basic
    • PL + A for advanced
    • PL + LA for live assist
  • Added row data-type assignment for playlist results.
  • Added runtime style injection for badges to ensure visual indicators appear consistently across themes/build states.
• public/scss/_sidebar.scss
  • Added badge styles for playlist type indicators (layout, pill styling, and per-type colors).

Behavior

• Searching playlist sidebar with type terms (e.g. basic, advanced, LA) now returns matching playlist types.
• Playlist result rows now show compact type badges as a visual indicator.

Verification

• In sidebar playlist search, query basic, advanced, and la.
• Confirm matching playlists appear for each type term.
• Confirm each result shows visible type badges (PL + B/A/LA) next to playlist name.

I chose subtle color-coded PL/B/A/LA badges to improve visual scanability in the playlist sidebar while keeping explicit text labels for clarity and accessibility.

[sreeshanth-soma]

Updated the sidebar type indicator to ensure proper display across themes, including the default Tanzanite theme.

Removed the redundant "PL" prefix so only a single type marker (B, A, LA) remains.

Also aligned the visuals with existing UI patterns and avoided static icon assets.

Attaching updated screenshot for reference:

[radiorob]

Use dynamic icons from Font Awesome whenever possible https://fontawesome.com/search?q=live&ic=free-collection

[sreeshanth-soma]

Thanks for the suggestion. I’ve updated the playlist badges to use Font Awesome icons and moved the badge styling into _sidebar.scss for consistency.

Standard/Basic → fa-list (green)
Advanced → fa-cogs (blue)
Live Assist → fa-microphone (orange)

Also added the missing search alias for “standard”.

[hinanaya]

Can you tell me what theme you are using to get those icons? When testing, my playlists look like this:

I also want to note that compared to the media items, the icons aren't aligned. It should ideally look consistent:

The shortened search queries aren't good design either. Typing 'a' will now always include every advanced playlist, 'la' will include all live assists (despite being a common article in e.g. french, as well as possibly referring to the city). It makes search far more ambiguous. I'm also not sure why all the search for standard uses the word 'basic' instead? Is that a design change? They're called standard playlists everywhere.

Finally, and most importantly, please rebase from the current code 5.5-develop for each new PR. When you submit multiple PRs that are all based on 5.5-develop rather than stacked, trying to merge them in causes enormous merge conflicts. It ends up looking like this:

Essentially what the problem is that because each PR depends on the 5.5-develop branch directly, when I merge in PR 1, 5.5-develop now includes the code from that PR, and then when I try to merge PR 2 (which touches the same code), I get merge conflicts because it's not expecting PR 1 to be there. It's not feasible for me to do complicated branch surgery for PRs every time. To get around this there's a couple options:

• After I merge in one of the PRs, all other PRs that touch the same code will need to be rebased. I strongly prefer this solution. When making a number of changes to the same code, it's ideal to then submit only a single PR for those if they're all related to minimize rebasing. e.g. all the new filters implemented in the advanced search could all have been a single PR. (However, PRs that are too bulky make them hard to test too, so keep it reasonable. Rebasing afterwards isn't too much work.)
• Or create stacked PRs, where the code from PR 2 is branched from PR 1, the code from PR 3 is branched from PR 2, and so on. This way they can all be merged in sequentially. I personally would prefer the first option however, because if I need to make a change to the code at any point in the PR chain, all PRs relying on this then cause the same merge conflicts.

I hope this can make the process more streamlined in the future. Thank you for your contributions so far 😊

[sreeshanth-soma]

Thank you for the detailed feedback @hinanaya! I have addressed everything in the latest push

• Playlist type icons are now in their own column, aligned consistently with the media tab icons
• Removed the short search aliases (a, b, la), only full type names like standard, advanced, live_assist will trigger type filtering now
• Dropped the basic alias, using standard everywhere as it should be
• Also recompiled all theme CSS, so the icon colors should now show up properly on your end too

Regarding the PR workflow, that makes a lot of sense, and I was actually thinking along those same lines. I will try to group related changes into a single PR going forward, especially things like the search filters which all touch the same code. And whenever a PR gets merged, I will make sure to rebase the remaining ones so things stay clean. If I notice anything that needs adjusting during rebasing I will handle it right there. Appreciate the guidance on this 😁