Sitelet https://github.com/feulf/raintpl3/issues/155
Skip to content

issue with checkTemplate and sub-includes #155

Description

@thedavidscherer

I'm not sure how localized this is, but I was running into an issue where a template in a sub-directory including another template from another sub-directory (both share the same parent directory) was causing the calling template's sub-directory to be appended to the base-path before the file_exists check.

Example:

Directory Structure:

./view
../handlebars
.../handlebarsTemplate.tpl

../modals
.../modal.tpl

../pdf
.../pdf.tpl

../widgets
.../widget.tpl

../file1.tpl
../file2.tpl
../etc....tpl

Let's say file1.tpl includes ./view/modals/modal.tpl and modal.tpl includes the handlebarsTemplate.tpl.

When Rain::checkTemplate runs for handlebarsTemplate.tpl the value passed is modals\handlebarsTemplate.tpl

And then the following code runs (..\Rain\Tpl.php:227-232):

// set filename
$templateName = basename($template);
$templateBasedir = strpos($template, DIRECTORY_SEPARATOR) ? dirname($template) . DIRECTORY_SEPARATOR : null;
$templateDirectory = null;
$templateFilepath = null;
$parsedTemplateFilepath = null;

The culprit here seems to be the ternary on Line 229 $templateBasedir = strpos($template, DIRECTORY_SEPARATOR) ? dirname($template) . DIRECTORY_SEPARATOR : null; which, when used in the foreach which immediately follows, causes some templates not to be found because it's checking for the included file in a sub-directory having the name of the including file's parent directory inside of the included file's sub-directory.

From what I could tell, the following 2 lines can be removed from ..\Rain\Tpl.php with no adverse affects:

Line: 229

$templateBasedir = strpos($template, DIRECTORY_SEPARATOR) ? dirname($template) . DIRECTORY_SEPARATOR : null;

Line 242:

$templateDirectory .= $templateBasedir;

My local copy is working fine without this currently, I would contribute a pull request, but I'm not certain I'm not just doing something wrong, or that the changes won't have unintended effects elsewhere in other use cases/situations.

At the very least, commenting out line 242 fixes my current issue.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions