template compiling problem for 'non-local' templates

[craigh]

I am working (with Jusuff) on scribite right now. As a hook-based module it needs to pull in templates that are not 'local' in the sense that they are not from the current top-level module. In order to do so, I've used the advanced functionality of Smarty and used template locations like this:

return $this->view->fetch("file:modules/Scribite/plugins/$editor/templates/editorheader.tpl");

see http://www.smarty.net/docsv2/en/template.resources.tpl#templates.from.any.dir

so this works fine* on linux/bsd based systems but completely fails in windows. Jusuff is the one to discover the problem with windows. The problem comes when the template is compiled and the location isn't correctly set. Then it cannot be rendered properly when sending to the browser. Jusuff was

*while it 'works' on my BSD (macos) machine, it does produce an odd structure. See the picture below where the "file/modules" has created a directory with a slash in the name somehow.

@jusuff @matheo

[craigh]

I also thought about setting the template location/path from within scribite Zikula_View does not have a method for doing so (manual override so to speak). I have also tried multiple other pathnames to get the template available but nothing works. only file:path/to/template.tpl works, but not on windows.

[ghost]

Shouldn't you be using Zikula_View_Plugin and specifying paths just as you would in a module?

[craigh]

I'm investigating that now. It is being used from with the HookHandler though...

[ghost]

Shouldnt matter. Use Zikula_View_Plugin::getPluginInstance($moduleName, $pluginName)

[craigh]

this works:

    $view = Zikula_View_Plugin::getPluginInstance("Scribite", $editor, Zikula_View::CACHE_DISABLED);
    return $view->fetch("editorheader.tpl");

and creates the following compile directories:

however, the compiling of non-local templates is still a problem. according to @Drak, Zikula does not support this because of problems with the vendor's handling of filenames/paths (Smarty) and therefore "there should be another way". I'm leaving this ticket open for now hoping that @matheo or @jusuff will have some thoughts on the matter....

[ghost]

Unless there is a strong use-case for having to support file: at all, I see no reason to waste time on this issue - given this has not come up before, I'm -1 on even trying to support it.

[craigh]

in Content:
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L348
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L350
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L363
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L364
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L369
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/AbstractContentType.php#L375
https://github.com/zikula-modules/Content/blob/master/src/modules/Content/lib/Content/Form/Handler/Admin/EditContent.php#L90

in Tag:
https://github.com/craigh/Tag/blob/master/src/modules/Tag/templates/plugins/function.displaytags.php#L37

I'm not saying these instances make a case for the functionality, but it is in use in the wild. I doubt anyone is using the Tag plugin, but Content is definitely in use. @espaan

[ghost]

Even so, it's clear that windows is not a production target otherwise there would have been many bug reports about this.

[espaan]

As long as it works on linux it's fine for production environments, but for local testing this would be not convenient to say the least.

Within Content it might be that this was coded at some stage, since in earlier days I cannot remember that there was something like that in the code :-) I also don't know how to solve it actually.

In Content before upgrading to OO as it is now the getXtemplates function was not there afais in the code. This was just hard coded in the template for the calling module.

[ghost]

What are the paths Content is trying to map with this notation?

[craigh]

I'm not sure I understand @Drak 's question.

for certain, I am the one that coded these methods when I refactored Content (v4.0.0). The problem as I recall, was that the template can come from anywhere (ContentTypes are in many different modules) and so I needed a way to get them from the document root. Or something like that. It's been a while since I did that and I don't remember exactly.

Content does things a bit wacky and there are multiple instances of Zikula_(Form_)View passing around making things even more complicated and memory intensive. I remember having to create and destroy instances of View to get the job done.

[espaan]

True, the view instances had to be destroyed in some places, I can also remember that.

I have not dived into those methods to be honest (should have done that probably back then ...), but they worked.
In the end they might not be necessary, but it had to do with the contenttypes and layouttypes that can be in any other
module and location indeed. Maybe in future this could be re-coded to other ways, especially since system/module plugins can now also have templates etc (or was that not a ticket also that was solved?).

[mazdev]

// Get the full path of the template.tpl template

$smarty->assign('one_var', dirname(FILE).'/template.tpl');
return $this->display(FILE, $this->name.'.tpl');

And the following code:
{include file=$one_var}

or something different like: (I don't know how to put this in php)

if substr( $string_n, 0, 7 ) === "file:///"

$filename = filename:

[damon18]

zikula-modules/Content#135

[espaan]

I just tried this in Zikula Core 1.3.4 build 35 and current github version of Content and News and there also the template is not found. So on Win xampp platform the template ath with file: resource and absolute paths don't work.
You get

WARN (4): E_USER_WARNING: Smarty error: unable to read resource: 
"http://localhost/zk134b35/file:C:\Apps\xampp182\htdocs\zk134b35/modules/News/templates/contenttype/newsarticles_edit.tpl" 
in C:\Apps\xampp182\htdocs\zk134b35\lib\vendor\Smarty\Smarty.class.php line 109

[espaan]

I now notice that going back to DataUtil of Zikula Core 1.3.4 build12 does work with on Windows systems. Apparantly the creating of the compiled version of the template uses FormatForOS, since that is the only difference I could find between 134 and 138 in this problem scope.

It's not an issue in production, but for testing it makes it so much easier when this works again. for instance for Content as it is now.

What does make it work is changing back again in DataUtil line 413:

            $dirty_array = preg_split('#[/\\\\]#', $var, -1, PREG_SPLIT_NO_EMPTY);

into

            $dirty_array = preg_split('#[:/\\\\]#', $var, -1, PREG_SPLIT_NO_EMPTY);

not sure why the : was excluded from the pregsplit.

The update was done here:
9e74470

[craigh]

thank you @cmfcmf Christian for fixing this elusive problem!

[espaan]

👍