Updates for ultimate-addons-for-gutenberg (now Spectra) #320
Conversation
See compsupp-6801
| <item id="stackable-ultimate-gutenberg-blocks" override_local="true">Stackable - Gutenberg Blocks</item> | ||
| <item id="subscriptio">Subscriptio</item> | ||
| <item id="the-events-calendar" override_local="true">The Events Calendar</item> | ||
| <item id="ultimate-addons-for-gutenberg" override_local="true">Spectra</item> |
There was a problem hiding this comment.
@diiegopereira, I saw your comment in compsupp-6801, that the Spectra plugin has a local WPML config file.
Beware that if we override the local file, we may loose some local configurations if it was not synced on the remote one.
Can you make sure the local and remote config files are in sync?
There was a problem hiding this comment.
@strategio it seems that we have several differences between our remote file and the one included in the plugin: https://www.diffchecker.com/ArriH1zI/
I was trying to manually update the remote file by adding the differences to it. But I found some parts that can generate conflicts. E.g. in the remote file, the string is registered using xPath, but in the plugin file, it is registered using "key" (or a different xPath that belongs to the same string).
What would be the correct way to sync both files? Should we use what's included in the plugin, which looks more up-to-date? Is there a problem with a string being registered twice (key + xPath, or 2 different xPath for the same string)?
There was a problem hiding this comment.
@diiegopereira, let me share some elements:
-
String IDs (i.e. strings names) are based on the block name and the text content, we make a hash of that (see here). In short, strings are unique to block type and content. If we have twice the same content inside a block, we'll register only 1 string. So we don't risk to have duplicated strings or wrong string IDs inside blocks (note that this is not true for other page builders integration).
-
If you see that the plugin's local XML config looks more up-to-date than the remote one, it means that the author is maintaining his config (even not fully). At least, he probably does that more than us.
With all that said, I think we have 2 options:
-
Take real ownership of the config: First, we need to merge the local config into the remote one (as you started to do), and then inform the author that the remote configuration will now take precedence. If he wants to change/add blocks in the future, he will need to open a PR here.
-
Let the author take care of his config, and inform him about the issue we found (and perhaps ask him for a campaign of re-testing on his plugin).
I'll let you check what could be the best option.
There was a problem hiding this comment.
Thanks @strategio! I think we should contact the author and discuss the best option. Let's continue on youtrack for now.
See compsupp-6801