frkly
Forum Replies Created
-
Thank you, Tim, for your response.
Currently, the plugin’s settings page describes this option as “This option is typically safe to set to ‘Yes’.” However, if this option is incompatible with OGP tags (used by Jetpack, Yoast, All In One SEO, Rank Math, and many other SEO plugins and themes) and can cause critical errors, it is a potential issue for users who are unaware of this limitation. To address this, you could either:
- Improve the plugin’s behavior to ensure safer operation, or
- Clearly state on the settings page that “This feature is incompatible with many SEO plugins/themes or OGP tags and may cause critical errors.”
Regarding the concern about the complexity of applying relative URL conversion only within specific tags, I believe it might be relatively straightforward to limit the conversion to specific attribute values (
href,src,srcset,action,value). For example, the following code could be a possible implementation:if ( $minify_html_relative == 'yes' && isset( $_SERVER['HTTP_HOST'] ) ) {
$host = sanitize_text_field( wp_unslash( $_SERVER['HTTP_HOST'] ) );
$buffer = preg_replace_callback(
'/(href|src|srcset|action|value)=(["\'])(.*?)\2'.$mod,
function($matches) use($host) {
return str_replace( array ( 'https://' . $host . '/', 'http://' . $host . '/', '//' . $host . '/' ), array( '/', '/', '/' ), $matches[0] );
}
, $buffer
);
}While this is just one approach, it seems like a relatively simple way to limit relative URL conversion to specific attributes, maintaining the existing functionality while improving safety.
Since the primary goal of Minify HTML is to reduce file size without altering the core functionality of the HTML, limiting relative URL conversion to non-critical parts of the HTML (i.e., parts that do not cause fatal issues) aligns better with what users are likely to expect from this plugin. On the other hand, applying relative URL conversion indiscriminately, even to parts that could lead to critical problems, is probably not the behavior most users would anticipate or desire from this plugin.
Additionally, I tested the performance of this regular expression replacement on a 680 KB HTML page in my environment, and the processing cost was only 0.0017 seconds. This demonstrates that the impact on performance is negligible, even for relatively large files.
I hope this solution can serve as a starting point for consideration.
Thank you for your support. The issue I raised was submitted last month as GitHub PR #1074 by someone else. Considering this, I agree that this thread can be treated as resolved.