Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag Manager extended plugin #729

Open
Chardonneaur opened this issue Nov 23, 2023 · 7 comments
Open

Tag Manager extended plugin #729

Chardonneaur opened this issue Nov 23, 2023 · 7 comments

Comments

@Chardonneaur
Copy link
Contributor

Hello team,

There is an issue that the Tag Manager extended plugin is raising. When we uninstall it, as it is using some specific tags which may have been used within the previous container versions, then we cannot publish any other versions.
The solution would be to be able to remove tags associated with this plugin when we are removing it.
I asked to the developer to do it but he told me that it is due to the tag manager behaviour itself.

@snake14
Copy link
Contributor

snake14 commented Nov 23, 2023

Hi @Chardonneaur . Thank you for taking the time to create this issue. I think that I was able to recreate the issue you described. I installed the TagManagerExtended plugin, created a Hotjar tag, disabled the plugin, and tried to publish a new version of the container. I received the following error:

ERROR API[2023-11-23 20:28:01 UTC] [7989f] Uncaught exception in API: /home/jacobr/projects/matomo/plugins/TagManager/Template/Tag/TagsProvider.php(48): The tag "Hotjar" is not supported [Query: ?date=yesterday&module=API&format=json&method=TagManager.createContainerVersion&idContainer=4TJOz4fJ&idContainerVersion=&segment=&idSite=14&period=day, CLI mode: 0]

That seems like a pretty standard validation check failure, which makes sense as the tag isn't a type supported by the TagManager plugin. It seems like the TagManagerExtended plugin should implement the deactivated and/or uninstall methods to remove the tag and variable types that it added.

Edit:
If the developer isn't willing to do that, I suppose we could make the validation check a unique exception type and simply ignore unsupported types. For example, we could surround the API call with a try/catch and ignore validation errors. However, if done incorrectly, that could lead to potential loss when importing a container.

@Chardonneaur
Copy link
Contributor Author

Ok i am getting in contact with him right now to contribute to this ticket. Thank you for your help/support.

@ronan-hello
Copy link

Hi,

I'm the developer behind the TagManagerExtended plugin. And I understand the Tag Manager behavior in this situation.

I think that if we want more plugins with custom tags, Matomo should handle the situation where Tags is not recognised, and just ignore the tag in the container. A global tags check before editing the container could be useful and add to the Matomo core TagManager plugin ?

If the situation is fixed from the plugin, then the situation isn't fixed at all right ?

@snake14
Copy link
Contributor

snake14 commented Nov 30, 2023

Hi @ronan-hello . Thank you for reaching out. Up until this point, I believe that developers have created pull requests on this project when they wanted to add new Tag/Variable templates. This is the first case that I know of in which we've had a second plugin add more templates for the TagManager plugin.

I can see both sides. The TagManager plugin should probably handle the situation more gracefully. However, it makes sense for the make the situation known when there's a Tag/Variable type that isn't supported by the plugin. We could simply ignore them, but then customers might wonder what happened to Tags/Variables that they used to have. In that regard, I wonder if it would make more sense for the plugin that supports the types to warn the user that those types will be removed when the plugin is uninstalled?

@ronan-hello
Copy link

ronan-hello commented Dec 4, 2023

Hi @snake14 ,

Thank your for your response.
For sure, I can update the plugin in order to prevent bad usage before remove/uninstall the custom plugin.

At this time, several plugins use custom Tags:

Regards,
Ronan

@snake14
Copy link
Contributor

snake14 commented Dec 4, 2023

Thank you @ronan-hello

@Stan-vw It looks like there are already other plugins that create custom tags. With that in mind, we may want to look into a better customer experience if unsupported tag/variable types are found while importing a container or creating a new version. We could do something as simple as what I mentioned in the edit portion of my previous comment, but that would simply ignore unsupported types instead of notifying the customer.

@AltamashShaikh
Copy link
Contributor

@ronan-hello
We reviewed the work with the team, and our recommendation is for plugins to handle uninstalling gracefully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants