Taxonomy terms should be listed in order they are entered

More information at http://www.drupalusability.org/node/20

Basically this means that when creating terms, newer terms should appear after older ones.

Just a note to say that during the usability tests, *all* participants expected this to work as proposed here.

BTW, there is a module for that.
http://drupal.org/project/tagorder

The problem may rise with a library/inventory/catalog application of Drupal when a large number of terms are added in the order they become available, but the user may expect to automatically see the list sorted alphabetically (or by other criteria). There should be links/buttons at the top of the term list to sort by [Weight | Alphabetically | Time/date Added]. Furthermore, after inserting a term, the page jumps all the way back to the Vocabulary list, instead of displaying the list of terms. Very tedious when having to add a large number of terms.

===================
http://www.elteto.net

Currently working on this issue at the Utrecht UX Sprint.

We worked out to set the default term-weight to the "maximum weight + 1". This will be done in taxonomy_term_save() to new terms by retrieving the value via query and add it as weight.
If there is allready a valid weight set, it will be kept. Because the existing value can be "0", indicator for not-set-weight will be a "" (or non existant $term->weight or invalid weight/non-numeric).
Therefore the term edit form is now set to default weight with "". Validation now allows "" and numeric values.
Description and validation message was also updated for new feature.

Patch is attached and ready to be reviewed.

This change shouldn't be necessary:

-    'weight' => 0,
+    'weight' => "",

Weight is an integer value so it should be 0. If you set it to 0, you should be able to clean up a lot of the if-test that you introduced.

This test is not necessary either, as far as I can see:

+      if ($max_weight == NULL) {
+      	$term->weight = 0;
+      }

Patch has some code style issues.

'weight' => "", is necessary, because it defines the default value for a new term. As this shall be set to max_weight+1 during taxonomy_term_save(), you cannot set it to "0" by default.

Changes to last patch file
* Removed additional validation in taxonomy_term_save()
* unset $term->weight in taxonomy_form_term_submit() for empty user input
* removed $term->weight also will update to maximum_weight+1 for updating terms

New patch file attached with code style issues hopefully removed.

I think the empty weight should be set to max_weight + 1 in the submit handler - this only matters if saving via the form, not if saving terms with the API, that removes some code weight as well - don't need to unset then put it back for example.

db_result() is deprecated, user db_query->fetchField() instead.

Don't use double quotes if single quotes are enough.

After thinking about it, I totally agree.

Especially when using taxonomy_term_save() for batch creation (like import), it would be very unperformant. So a contrib module developer should deal with insert it in right order, e.g by using its own iterator.

So now taxonomy.module stays untouched. The patch only does changes in taxonomy.admin.inc

Patch attached.

Ran failed test on current HEAD, no error occurs. Besides I couldn't imagine why there is at all a "User blocks"-Test failing. Any suggestions?

Ok, re-test passed.

Requested a retest, to see if it still applies. I don't have other objections.

-    '#required' => TRUE);
+    '#description' => t('Terms are displayed in ascending order by weight. When left empty, the term will be appended to the end of the term list.'),

I don't think we need the extra sentence here - users expected new terms to be at the end of the list after all. If we really do need the extra sentence then it should say 'defaults to the end of the list' rather than 'if left empty'.

+    '#required' => FALSE);

#required defaults to FALSE, so can just remove this.

+  // Term with empty weight is appended to the end by setting its weight to
+  // "maximum weight + 1".
+  if ($term->weight === "") {
+    // Fetch the max weight.

Can should just use single quotes where possible. It's also usual to leave a line break before inline comments to break up relatively dense chunks of code for readability.

Otherwise looks great.

Updating derhasi's last patch to include suggestions from catch. Patch attached.

HEAD is broken.

Just a thought, but what if the taxonomy terms list was a sortable table that allowed the user to sort alphabetically or by date entered?

We could only do that if there's no hierarchy - but that's often the case when entering terms.

To do date entered, we'd either have to hack it and use tid, or add a timestamp to taxonomy terms. A timestamp is useful information to have maybe, but a much bigger patch than this one. Maybe ORDER BY tid would be OK though, especially given this is only for convenience on admin pages.

Sorting terms in a different way shall stay part of contrib modules. This patch "only" deals with the fact, that most(!) users suggest a term to be entered at the bootom of the list when it was entered, and no weight has been given. This should be the default behaviour for core, because it improves usability.
Any contrib module can feel free to alter the weight before submission, so it can order it in the way it wants to.

@attheshow, thanks for updateing the patch ;)

Applied patch #2 and am seeing no issues with it. New taxonomy terms are now automatically assigned a weight of max+1. The same happens to existing terms if you remove the weighting.

How far did this get, and how much is missing to get this rtbc?

It's been tested by me, catch, casmaron, and the test bot. No failures. In my opinion, it's rtbc.

thanks. rtbc it is.

Still green

Let's get a test for this so we don't break it again.

If you enter lots of terms, allowing the auto-assigning of the weight, eventually you will receive a 'Out of range' error from the database for the weight column as it's only tinyint (ie -128 to 127).

edit: the 127 limit should be, and needs to be, fixed by #612870: Weight fields should be int, not tinyint.

subscribing - will this eventually be available in drupal 6 as well? thank you

One thing I noticed - with multiple parents set to YES, there is an issue with term weights as the term may be at a different weight under each parent. Example below where "station a" is the 1st on the list for Line 1, 2nd on the list for Line 2, and 3rd on the list for Line 3. With more stations, it becomes impossible to place "station a" in the right spot in the order at the moment. Will this be addressed in this issue or another issue for Drupal 7? Many thanks!

Line 1
-station a
-station b
-station c
Line 2
-station d
-station a
-station e
Line 3
-station f
-station g
-station a

I was wondering if anyone would be able to assist with this?

Using this issue thread's example for numbers, the below vocabulary is currently not possible as under parent:Numbers one is above two and three. (the best real world examples are train lines, bus routes, plane routes etc where there are common stops, but the stop is in a different order for each route)

Vocabulary
Numbers
-one
-two
-three
Countdown
-three
-two
-one

Here is a reroll of the patch from #17 to keep this issue moving along. It seems to work as expected... tests coming next.

Actually, after spending some time pondering this, it's a much easier problem to solve if we just assign the default weight in the form itself.

Adding proper comment formatting.

After conferring with alexpott we decided to roll a semantic change in here. All references to "Reset to alphabetical" have been changed to "Sort alphabetically" or their past-tense counterpart "sorted alpha..."

Since the order was never set alphabetically, there is no "reset" here.

One more message change.

subscribing

Tested and confirm the patch in #41 works as expected.

Bummer. The tests were dependent upon the names of the buttons which were changed. The tests pass locally now. Let's see if the testbot concurs.

This patch also changes the name of the buttons in the tests.

needs review then

I was wondering if this works for a hierarchical taxonomy vocabulary with terms with multiple parents?
For example, the term 'a' is 1st under one parent but 3rd under a different parent (has different weights).

A
-1
--a
--b
-2
--c
--d
--a

For now, there is no way to give a term two weights depending upon its parents. So, the only way - I know of - to handle the above example would be to assign some different weights to the other terms:

Term -- Weight
A      -- 0
-1     -- 1
--a    -- 3
--b    -- 4
-2     -- 2
--c    -- 1
--d    -- 2
--a    -- 3

There might be a contrib module to help with this, but I don't know of anything off the top of my head :)

Hi Kevin,

Nice to meet you at Drupalcon...

I was just trying to write a test for this functionality and I've come up against an issue. The existing ordering tests use taxonomy_term_save to create the test terms. Your fix only works when the term is created through the admin form. Perhaps we could move the test for a null weight into this function then all terms added through a standard drupal method will be added in the same way.

However thinking about this a bit more this opens a can of worms!

Especially for what in d6 was called free tagging... at the moment these are often entered through the node form and at the moment are in alphabetical order (even with your patch applied as this method uses taxonomy_term_save). And perhaps this is the desired result when you want users to free tag nodes. On testing this out I noticed another oddity... the terms on the node are listed in the order they were entered!!!

I think that perhaps the whole issue of taxonomy ordering needs some careful thought... and perhaps the default sort order should be configurable... either alphabetic or as entered.

Here is the beginning of the testing code fyi

Replace the createTerm function with

  function createTerm($vocabulary, $name = NULL) {
    $term = new stdClass();
    $term->name = is_null($name) ? $this->randomName() : $name;
    $term->description = $this->randomName();
    $term->vid = $vocabulary->vid;
    taxonomy_term_save($term);
    return $term;
  }

Add this method to the TaxonomyTermTestCase class

/**
 * Save 3 terms using the user interface and test ordering.
 */
function testTermMultipleAddOrder() {
	$names = array('gamma', 'beta', 'alpha');
  $this->createTerm($this->vocabulary, $names[0]);
  $this->createTerm($this->vocabulary, $names[1]);
  $this->createTerm($this->vocabulary, $names[2]);

  // Fetch the created terms in the default order, i.e. the order in
  // which they were created.
  drupal_static_reset('taxonomy_get_tree');
  drupal_static_reset('taxonomy_get_treeparent');
  drupal_static_reset('taxonomy_get_treeterms');
  list($term1, $term2, $term3) = taxonomy_get_tree($this->vocabulary->vid);
  debug(array($term1->name, $term2->name, $term3->name));
  debug($names);
  $this->assertEqual(array($term1->name, $term2->name, $term3->name), $names, t('Terms are in the order in which they were added.'));
}

Yeah, great to meet you as well. Fun how collaboration leads to more thorough testing and better software :)

You are right, that's an interesting dilemma. Regarding the default sort order configuration, that might warrant a separate issue.

As for testing this issue, we should look into drupal_form_submit(). There may also be a way to do it with some clever simpletest assertions and simpletest api functions, but it's not super easy as you'll need to do a form submission.

Regardless, I think that the default sort order on the form is the simplest solution here.

Here's a patch that adds the test for creating multiple terms through the taxonomy admin interface in an order that is not alphabetic and makes sure the terms remain in that order.

As noted in #49 I have a few reservations about this patch:

1. Terms created through the field interface don't obey this order and are still ordered in alphabetical order
2. And conversely, terms created through the field interface are listed on the node in the order they were entered

However, I can confirm that Kevin's patch works as intended for terms created though the taxonomy admin interface.

Here's a completely rewritten patch (that needs tests) that addresses some of the issues I've raised about the inconsistent ordering of terms.

The patch makes the following changes:

• Configure the default sort order on the vocabulary edit screen - either alphabetical or in order created
• Terms added through the taxonomy admin interface obey the vocabulary set default order
• Terms added through a free tagging field obey the vocabulary set default order
• Terms listed on the node view are displayed according to taxonomy sorting rules (weight then name)
• Terms listed in a free tagging field a listed according to taxonomy sorting rules (weight then name)

After applying the patch you will need to update the database as the "sort_order" column is added to the taxonomy_vocabulary table.

Oops... new patch

Patch now includes a new set of taxonomy tests specifically for testing ordering of multiple terms and how they appear on node views and node edits.

I'm changing the priority to critical as I've just tested taxonomy in D6 and discovered that taxonomy terms are always listed on nodes (both view and edit) according to their taxonomy sort order (ie. weight then name) and this currently does not happen in d7.

Created a new patch that does not have the "\ No newline at end of file" issue...

Made the usort callback function names more in line with what's in other modules (eg. block.admin.inc) and fixed a bug in one of these functions - should be using strcmp() and not strnatcmp()

#51 looks good to me on a quick look, have not reviewed in depth.

#57 is a new feature which should go into D8, or could be done via a contrib field module. For example, you could have a taxonomy term widget which allows you to use the default core drag and drop to order how fields are displayed. The current behaviour of sorting by field delta is by design IMO. Demoting from critical.

Hi Catch,

Not sure I agree with the current behaviour of sorting by field delta on the taxonomy free tags being by design. I think rather like the comment you made on #783112: Deleting a taxonomy term through admin interface causes issues if terms were created on the node edit form where you pointed out that "There is currently no way for modules which provide reference fields to update field API about edits or deletions of the referenced entities." - I can't see a way for module which provide reference fields to include data from tables that are not controlled by the field storage api - as obviously joining to the taxonomy_term_data table to sort by the weight during an entity load would be a more elegant solution to both this issue and #783112: Deleting a taxonomy term through admin interface causes issues if terms were created on the node edit form.

If some one has a large taxonomy that has been entered through the free tagging field and then looks at this taxonomy in the vocabulary admin screen and sees it all order alphabetically there but not on the node view - isn't this a little confusing? They would probably press the reset to alphabetical and there would have no effect. In fact - isn't one of the points of taxonomy weight to order terms on a node?

Perhaps a solution here is to leave out the bit that feels like a feature - namely the ability to define the default sort order on the taxonomy - and leave the code that sorts terms by weight on the node and makes terms entered through the admin interface be sorted in order created?

Thanks for working on this.

and leave the code that sorts terms by weight on the node and makes terms entered through the admin interface be sorted in order created?

Yes. The window for new features has been closed for some time now, it would be good to focus on only solving the original issue here.

Hi yoroy,

The original issue is solved by #51 but whilst creating a test for this I noticed the closely related issue taxonomy term sorting on nodes (as outlined in #51). Shall I create a new issue to propose solving the term ordering on nodes or shall we change the title of this to "Taxonomy terms should be listed in order they are entered in admin screens and by weight then name on nodes"?

Hmmm. As the solution to the original issue hasn't been committed yet I'd like to see that fixed first, but you've outlined its shortcomings clearly. From how I understand it, fixing it only for the taxonomy admin page is indeed only a partial fix that would give us two different behaviors. We want to prevent that.

Let's go for fixing the original issue of 'taxonomy terms should be listed in order they are entered' for all interfaces that lets you enter them. Thanks for explaining.

Not sure I have explained too clearly... :)

Current situation:

1. Terms created through admin interface are created with weight = 0 and therefore are listed in alphabetical order in admin.
2. Terms created through free tagging field on node are created with weight = 0 and therefore are listed in alphabetical order in admin but are listed in order entered on node edit (NB this might not be order the terms were created).
3. Regardless of where terms how the terms are created... on the node view terms are listed in the order of field delta... i.e not according to usual taxonomy ordering of weight then name.

My suggestion for the correct situation:

1. Terms created in admin interface should be weighted in the order they are entered.
2. Terms created through free tagging field on node are created with weight = 0.
3. When a node with free tags is edited the free tagging field should list terms in order of weight then name.
4. Terms view on a node should be listed in order of weight then name.

Here are my reasons for each of the suggested fixes:

1. As noted in #1 this is how users expect it to work.
2&3. Free tags can have lots of terms and alphabetical order makes sense. You are unlikely to use a free tag for a countdown or "numbers as text" sort of taxonomy. Imagine if you were relating nodes to types of kittens... if this list Abyssinian, American Bobtail, American Curl, Bengal, California Spangled Cat, Havana Brown, Munchkin, Norwegian Forest Cat, Selkirk Rex, Turkish Van, York Chocolate wasn't alphabetical it would be difficult to see if the term is already listed and manage it.
4. As above, when viewing a node with lots of free tags alphabetical order makes sense. Plus if someone does want a bizarre order then they can reorder the terms in the admin interface and this change would be reflected on the node view. This is how taxonomy weighting works in D6.

At the moment, if you enter terms via free tagging, they are "listed in the order they are entered", so that's consistent with admin - even if the ordering between admin and the node page might be different. There are completely different issues anyway, and I stick by the field API one being D8.

Ok. Checked in with catch on IRC:
- Different behavior is not necessarily a regression
- For this issue: let's go back to where we were in #51.
- alexpott: please open follow-ups around the other (yes, closely related :) issues you found.

Hope that gives us the right direction to bring this one home!

I'd just like to add from my own experience with this problem. It would solve most of the problems I've had , if when listing the terms in a node view, it would sort first by the vocabulary order, then by term order. I have both free tagging, as well as set vocabularies. For example, I have news items that are listed by the main category of what type of news they are, but I also included free tags to help classify them further. In node view, I'd like to see the taxonomy list first the main news category, then follow it by the free tags. Right now the free tags all have a weight of zero, and it won't let me manually set the main news terms to negative amounts, so they end up in the middle of the free tags.

Re-attaching the patch from #51 to help get this back on track. Lets keep the scope small and improve other cases in follow-ups

Subscribing.

Still a valid issue in Drupal 7.0.

Subscribe.

If I have read this correctly, this patch is going to be painful. About 95% of all lists we create are sorted alphabetical, so there is now going to be an additional step required when adding every term, and it is something new to teach a client about when creating terms.

The example vocab was incredibly simple (beginner, intermediate, advanced) and is bias to get a result that is not sorted, but if I have read those results correctly, only 3 of 11 users expected this to be sorted by the creation date.

Also, this will result in many Drupal sites supplying lists to the public that either not sorted or that are almost sorted alphabetically (ie: 10 terms are added alphabetically and then they add one that they missed at a latter date and forget to reset the list back to alphabetical). If these lists are greater than simple selects of less than 7 or 8 items, then the resulting list will be very difficult to use and will look untidy, adding a small negative feel for the use of Drupal as a cms.

However, I actually love the functionality, but would prefer a vocabulary selector to set the default behavior.

IE: On the create vocab page

Default term ordering
(*) Sort alphabetical
( ) Sort by creation date
This behavior can be overridden by changing a terms weight

Then toggle the default value and reset text on the admin listing page. :)

+1 for default term ordering.

I think the default-default should still be order entered. If I'm entering a list of categories, someone has usually supplied them to me in the order they would like to see them. When I enter them, I enter them in that same order. I want my results to be in that same order too, without defaulting to alpha, and needing to be rearranged. I can see your use case for wanting to change the default, since sometimes you really do want them in alpha order though. Love the idea of default term ordering per vocab.

The patch no longer applies (unsurprisingly).

A good issue summary would help here.

Cross-referencing #941266: Order of terms with same weight messed up after saving and #815682: Taxonomy term ordering on node view & edit not consistent with taxonomy weight, which also relate to term ordering.

Issue summary added

This include an api change so now this belongs to 8.1.x

Thanks @jibran.

As Taxonomy term ordering has worked this way for 6 years now, I don't think we can really call it a bug anymore, so much as just a behavior we might want to change. So recategorizing as a task. If we did change this in a minor, we'd want to think carefully about the change in expectation for existing sites.

I should clarify that if this were a bug, then it would be possible for 8.0.x if we decided the positive impact from the patch outweighed the disruption it introduced.

I'm actually also not convinced that this behavior is desirable, FWIW. The related issue #815682: Taxonomy term ordering on node view & edit not consistent with taxonomy weight however does still seem like a bug to me.

This is clearly a bug.

@hass, no it isn't. Ordering terms with no deliberately specified weight alphabetically by default seems entirely logical. If you want to order terms by creation date, contrib can provide that.

After having thought about it overnight I'm going to mark this issue wontfix, as there is not really anything relevant on it in the D8 cycle and the last patch is from 2010. If someone wishes to file a current issue, they can, but as there were no comments on it since 2011, I think we can safely assume the default behavior is fine by most users.

That said, I'd still be interested in a patch for #815682: Taxonomy term ordering on node view & edit not consistent with taxonomy weight because I think the inconsistency between one UI and the other is a bug.