Natural sort does not work with text fields anymore

Did you enable the module for that? see https://git.drupalcode.org/project/views_natural_sort/-/blob/7.x-2.x/vie.... Also make sure you are on the 7.x-2.x branch as the 7.x-1.x branch does not have that feature.

Sorry I just noticed you put 8.x-2.x-dev.

I'll look into it, but all text fields THAT ARE NOT LONG TEXT should have this feature. Take a look and see if your field qualifies as I can't sort "blobs" or "Long Blobs"

Ok,
So first, I can't believe I don't have a test for this...

second, I've validated that you are correct in that it's missing

There's no indication of field node__field_plain_text_test in my views_natural_sort table.

MySQL [drupal10]> select * from views_natural_sort
    -> ;
+-----+-------------+----------+-------+----------------+
| eid | entity_type | field    | delta | content        |
+-----+-------------+----------+-------+----------------+
|   1 | node        | title    |     0 | 011.0  011.0   |
|   1 | user        | name     |     0 | admin          |
|   1 | user        | timezone |     0 | UTC            |
|   2 | node        | title    |     0 | 011.0  012.0   |
|   3 | node        | title    |     0 | 011.0  0210.0  |
+-----+-------------+----------+-------+----------------+
5 rows in set (0.001 sec)

Probably should find out when this broke because as far as I know, I implemented the D8 version way back when with this feature.

I won't be able to get into it until later this week.

A few more details, I'm testing 8.x-2.x-dev with PHP 8.1 and Drupal 10 in case that makes a difference.

++

I'm going to have to pick this up tomorrow at MidCamp contribution day... but here's what I've found out so far. It appears that my function $this->getViewsBaseTable($field_config) is sending back "node_field_data" for fields. This obviously doesn't match up with what is actually happening over in views_data where a test field looks something like $views_data["node__field_vns_field"] instead.

I'm going to step through that function. It appears I stole it from EntityViewsData::getViewsData()... so if that changed... that could be a lead.

Adding the sort plugin to the tests cause the tests to pass programmatically which is weird as hell to me... It makes me question if my tests are valid.

Looking through the code, It's turning out that custom fields were never implemented... or something happened in the Views API in Drupal core that caused them to quit working. My comments and notes from several years backs suggest the former though. So I'm working through it now, but the way to find all the properties and fields that are a certain type (varchar instead of blob) and adding the sort handler to them is very complicated. I'm working through the function I mentioned before to see how views is mapping properties and fields to the viewsData array to see if I can grab the field part of that out.

I really should ask someone to review that part of the module and talk about what would be a better strategy...

@Greg Boggs,

Give this a MR a shot. I THINK it does what we need it to do and seems to work on the configuration that I'm implemented in the testing modules.

Hi. I am using latest release and php 8.1.
It is only working for me on node titles but not any other fields.

Is there any patch I need to apply?

thanks

There is a MR ready. you can use the patch off of it

Hey all,
I made some changes here... I suspect that none of yall got to actually test this because frankly, I don't know how I "thought" it worked before... The view I was using to test with was corrupted with some missing configuration items. That said I corrected that AFTER I fixed the sql errors I was getting because the handler only could work with base properties like title, stored on the entity table itself. fields using the "field api" tables such as multivalue fields were broken. I've got that working now though.

If this reviews "good" we will call this the first Release Candidate for the stable 2.0 version (I know long time coming)...

Let me know if yall have any issues.

I'll give this a test today. We're currently sorting based on title, which is not ideal. I'll update to the MR and switch it back to using the Teaser title text field and let you know. I have lots of advanced views of all sorts on my site that I'll test it against.

Greg,
I hope I didn't waste too much of your time. I found a bug. I've pushed up the change, so you should be able to take advantage of it.

The option to change sorting on fields to natural sort wasn't appearing for me until I resaved the field settings. And then I had to manually rebuild the vns index to get the new field sorts added to the views_natural_sort table. This might need an update hook so that it can be added on existing installs.

After reindexing the sorting works as expected on my plain text fields though.

Can you elaborate on "field settings"? I'm assuming you mean the sort settings on the view? This makes sense to me... I wonder if it's ok to switch out all standard sort handlers out on all views with the VNS one since this is what technically normally is what happens for those text fields... This would technically also be a problem if you installed VNS and altered an existing sort handler for something like title too so I'm tempted to call this a separate and existing bug. It does make me question if the way we are extending the sort handler and hijacking it in views data is the way we should be going architecturally speaking.

Reindexing may not be something we want to do on update hook... I'll need to see what I do on install... Because large data sets would hang deployment on drush updb and I'd prefer to avoid that if possible. I need to write a test for 1 million data points at some point.

I'll look into this further.

I mean the field storage settings on the field I was trying to change the sort for. Where you set if the field cardinality, etc. It could be that it was just a caching issue, but the options to use natural sort were not showing up when editing the view otherwise. I think I did a drush cr after applying the patch and it wasn't showing up though.

First, thanks for the hard work in getting this out to the community! The alpha 7 version with this patch seems to be working for me on Drupal 10. The one question I have is about the indexing. It looks like all applicable fields get indexed when enabling the module or saving the settings. The instructions mention enabling indexing on a per-field basis on an entity's field storage screen. Is that intentionally no longer the right way? My field storage page does not have those controls. My View does give me the option to "Sort ascending naturally" and it's working, which is great.

However, my views_natural_sort table now has almost 37,000 records when I was expecting more like 50 (for the single field I need this for). The indexing process went Indexed 158,736 entries.

Is that the expected behavior?

Sorry about the long hiatus. Right now, with this patch, it's indexing "everything". It's not quite feature parity with the D7 version. I'm working my way out of a hole here a bit, and I hope that it soon will actually be something like:

Only the fields that have views that have natural sorting applied to them will be indexed. So yall haven't missed anything I don't think, it's just not there.

Rerolling this Merge Request with what's in the current dev release since there were a massive amount of code cleanup changes.

Thanks for all your work on this feature. It works perfectly for us. However, the views_natural sort table is one of the largest tables in our database:

views_natural_sort ~66,998 InnoDB utf8mb4_general_ci 5.5 MiB

For context, our node revision table has 15,236 rows. So, 67k rows is quite large for our size of website. Does the module really need a table this large to function? I'm asking because the size of our database is making our website slow and I'm looking for ways to slim down our database.

Truth... no. It's heavy handed. You can use one of the hooks to limit what data is stored. I'll sleep on it and work up a suggestion until I get you some 3.0 features worked out. Ideally you would only index the items that are referenced in views config. But at the moment you get every possible item that could be used.