info.xml - Allow extensions to define a list of tags #16551
Conversation
Overview
--------
This adopts a convention by which extensions may use `info.xml` to register tags, e.g.
```xml
<extension key="org.civicrm.foo" type="module">
<tags>
<tag>civicontribute</tag>
<tag>payment-processor</tag>
<tag>install-mandatory</tag>
</tags>
</extension>
```
Before
------
To add *any* metadata to `info.xml` files, you must update the parser and providing
filtering/indexing.
After
-----
If you need to add very simple metadata (tags), you can do that without
extra parsing code. The tag information can be accessed in the following
ways:
* Using the extension mapper
```php
$mapper = CRM_Extension_System::singleton()->getMapper();
$allTags = $mapper->getAllTags();
$mandatoryExts = $mapper->getKeysByTag('install-mandatory');
```
* The `Extension.get` API will return the list of tags for each ext
|
(Standard links)
|
|
I guess my question is - about control - this makes it easy to add new tags - for better and worse. We don't have to change the code to define a new tag - but is there a control aspect to 'free-tagging' - or do we not care what tags people give, as long as they don't expect anything other than documented ones to trigger functionality. It feels like once this is merged I can go back through my extensions & give them 'helpful' tags. But it also feels like the goal is that I tag my payment processors with 'payment-processor' not paymentProcessor' or 'payment_processor' to support some future UI along the lines of what John FF did |
|
@twomice pinging you in as extension lead |
|
@seamuslee001 @colemanw @mlutfy @MikeyMJCO ping |
eileenmcnaughton
added
the
merge ready
|
I would say "needs documentation" in line with your first comment above regarding what it's intended use is - if there are tags that do certain special things they should be documented. Otherwise it looks ok to me. |
|
+1 for "needs documentation". Devs will benefit from knowing what's expected, supported, and allowed WRT extension tags. I'm not sure how much this has been discussed so far. Is there somewhere a proposed list of supported tags, and perhaps even a proposed format for tags (contribute vs civiContribute vs civicrm_contribution, etc.)? |
|
I've been thinking about a similar idea for a while - especially because there are many extensions that are popular for building on top of (CiviRules, CiviToken, and Extended Reports off the top of my head). However, there isn't a UI for discovering new rules/tokens/etc. Tagging with "Provides CiviRule action" would enable this. Most of the tags I would actually want/use focus on the feature they extend - "soft credits", "contribution pages", "PCPs" etc. In some ways, there's a question of whether there's a taxonomy that's more granular than the Civi components that makes sense for talking about Civi as a whole. |
|
I'm going to merge this since I think this concept has agreement & Ill take the docs conversation to the docs queue |
|
Docs PR is civicrm/civicrm-dev-docs#761 |
Overview
This adopts a convention by which extensions may use
info.xmlto register tags, e.g.Before
To add any metadata to
info.xmlfiles, you must update the parser and provide filtering/indexing logic.After
If you need to add very simple metadata (tags), you can do that without extra parsing code. The tag information can be accessed in the following ways:
Extension.getAPI will return the list of tags for each ext