Background of the issue:
I am trying to solve an issue related to WPML where an 'ALTER TABLE' is generated at runtime. I previously opened a ticket, but it was closed too early without waiting for my feedback. I am attempting to address this issue again.
Symptoms:
WPML try to alter tables at runtime but, due to the structure of our DB, we kept TABLEs ONLY for the main blog, while most of the tables have been replaced by VIEWs in the secundary blogs (with a few exception).
This replacemente is due to the fact wp_posts has the same structure (TABLE in the main blogs + VIEWs in the remaining blogs).
To have a better evidence of tables and views, se the attached query resut as executed on "wpml" tables
Questions:
Why was my ticket closed too early without waiting for my feedback?
How can I solve the issue with 'ALTER TABLE' being generated at runtime?
The basic would be to check (before any ALTER command) if the target is an actual TABLE or a VIEW.
I guess our revision of the DB structure should not be so unusual for wordpress DB.
(please let us check yur reply before closing tickets, I am travelling frequently and I cannot react immediately, esle would be better to define a date for a live chat to discuss this issue)
I didn't find the ticket you mention (related to this topic). Anyway, this tickets remain open for two weeks without activity, then they are automatically close. If you need more time, just drop a line before that period and the period will be extended automatically for another two weeks.
About the problem:
WPML expects real (physical) tables for all of its icl_* tables on every site in the network, not MySQL views.
Why WPML needs real tables?
- During activation, updates, and some maintenance routines (e.g., String Translation scans/optimizations), WPML performs schema checks and automatic repairs. These include ALTER TABLE operations to add/update indexes or columns on icl_* tables.
- MySQL views can’t be altered with ALTER TABLE. When WPML’s maintenance routines run against a view, they fail, which is what you’re hitting.
WPML assumes each site’s icl_* tables are physically present and writable. Your setup—replacing per-site icl_* tables with views—is not supported at the moment.
You'll need to convert all icl_* objects that are views into physical tables on the secondary sites.
I’ll raise your architecture as a feature request so our team can evaluate whether WPML could become “view-aware” (e.g., detect and skip schema ops on views or provide an alternative flow). This is only a request—there’s no commitment or timeline, and if accepted it would take time to design, implement, and test.
i understand WPML cannot follow and support customizations like our (even if it would be a smart decision to have flexibility to support data pooling)
the main question is how would be possible to stop checking and trying to fix table structure at run time
would not be more reasonable doing DB check/update/repairs made more on a “update” basis than at runtime. the tools/troubleshooting area have many similar features
Our dev team confirmed it's not currently supported. We can't provide a workaround because it involves many moving pieces. We added to our feature requests backlog, and we may consider implementing it in the feature, but we can promise it will nor when.
I am sorry I can't be of better help regarding this problem.
