forum.coppermine-gallery.net
Support => cpg1.4.x Support => Older/other versions => cpg1.4 plugins => Topic started by: Gwyneth Llewelyn on August 17, 2009, 01:44:50 am
-
Hi,
I'm changing the mac_ox_x theme, and wish to add a new menu item without touching the theme's template files (http://forum.coppermine-gallery.net/index.php/topic,59868.0.html) (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 (http://forum.coppermine-gallery.net/index.php/topic,37612.0.html), 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.
The plugin manual (for 1.5...) suggests:
<?php
$thisplugin->add_filter('sub_menu','add_sub_button');<br />
function add_sub_button($menu) {
$new_button = array();
$new_button[0][0] = 'MENU LINK';
$new_button[0][1] = 'menu link';
$new_button[0][2] = './menu_link.php';
$new_button[0][3] = 'class_name';
$new_button[0][4] = '::';
$new_button[0][5] = 'rel="nofollow"';
array_splice($menu, count($menu)-1, 0, $new_button);
return $menu;
}
That's very nice, but a) I don't know what all of those options mean (why the duplication on - and [1]? What is the class_name, can we replace it by one of our classes? What is
::?); b) all my efforts to implement this result in this bit of code to be completely and utterly ignored. It simply doesn't work under Coppermine 1.4.25 (stable). Possibly because this only works under 1.5...
Searching and replacing the whole HTML (as suggested here (http://forum.coppermine-gallery.net/index.php/topic,25127.0.html) in 2005 or here for LoginForm (http://forum.coppermine-gallery.net/index.php/topic,33349.0.html)) 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 when the page 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 (http://forum.coppermine-gallery.net/index.php/topic,26893.msg160554.html#msg160554) and try to remove buttons that way (and then, how do they get added?).
After a weekend of tweaking around, I simply changed the template and include/themes.inc.php for now (without a plugin), since tomorrow 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?
-
Sorry, the topic should be
Such a simple question: how to add a new button under SUB_MENU? (via a plugin)
and not
Such a simple question: how to add a new button under SYS_MENU? (via a plugin)
Also, I should have put :: under teletype tags and not code tags.
Sadly I can't change the original post!!! My apologies!
-
I should also add that in the mean time I've gone through the Coppermine Forum Plugin (http://forum.coppermine-gallery.net/index.php/topic,51535.0.html), 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 (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).
-
I think you might be a bit off track in your assumption about theming and templates.
....without touching the theme's template files (to make sure they remain untouched for possible upgrades)
Your 1.4x themes and templates are exactly what you reuse and keep as you upgrade.
So my suggestion is to use the template and theming options that are given....
-
Well, you might be right, of course, I'm basing my assumption on just the revision numbers of the mac_ox_x template, which changed while upgrading Coppermine. To be honest, I haven't done a step-by-step comparison to see if there was, indeed, a 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 (imagine, for instance, that the next version has an extra button, or the whole templating system is redone from scratch). 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). And both things, of course, might happen simultaneously: on a future version, Coppermine's templating engine might change dramatically and all themes are suddenly much more feature-rich — except for my own, which will be old, clunky, and incompatible — while the plugin, of course, will not work with any other theme except my own tweaked one.
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 plugins have a reasonably well-documented approach to multi-language support). Both approaches do not make much sense to me.
So what you're suggesting is that instead of adding a button via a plugin I should simply redesign a new template and a new multi-language support engine just for that theme?
-
It's a pity that you keep on refering to cpg1.5.x. I already told you in the other thread where you asked questions about cpg1.5.x that you mustn't do that yet, because cpg1.5.x goes unsupported. Specifically on the cpg1.4.x support board it's a bad idea to refer to cpg1.5.x things, as it's confusing and misleading.
Marking thread accordingly and locking.