Ok, I'm trying again. Since apparently it's forbidden to refer to future versions of Coppermine, I'll try to rephrase my question again, without any references to possible eventual future versions or to possibly existing documentation for those versions.
I'm changing the mac_ox_x theme, and wish to add a new menu item without touching the theme's template files (to make sure they remain untouched for possible upgrades). The menu item should be under the SUB_MENU (which almost nobody seems to like to do) instead of the SYS_MENU (which everybody seems to love, and it took me 30 seconds to locate at least three different ways of doing this, all of them working flawlessly).
Sadly, changing the SUB_MENU seems to be far less popular than the SYS_MENU. After spending several hours browsing through the forum, I still haven't found a working solution. Coppermine 1.4, as you know,
doesn't have any official documentation for writing plugins and
there is just a list of hooks from 2006.
Searching and replacing the whole HTML using the
template_html hook (as suggested
here backin 2005 or
here for LoginForm) is really not an option for me. After a lot of searching and replacing, it seems that I could remove {SUB_MENU} entirely or add new entries at the bottom of it. Sadly, the mac_ox_x theme has a table wrapped inside {SUB_MENU}, so adding an extra <td>...</td> is not easy... specially because you can't simply replace existing elements yet (they haven't been rendered yet at the moment the hook was called).
The older a forum entry is, the more the suggest either replacing the theme template or searching and replacing through the whole HTML. More recent entries only talk about the SYS_MENU. Some suggest to
install the final_extract plugin and try to remove buttons that way (and then, how do they get added?).
I should also add that in the mean time I've gone through the
Coppermine Forum Plugin, which allegedly also changes the SUB_MENU and not only the SYS_MENU, using almost identical code for both. That's pretty advanced "magic" for me, and adapting it for my own plugin, it definitely works flawlessly for the SYS_MENU, because it basically assumes that SYS_MENU is tagged with comments, which it is; but it also assumes that SUB_MENU has similar tags, which it doesn't — at least, not under the default [ie. untweaked] mac_ox_x theme.
After a weekend of tweaking around, I simply changed the template and include/themes.inc.php for now (without a plugin), since today I'll have the client looking at the result (sorry, it's still not released to the public, so I can't show it). But I still wonder how this can be properly done inside a plugin?
i-imagine
suggests that changing buttons should not happen inside plugins at all, but only on theme templates:
Your 1.4x themes and templates are exactly what you reuse and keep as you upgrade.
I've found out that this might not always be the case. Upgrading from Coppermine 1.4.16 to 1.4.25 showed that at least the revision numbers and copyright header information on the theme has, indeed, changed — at least for the mac_ox_x theme. To be honest, I haven't done a step-by-step comparison to see if there was any other change besides the revision number (and minor copyright disclaimers on some headers). Perhaps there weren't any changes. I don't know. That's exactly my point here: I don't know, and I can't know, if something changes on the theme templates from one version to the other. To be completely sure that during an upgrade any problems that arise are only my fault (and nobody else's), I prefer to leave the templates as untouched as possible.
Worse than that — if I change a template and
theme.php for a template too much, it will be a pain to make sure that a particular plugin will continue to work if someone changes the template later on (even if the Coppermine version does not change).
By putting all possible changes inside plugins and not themes at least I have just one thing to change due to a dramatic upgrade. If something fails, it's just the plugin — the rest of the Coppermine install remains perfectly functional. So I have just one person to blame and one section of code to rewrite: the plugin.
Furthermore, I don't see (yet) how I can add multi-language support to themes without using plugins (I mean, if I need completely new buttons and elements that are not on the "mainstream" themes). Granted, I can replicate the whole multi-language support on
theme.php, and create new "lang" directories for that particular theme, but this is really overkill. Or, of course, I can make a theme so bound to the plugin that it will only work with that plugin installed and nothing else (since multi-language support on plugins are reasonably well-documented on some plugins posted the forums and is easy enough to do). Neither approach makes much sense to me.
So is the only option of adding a new button on a multi-language theme to redesign a
new theme (based on the existing one) and create a new multi-language support engine just for that theme?