Skin path handling vs. plugins

[rcubetrac]

Reported by @alecpl on 19 Feb 2013 13:07 UTC as Trac ticket #1488967

In one plugin I wanted to add some content to compose page with:

$rcmail->output->add_footer(
   $rcmail->output->parse('myplugin.compose', false, false));

Yes, I have a template file in plugins/myplugin/skins/larry/templates/compose.html. This is currently not possible because template with the same name exists in core skins/larry/templates folder. The core compose.html template content will be "overwritten" by plugin's template. rcmail_output_html class (and its parse() method, but maybe other too) should be aware of the context.

BTW, template_exists() has similar problem. Doesn't work with plugin templates.
BTW, there's still a reference to skins/default in parse() method.

Migrated-From: http://trac.roundcube.net/ticket/1488967

[rcubetrac]

Comment by @thomascube on 22 Feb 2013 18:29 UTC

Replying to alec:

The core compose.html template content will be "overwritten" by plugin's template. rcmail_output_html class (and its parse() method, but maybe other too) should be aware of the context.

Yes, context could be helpful here.

BTW, template_exists() has similar problem. Doesn't work with plugin templates.

Sure, because it uses the same search paths.

BTW, there's still a reference to skins/default in parse() method.

That's the fallback for old plugins which still have one default skin folder. The comments above the according line should explain that.

[rcubetrac]

Comment by @thomascube on 10 Apr 2013 21:42 UTC

Minor issue, rescheduling...

[rcubetrac]

Milestone changed by @thomascube on 10 Apr 2013 21:42 UTC

0.9-stable => 1.0-beta

[rcubetrac]

Milestone changed by @alecpl on 1 Dec 2013 10:02 UTC

1.0-beta => 1.0-stable

[rcubetrac]

Comment by @thomascube on 20 Jan 2014 11:29 UTC

The fact that default templates get overwritten by plugin templates with the same new seems more like a feature to me than a bug. It allows plugins replace the UI for a certain action pretty easily by still keeping the possibility of standard <roundcube:object > tags being handled.

[rcubetrac]

Comment by @alecpl on 20 Jan 2014 11:49 UTC

Not really. I'd say this is a confusing and incidental behaviour.

$output->parse('myplugin.compose');

I'd never read this code as "replace main template", more like "give me a content of the compose template from myplugin templates directory". For the feature you describe we should have something like:

$output->replace_template('compose', 'myplugin.compose');

[rcubetrac]

Comment by @thomascube on 3 Aug 2014 13:17 UTC

So the only solution to this would be to somehow pass the context to the $output->parse() call.. Otherwise we cannot determine whether the call comes from a plugin or from core. Or do you have a better solution?

[rcubetrac]

Comment by @alecpl on 5 Aug 2014 07:08 UTC

The context in parse() is already known. You have it as plugin prefix in template name. The problem is in skin_paths and base_path handling later. Which means all methods using these variables need to be made aware of the context. The fact that plugin templates can include global templates (e.g. <roundcube:include file="/includes/links.html" />) makes this even more complicated.

[rcubetrac]

Comment by @thomascube on 3 Nov 2014 15:20 UTC

Fix committed in 8d526c4.

The plugin skin directories are added to the search path if in plugin context and removed again after parsing of a plugin template has finished. Some in-depth testing is required. So far I couldn't find any issues with the committed changes.

[rcubetrac]

Status changed by @thomascube on 3 Nov 2014 15:20 UTC

new => closed