Dolibarr the PHP beast - Problems with module installation

[luckow]

Today I spent a few lives trying to get an idea of how to sync Dolibarr with WordPress WooCommerce. Good news: there is a module for that.
WooCommerce SYNC -> https://github.com/OPEN-DSI/ecommerceng_woosync

But it ends with an unsolvable problem:

Error copy file '/app/code/htdocs/custom/ecommerceng/patchs/dolibarr/includes/OAuth/OAuth2/Service/WordPress.php' to '/app/code/htdocs/includes/OAuth/OAuth2/Service/WordPress.php'

My best guess is: yes, we can handle it on the app package level. Link /app/code/htdocs/includes/OAuth/OAuth2/Service/ to the /app/data directory.

But really? Should we install all available modules to get an idea of where the module developers want to copy files to the read-only file system level?

Do you have an idea on a general level to solve such core/module problems?

[Inli]

@luckow the main problem is : a plugin tries to patch a dolibarr core file ... that could be a very bad idea (security point of view) and then what about dolibarr upgrades ?

For example:

• i install dolibarr 14.0.1
• then i install that plugin wich update a core file (includes/OAuth/OAuth2/Service/WordPress.php)
• some time after i will update dolibarr to 14.0.2 -> for sure includes/OAuth/OAuth2/Service/WordPress.php could be override by dolibarr update

what about the consequences ?

[luckow]

@inli Dolibarr is not the only FOSS with this kind of extensible functionality. In an ideal FOSS world, abstraction layers for modules/extensions/plugins exists and Cloudron apps are "easy" to package and update. 100+ apps in the store shows us, that this is possible.

My question is: should we invest time in applications like Dolibarr, where installing modules puts us in this situation? Do we have a generic solution for "hacking core"?

My position for a scalable video conferencing solution on Cloudron is clear: no Install a greenlight (Frontend for BigBlueButton) and use a separate cluster to scale. Perhaps we should define the same position for FOSS with "scary development" or find the holy grail to fix all possible side effects.

An alternative way could be: use Dolibarr without modules. If it works for you, fine. If you need modules (and there are problems), install it on a separate instance.

[Inli]

@luckow that is a "good" point of view but in that precise case, the problem is on the plugin who "hack" main dolibarr core files, that's not a cloudron problem i mean

and what about dolibarr core upgrades, it will break oAuth functionnalities ? really that is a special case for ONE plugin who don't care about main dolibarr files ...

Hmmmm just to be clear, i'm sorry, for THAT module in that case it's not a patch, it does not modify a file in dolibarr core, it ADD a file in OAuth to enhance dolibarr oAuth support and add Wordpress as a OAuth source

So that's a surprise for me and i don't know what to think about that ...

[girish]

Yeah, these apps can be quite complicated to maintain. I have put a note for ourselves to see how we can solve deployments of such apps in the next release.

I will create a separate thread and see if we can come up with ideas.

[girish]

Started a new thread here - https://forum.cloudron.io/topic/6424/deploying-apps-that-treat-code-as-data