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
Comments
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:
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: |
Ok i am getting in contact with him right now to contribute to this ticket. Thank you for your help/support. |
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 ? |
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? |
Hi @snake14 , Thank your for your response. At this time, several plugins use custom Tags: Regards, |
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. |
@ronan-hello |
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.
The text was updated successfully, but these errors were encountered: