Bug Report: External CSS URLs Processed As Local Files During CSS Compression - Question | JoomShaper

Celebrate JoomShaper's Sweet 16 with Flat 35% OFF!

Bug Report: External CSS URLs Processed As Local Files During CSS Compression

T

Torsten.S

Helix Framework 6 days ago

Environment Joomla: 6.1.1 Helix Ultimate Plugin: 2.2.6 Template Version: 5.0 PHP: 8.x Apache with open_basedir enabled

Description

Helix Ultimate's CSS compression routine incorrectly processes external CSS URLs as local filesystem paths.

When a stylesheet URL such as:

https://fonts.googleapis.com/css?family=Roboto&display=swap

is present in $this->doc->_styleSheets, the code attempts to convert it into a local file path and later calls file_exists() on the resulting string.

This produces paths similar to:

/path/to/web/root/webfonts.googleapis.com/css?family=Roboto&display=swap

which are invalid filesystem paths.

On servers with open_basedir enabled, this generates PHP warnings.

Error Log

PHP Warning:

file_exists(): open_basedir restriction in effect. File(/path/to/web/root/webfonts.googleapis.com/css?family=Roboto...) is not within the allowed path(s)

Origin:

plugins/system/helixultimate/src/Core/HelixUltimate.php

Line:

1812

Relevant Code

Current code:

$css_file = str_replace($root_url, \JPATH_ROOT, $key);

if (strpos($css_file, \JPATH_ROOT) === false) { $css_file = \JPATH_ROOT . $key; }

if (\file_exists($css_file)) { ... }

If $key contains an absolute external URL, the code generates an invalid local path before reaching file_exists().

Expected Behavior

External URLs should be skipped before any filesystem operations are performed.

Example:

if (preg_match('#^https?://#i', $key)) { continue; }

or alternatively:

if (filter_var($key, FILTER_VALIDATE_URL)) { continue; } Temporary Workaround

The issue can be avoided by adding:

if (preg_match('#^https?://#i', $key)) { continue; }

immediately before:

if (\file_exists($css_file))

This prevents Helix Ultimate from attempting filesystem operations on remote URLs.

Notes

The issue was reproducible even after Google Fonts had been disabled in the template settings, indicating that external stylesheet URLs may still be present in the document stylesheet collection from other sources, extensions, cached assets, or previously generated output.

The bug is therefore not limited to Google Fonts and can affect any externally loaded CSS resource.

0
1 Answers
Rashida Rahman
Rashida Rahman
Accepted Answer
Support Agent 6 days ago #226094

Hi,

Thank you for the detailed report and for providing the environment information, error log, code references, and workaround.

The behavior you described under open_basedir restrictions makes sense, and the suggested safeguard of skipping absolute URLs before filesystem validation seems like a reasonable approach.

I have forwarded the details to our development team for further review and verification. Thank you as well for noting that the issue is not limited to Google Fonts and may affect any externally loaded CSS resource, as that information will help during testing.

We appreciate the thorough investigation and the temporary workaround you shared.

Best regards,

Rashida

0