OS: Linux
Document Server version: 7.2.1.34
Browser version: Firefox 107.0
Hi ONLYOFFICE Team,
Is there a change in ONLYOFFICE version 7.2.1 which deactivates the method onExternalPluginMessage? This function no longer seems to work in my case from 7.2.
Best Regards
Uli
Hello @uwohlfeil
This method still persists: ONLYOFFICE Api Documentation - Events
Do I understand it right that this method doesn’t work in your plugin after Document server update to v.7.2.1? If so, probably we have to take a look at your plugin. If it’s possible please contact me via PM and provide us with your plugin and detailed description.
Yes, I also encountered this problem when I was using it. The conclusion I can get so far is the same as what you said before, but the authorities don’t seem to have solved the problem.
I wonder if your team has found a suitable solution to this problem?
I implemented this requirement in a different way, but the compiled plug-in must be placed on the server of the service. This is not very convenient. It is also because of cross-domain problems.
The general solution is as follows:
your web page:
docEditor = new DocsAPI.DocEditor("openFile", testConfig);
docEditor.serviceCommand("selfKey", anyMessage);
your plugins code：
window.parent.Common.Gateway.on(“internalcommand”, (data) => {
if (data == null || data.command == null || data.command == “”) return;
if(data.command === “selfKey”) console.log(data);
}）；
You can get any message you send using serviceCommand in the Gateway method.
We are checking the situation, I will update this thread when we have something to share.
Do you have any news regarding this issue?
Regards Uli
Hello @bashfuldeng @uwohlfeil
The described situation is related to moved mentioned functionality to Automation API. We’ve described the same case here: Version 7.3 externallistener cannot be allowed - #4 by Alexandre
If you have commercial license, please contact your manager to discuss the situation.
Sorry for inconvenience.
@Alexandre
Thanks you for your response.
So ONLYOFFICE remove this functionality without any replacement. To use this function the customers has to upgrade to the new pricing model to keep a existing functionality.
I think it is almost impossible to inform all customers about this change and to suggest that they upgrade to the much more expensive licence just to keep the functionality.
So we have to find an alternative way to fix the problem or stop further development in favour of a competing product. This is an unfavourable development.
Do you have any suggestions how to communicate between the parent window and the plugin iframe?
Are they any other plans for further function-restricting changes in the future while prices are rising (both at same time …)?
Please note that this plugin is outdated, so we moved forward to implement the new functionalities that avoid using third-party solutions as plugins, so basically the extended API is the direct extension of editors functionality that allow to interact with the editors from outside. I believe the situation can be resolved in a faster way if you contact your personal account manager.
Thanks for your response. We will contact the account manager.
It is of course normal that a product evolves and this can lead to breaking changes.
In this case, however, the process and the communication with the integrators is unfavourable. As far as I understand it, the function was removed without a deprecation flag within a minor release (7.1 → 7.2). This is unusual in the market. This raises questions about long-term reliability.
I have to say ‘sorry’ thousand times and it will be not enough. We thank you for your feedback and we will make sure that similar situations do not arise in the future.
Sorry for inconvenience.