What is this feature about (expected vs actual behaviour)?

HtmlMin cut html code at the end of html page

How can I reproduce it?

Example page without use HtmlMin: https://sector.biz.ua/docs/tiworker_exe_bitcoin_miner_riched32_dll/page-no-htmlmin.phtml

Example page with HtmlMin: https://sector.biz.ua/docs/tiworker_exe_bitcoin_miner_riched32_dll/page-with-htmlmin.phtml

see difference in pagesources

Does it take minutes, hours or days to fix?

i don't know

Any additional information?

Before compression:

                        <span>foo</span>
                                                    <a href="bar">baz</a>
                                    <span>bat</span>

After compression:

<span>foo</span><a href=bar>baz</a><span>bat</span>

Notice that all whitespace has been removed, even though there was whitespace between <span> and <a> elements in the source. This is invalid because it changes the way content is displayed after compression.

What is this bug about (expected vs actual behaviour)?

expected: closing tag of a paragraph should still exist in HTML output after compressing:

actual: closing tag is removed after compression

How can I reproduce it?

use voku\helper\HtmlMin;

$html = "
<p>
    This is a simple test to show compressing paragraphs does not work.
    #compressing html
</p>
";
$htmlMin = new HtmlMin();
echo $htmlMin->minify($html);

output: <p> This is a simple test to show compressing paragraphs does not work. #compressing html

Does it take minutes, hours or days to fix?

not sure

Any additional information?

It also affects https://github.com/voku/html-compress-twig

What is this feature about (expected vs actual behaviour)?

Some closing tags are vanishing. In my example, the </p> is suddenly gone.

string(94) "<div class=rating><p style="margin: 0;"><span style="width: 100%;"></span>  (2 reviews) </div>"

How can I reproduce it?

$html = '
<div class="rating">
    <p style="margin: 0;">
        <span style="width: 100%;"></span>
    </p>

    (2 reviews)
</div>
';

$htmlMin = new voku\helper\HtmlMin();
$result = $htmlMin->minify($html);

var_dump($result);

Does it take minutes, hours or days to fix?

Dunno.

Any additional information?

Using voku/html-min 4.3.0 and voku/simple_html_dom 4.7.14.

Followup to discussion on #43

Proposed Changes

• Allow keeping of http/https prefix on href/non-rescource links.
• Add option to make all same-domain links relative.
• Add option to set domain manually

Notes

• makeSameDomainLinksRelative() disregards isKeepPrefixOnExternalAttributes(). This can be easily changed. The logic being that a library user choosing LinksRelative expects it to apply to both resources and links. Which is not the same expectation of choosing KeepPrefixOnExternal - which is to keep outgoing information intact.
• Setting domain manually allows running HtmlMin without strong coupling of HtmlMin and $_SERVER

This change is 

Hi, I made some changes and a fix to previous PR #44 in light of removal of $_SERVER usage.

Proposed Changes

• KeepPrefixOnExternal does not affect link tags' href attribute. The link tag is not an external link. It's a resource that must adhere to removePrefix.
• makeSameDomainLinksRelative() accepts $localDomain string as parameter
• Removed method setLocalDomain() - functionality merged into makeSameDomainLinksRelative()
• Removed unnecessary call to setLocalDomain() with empty parameter It is up to user to provide a valid localDomain string.

This change is 

On a legacy project, I'm facing issues with some client who (I don't really know how) has inserted base64 encoded images.

Further more, those images aren't optimized at all (uncompressed PNG for photos...), resulting in huge base64 strings (multiple images up to 2mo):

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA7EAAAJyCAYAAAFlL3dhAAAAAXNSR0IArs4c6QAAAARnQU1B....." />
<!-- base64 string is shortened for clarity 😅  -->

What is this feature about (expected vs actual behaviour)?

When minifying such HTML, I end up with an empty string because this replacement fails: https://github.com/voku/HtmlMin/blob/4f700584abd70b308b7d06b8e4cfcc31711faaf9/src/voku/helper/HtmlMin.php#L1375-L1381

Because it exceeds the pcre.backtrack-limit and returns a PREG_BACKTRACK_LIMIT_ERROR.

I'm fully aware this is all wrong: wrong image format for photo and more importantly, large images sources should be inserted as URLs.

However, technically speaking, all this crap is still valid HTML (the page displays when unminified) and I think such cases (even if it's kind of an edge case) should not fail.

Thus, I wonder if a sanity check should be inserted somewhere to prevent the script from failing and returning an empty string? Maybe catch errors on all preg_ calls and return the unminified HTML if an error occured? Or check the string length against the pcre.backtrack-limit value?

Wrapping preg_ calls the Guzzle json_decode way could be a nice solution (because it would not only handle backtrack-limit errors but all kinds of preg_ errors)? https://github.com/guzzle/guzzle/blob/74ca2cb463a7a99a0b99f195ca809cc4ba6c3147/src/Utils.php#L281-L301

try {
    $html = (string) Utils::preg_replace_callback(
        '#<([^/\s<>!]+)(?:\s+([^<>]*?)\s*|\s*)(/?)>#',
        static function ($matches) {
            return '<' . $matches[1] . \preg_replace('#([^\s=]+)(=([\'"]?)(.*?)\3)?(\s+|$)#su', ' $1$2', $matches[2]) . $matches[3] . '>';
        },
        $html
    );
} catch (\Exception $e) {
    return $html;
}

What do you think?

How can I reproduce it?

Try to minify some HTML with length that exceeds the pcre.backtrack-limit.

Does it take minutes, hours or days to fix?

I think a couple hours should be enough, I can submit a PR but would like your feedback on the different proposed solutions before working something out.

What is this feature about (expected vs actual behaviour)?

To use AMP properly, one has to use a specific html tag <html ⚡>

unfortunately HtmlMin removed the important bit, leaving only <html>

How can I reproduce it?

run the minifier over a sample document with the tag sahown above

Does it take minutes, hours or days to fix?

depending on the source of the problem and how much you are into your code: hours to days

Any additional information?

Fixes https://github.com/voku/HtmlMin/issues/84

This repo doesn't work in PHP 8, 8.1 or 8.2 due to the namespaces not being Capitalized.

• Have updated the namespaces.
• Have updated composer.json and removed php 7 as security updates ended in 28 November 2022.
• Have updated readme with new namespaces

Need to update the connecting repos now.

Linked to Pull Requests

https://github.com/voku/html-compress-twig/pull/5

https://github.com/voku/HtmlMin/pull/85

https://github.com/voku/simple_html_dom/pull/95

https://github.com/voku/simple-cache/pull/30

https://github.com/voku/portable-ascii/pull/87

Tested on the following

Tested on PHP 8.2 and Laravel 9.1

This change is 

Welcome to WhiteSource Bolt for GitHub! This is an onboarding PR to help you understand and configure settings before WhiteSource starts scanning your repository for security vulnerabilities.

:vertical_traffic_light: WhiteSource Bolt for GitHub will start scanning your repository only once you merge this Pull Request. To disable WhiteSource Bolt for GitHub, simply close this Pull Request.

What to Expect

This PR contains a '.whitesource' configuration file which can be customized to your needs. If no changes were applied to this file, WhiteSource Bolt for GitHub will use the default configuration.

Before merging this PR, Make sure the Issues tab is enabled. Once you merge this PR, WhiteSource Bolt for GitHub will scan your repository and create a GitHub Issue for every vulnerability detected in your repository.

If you do not want a GitHub Issue to be created for each detected vulnerability, you can edit the '.whitesource' file and set the 'minSeverityLevel' parameter to 'NONE'.

:question: Got questions? Check out WhiteSource Bolt for GitHub docs. If you need any further assistance then you can also request help here.

This change is