Deprecate vocabulary weight property

I have to say I'm not a great fan of removing this feature. I can think of at least 3 Drupal (7/8) projects I've done in the last few years which have relied on this to sort vocabularies in custom filter blocks etc.

I can't be the only developer in the world who uses it, and I expect most who do will be doing something custom with \Drupal::entityQuery() where it works, and will not necessarily notice the ongoing bugs/issues with views/entityreference.

If it's decided that it's really not needed then I guess it's fine to depreciate for 8.x it and flag for removal in 9.x, however I still believe the more sensible approach is just to fix the bugs with the existing implementation.

Hi @andypost,

We've used it to allow customers to change the order of their filters as below:

Using the drag/drop feature of the core vocabularies is much more convenient than implementing something custom.

@mattjones86, your case is valid but too specific. The filter on the screenshot is made with custom code, I suppose. From this point we should also add weight property to content types because it may have the same use case.

Out of box this property is not used in Drupal 8 and that makes the draggable inteface on admin/structure/taxonomy page confusing.

Even resolving #2969183: Vocabulary weight not honoured by Entity Reference fields will make a little difference. Implementing draggable interface just to specify order of vocabularies on field settings form seems redundant to me.

I stumbled upon this discussion because I was looking for a way to programmatically get the weight property for my vocabularies.

My use case is similar to @mattjones86. I'm building a site with a search page that has several filters, where each filter corresponds to a vocabulary.

I understand that one of the arguments for removing the weight property is that Drupal core does not use it anywhere. However, that feature has been around since Drupal 5 (according to https://www.drupal.org/docs/7/organizing-content-with-taxonomies/create-...), and there might be more developers (like mattjones86 and me) who need this feature but aren't voicing their opinion because they don't know this discussion is happening.

@Chi wrote on comment #5:

@mattjones86, your case is valid but too specific. The filter on the screenshot is made with custom code, I suppose. From this point we should also add weight property to content types because it may have the same use case.

Not necessarily! AFAIK Drupal never offered a weight property for content types, and I'm not aware of any feature requests that ask for it.

@andypost thanks for your feedback on this.

I don't believe either of the replacements you've suggested are suitable for site editors - for developers perhaps. In my opinion the only suitable replacement would be to use the Entityqueue module to allow the vocabulary list to be sorted with drag+drop.

This would provide the a similar editing experience (although somewhat clunkier) at the cost of quite a bit of performance and development overhead.

My 2p is that I really don't understand the rationale for removing a core feature which has very little support requirements from Drupal's side. If it was causing problems in other parts of the code or lots of support tickets then I could totally understand.

Also the agument that "'Content Types' don't support this" is not really valid, since the Taxonomy and Node modules were build to solve totally different problems and have very different requirements.

This is going to cause real problems for me and block me upgrading sites to Drupal 9, I'd be very surprised if I'm the only one!

Hi everybody!
I have the problem because the same case as @mattjones86 here. Filters order.

Will this need a deprecation test?

I still think you're going to be unpleasantly surprised how many developers were quietly using this without ever stumbling across this issue or having any input on the discussion.

For me personally (a single isolated developer), this will probably be adding £1000 to the next core upgrade to cover developing a custom solution to replace what was previously a core feature.

Hopefully someone will just re-implement this in contrib quickly.

Stumbled across a related feature request: #3107650: Unable to sort by term weight for contextual filter: term Name

Note that #3008064: Deprecate vocabulary weight property is marking this fully validatable, and is adding the following changes wrt weight's config schema:

     weight:
+      # @todo Deprecate in https://www.drupal.org/project/drupal/issues/3008064
       type: integer
       label: 'Weight'
+      # A weight can be any integer, positive or negative.
+      constraints:
+        NotNull: []

👆 That amounts to no changes at all: it just means that any integer is accepted. It also means that it should remain trivial for this issue to deprecate weight 👍

#29: that @todo should be converted to a follow-up issue that will remove it if #2002174: Allow vocabularies to be validated via the API, not just during form submissions lands first.

I'm not convinced this is worth removing and lean towards doing #1821274: Add back ability to sort on vocabulary weight and name instead. The big difference between taxonomy vocabularies and content types is they're much more often exposed or combined into a single list etc.

That means we should mark this Closed (works as designed) and leave a comment on #1821274: Add back ability to sort on vocabulary weight and name. #2, #8 and others indeed suggest this is actively being used.

Done.