Exibir metadado em ordem alfabética

Desenvolvimento Novas features e melhorias
1

Criamos aqui um metadado, porém, no momento de cadastrar um item da coleção, ao abrir a caixa de diálogo do metadado, os dados que posso escolher são sempre exibidos na ordem em que foram criados e não em ordem alfabática. Tem como alterar isso para exibir sempre em ordem alfabética?

2

Oi @Brancorp2000, tudo bem? Cara, a resposta por enquanto é que infelizmente não temos essa opção. Já foi discutido algumas vezes e pretendemos implementar ago do tipo. Seguem duas issues relacionadas:

Acredito que a segunda aí seja exatamente o que você está pedindo. Podemos discutir aqui sobre priorizar ela sim

3

Oi Mateus, acho que seria uma opção muito importante sim.
Não entendi o que posso fazer nessas issues… tem alguma solução ali?

4

Hahah desculpe não explicar. Essas issues são como acompanhamos bugs e recursos que precisam ser tratados. Temos uma visão geral delas aqui:

Vou conversar com a equipe aqui sobre subir a prioridade dela. Não é muito complicado, é mais termos brecha mesmo porque tem bastante coisa na fila

1 curtida
5

Ah entendi! Beleza, eu fico no aguardo então!

6

Oi pessoal, bom dia!
Registro aqui que também senti a necessidade da ordenação alfabética. Facilitaria muito o cadastro dos itens. O trabalho que fiz utilizando o Tainacan está publicado na BDM (Biblioteca Digital da Produção Intelectual Discente: Dos acervos impressos aos acervos digitais em rede : uma proposta de gestão e acesso à Revista Beneditina por meio da plataforma Tainacan)
Abraços e parabéns pelo desenvolvimento do Tainacan. Excelente ferramenta para os profissionais de Galerias, Bibliotecas, Arquivos e Museus

2 curtidas
7

Hi Mateus,
Any progress with this issue: Option to order term values by creation in the taxonomy metadata input. · Issue #618 · tainacan/tainacan · GitHub ?
I’m building a library database for sheet music and it is crucial for me that terms from my taxonomy for e.g. instruments are displayed in exactly the same order as entered.
So … do you have any idea if - and when - you will look into this issue.
All best,
Hugin

8

Hi @Hugin_Eide, welcome to our forum!

Sadly, we didn’t have the opportunity to put this upfront in our priority list. Lately there has been a lot of development in other areas of the plugin and the two features mentioned in this thread are not present in the coming releases.

The one that you mention (618) is related to the Taxonomy Metadata input, but I believe there is a broader one which might be of your interest, which is the 421. That one is considered one of our hardest issues so far because we do not have, in WordPress database structure, a way to track the value insertion moment, in order to sort values.

Nevertheless it is important to have you asking things here because it helps us prioritize things in incoming planning!

9

Thank you for you answer.
Tainacan is a great plugin - flexible and easy to use - and is just perfect for my planned sheet music database, except for this little issue with the sorting af the taxonomy terms.

I asked my new “friend” ChatGPT if that WP issue you mention has been discussed in WP fora and if there have been any suggestions to solutions.

You have probably asked ChatGPT yourselves ;-), but I’ve pasted the answer below (maybe it can be of some use).

Best,
Hugin

(quote start)
Yes—there’s quite a bit of WordPress-core + community discussion around “preserving the order of terms as selected,” and (crucially) the data model already has a place to store it:

What core says (and why your team is blocked)

  • WordPress keeps post–term links in wp_term_relationships, which includes a term_order column—but core doesn’t use or populate it. Many threads point out that it’s effectively “unused by core,” even though it’s exactly what you’d want for “as-entered” order. (core.trac.wordpress.org)

Community threads that propose solutions

  • Use term_order and custom queries: Multiple answers show how to order terms for a post by term_order (e.g., via terms_clauses filters or custom SQL), noting that core’s term queries don’t natively support orderby=term_order. (WordPress Development Stack Exchange)

  • Stack Exchange discussions on ordering terms and related gotchas (hierarchy order, etc.)—the key takeaway is that you must opt-in to custom ordering; core defaults to name/ID. (WordPress Development Stack Exchange)

Proof it’s feasible (plugins that already do it)

  • Post Terms Order – per Post based (by Nsp-Code) adds a drag-and-drop UI to set per-post term order—i.e., it writes the order for the relationship, not just globally. That’s exactly the “insertion/order per item” use case, built on the same tables Tainacan uses. (WordPress.org)

  • There are also popular plugins to set a global custom order of terms (useful, but not per-item): Taxonomy Terms Order / WP Term Order / Custom Taxonomy Order. They demonstrate how to surface and respect a non-alphabetical order, but usually at the taxonomy level, not the per-item relationship. (WordPress.org)

Practical path Tainacan could adopt (from those discussions)

  1. Capture selection order on save
    Hook where Tainacan saves the item’s terms and populate wp_term_relationships.term_order with the position (0,1,2…). Core’s wp_set_post_terms() won’t set it; you update it immediately after. (This is what per-post ordering plugins do.) (WordPress Developer Resources)

  2. Respect that order on read
    When rendering a metadata field with multiple terms, fetch via wp_get_post_terms() and force ordering by term_order (e.g., join on term_relationships using terms_clauses or rebuild the ordered list using the stored IDs). Community answers show both patterns. (WordPress Development Stack Exchange)

Why this dodges the “no timestamp for insertion” problem

You don’t need a timestamp: the position is enough. The WP schema’s term_order is expressly intended for ordered relationships; it’s just unused by core. Trac ticket #9547 documents this gap and has patches/notes discussing enabling it. (core.trac.wordpress.org)

TL;DR for the Tainacan team

  • Core doesn’t preserve selection order, but the official relationship table already has term_order.

  • Community precedent (plugins + Q&As) shows two workable tactics:

    • Write an order per post–term relation (set term_order during save).

    • Read with a custom ORDER BY (or rebuild the ordered array), since core queries don’t sort by term_order out-of-the-box. (WordPress Development Stack Exchange)

  • If they prefer not to touch SQL, a fallback is to store the chosen order in postmeta and then call wp_get_post_terms() with 'include' => $ordered_ids (which returns terms in the order of include). That pattern is used widely in forums/tutorials. (WordPress Developer Resources)

If you want, I can draft a small, self-contained proof-of-concept snippet that (a) records selection order into term_order on save, and (b) renders that field in saved order—so you can share it with the Tainacan devs as a concrete starting point.
(end quote)

10

Yes, we’ve already explored some of this in the past. The WordPress Terms and Taxonomy tables are confusing because they clearly contain a structure that is more complicated than needed, or at least for what is used. If all it’s initial potential was unlocked then that complexity would be justified, because we could have all sorts of nice things like terms order, terms synonyms and even cross-taxonomy terms reuse! However, once you get into the details you start noticing that things are more complex and a lot has been left half backed.

That first strategy (term_order) is the quickest, because we could use a data field that is already there. There are still challenges anyway. Mapping all the places where the queries are made to pass the new order_by, for example. Every time we move a bit out of WordPress standard queries we risk loosing performance optimizations. But one thing that I don’t like about this strategy is that it will only solve the issue for Taxonomy metadata, whereas sorting values is an issue for every type of multivalued metadata.

So in the future we might probably look at a way for storing extra information about the postmeta. This would allow us to do all the extra work (manipulating sort, updating values and storing order) for every metadata. There are several things to consider still: how will the UI for sorting this things be? How will this work in bulk-editing/importing scenarios? Will this affect filters and facets somehow? etc…

This is kinda why we haven’t figured out a solution for this. It is certainly in our plans for the future, but I believe in the next year we’ll be tackling more urgent demands such as refactoring our Logs and Mappers, and improving attachments manipulation.

1 curtida