Dataviews Filter: Showing error when sort-by filter changes to Status

[levinbaria]

What?

Fix a runtime TypeError when sorting DataViews by fields that can produce non-string or missing values. Specifically: prevent "TypeError: a.localeCompare is not a function" by hardening the comparators used for sorting in dataviews field types and the fallback comparator.

Why?

When sorting, some comparators called localCompare directly on values that could be undefined, null, or non-string. Calling localCompare on a non-string throws a TypeError and breaks the UI when users change sort settings (reported when sorting by Status in dataviews). This PR makes the sorting comparators robust so they never call localeCompare on a non-string.

How?

For field types that can reasonably return non-strings or undefined (text, email, url, and the fallback field-type), comparator code now coerces values to strings before calling localeCompare:

• null/undefined -> '' (empty string)
• else -> String(value)

Testing Instructions

1. Go to the Templates --- Appearance->Editor->Templates
2. Change the filter-> "Sort by" option to Status or any other fields.
3. Observe the console: there should be no "TypeError: a.localeCompare is not a function". -- No UI breaks.
4. Confirm sorting behaves sensibly: Ascending vs descending order toggles as expected.

Testing Instructions for Keyboard

Screenshots or screencast

error.mp4

Before	After

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: levinbaria <levinbaria@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Thanks for the PR!

This pull request certainly solves the problem, but I believe it's the developer's responsibility to define the appropriate type and value for each field. Otherwise, it becomes impossible to detect errors in invalid fields.

I think it's best to move forward with #72648.

cc @ramonjd @Mamaduka

[t-hamano]

Closing in favor of #72648