Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FileLoader::normalizePath doesn't take into consideration phar:// at the beginning of the path #378

Closed
Marian-Kechlibar opened this issue Oct 1, 2024 · 4 comments

Comments

@Marian-Kechlibar
Copy link

Marian-Kechlibar commented Oct 1, 2024

Version: 3.0.18

Bug Description

The internal method of the class FileLoader

protected static function normalizePath(string $path): string

converts all forward slashes in the supplied path to backslashes on Windows before returning:

return implode(DIRECTORY_SEPARATOR, $res);

This is correct for normal canonical paths to files, but doesn't work in the very specific case of files loaded from a PHAR archive.

Their path starts with phar://, such as:

'phar://C:/xampp/htdocs/kraken-control-tester/kraken-control.phar/app/Module/Basic/Presenters/templates/...'

and the method normalizePath will convert this blindly into:

'phar:\\C:\xampp\htdocs\kraken-control-tester\kraken-control.phar\app\Module\Basic\Presenters\templates\....'

Due to this blind conversion, rendering of Latte templates loaded from PHARs on Windows breaks down.

A one-line solution is to convert the :\\ back to correct value:

$res_str = implode(DIRECTORY_SEPARATOR, $res);
return (str_starts_with($res_str, 'phar:') ? str_replace(":\\\\","://", $res_str) : $res_str);

Once this is done, even complicated templates from PHARs are rendering just fine.

I will try to create the appropriate Pull Request.

@dg
Copy link
Member

dg commented Oct 4, 2024

Can you post a minimal code sample here when the problem occurs?

@Marian-Kechlibar
Copy link
Author

Marian-Kechlibar commented Oct 4, 2024

For what purpose? A unit test to prevent relapse? Or is there any doubt whether the problem is real?

My smallest PHAR contains some 960 files and is full of IP that I cannot share, so I cannot provide it... I suspect I could construct a smaller case, if absolutely necessary (short on time...)

But the problem definitely happens and I had to apply that fix all around me. Basically, once you have a hierarchy of lattes where you derive anything from a layout, includes will start with phar:// internally (while rendering) and the normalizePath method will break them. On Windows only. On Linux, as the DIRECTORY_SEPARATOR is equal to /, the problem is trivially avoided.

@Marian-Kechlibar
Copy link
Author

screenshot_bad_latte_address

This is how it looks like once I revert my change.

@dg
Copy link
Member

dg commented Oct 4, 2024

I'm sorry, but the "short of time" thing offends me. You think I don't have better things to do than work on solving your problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants