Tim Eckel

Oh, and consider turning on the following Minify HTML options:

Remove XHTML closing tags from HTML5 void elements
Remove relative domain from internal URLs
Remove schemes (HTTP: and HTTPS:) from all URLs

This will save far more than the 2 enters due to the inline JavaScript.

Tim

That’s not an error, it’s doing that on purpose.

For inline JavaScript it minifies it, but does leave some returns to avoid certain problems and keep the speed fast. As most sites contain little to no inline JavaScript, this is a minor issue. It’s not something that will be “fixed” as fixing it can cause isolated issues (or significantly slower speed).

In any case, it’s working properly and what you are seeing is correct.

Tim

Fixed in version 2.0.

Closed due to age.

Closed unless I see the example in question.

Suggestion given on how to correctly disable features without disabling wp_head and wp_footer, which is a terrible idea.

v1.95 is ready to go. Let me know if it works.

That sounds like a character set (charset) issue. Looking at your site (and duplicating the html locally) I can reproduce what you’re seeing.

I believe I have it sorted out. It has to do with non-English characters being multi-byte.

I’ll be releasing v1.95 tonight. If you could try it out and let me know if it’s working that would be great.

Tim

Minify HTML is also designed to be fast and use little server resources. Not sure where the 233 bytes in savings would come from, but my guess would be from JavaScript minification. Which I would speculate is specific to your website that has lots of inline it on page JavaScript instead of proper JS in files.

Basically, I’d really doubt there’s much of a real-world difference. Also, you should be using grip compression as well so that 223 bytes is probably more like 60, in other words insignificant once server overhead is considered.

Tim

Why are you asking for a feature when you can’t get the plugin working at all? Very confused. Basically, if you got the plugin working, you would realize that you don’t need this “feature” as there’s no need for admins to see non-minified markup as developers use browser developer tools, not view source. Also, the plugin already doesn’t minify for admin view. You’re putting your cart before the horse.

• This reply was modified 8 years, 1 month ago by Tim Eckel.

Yup, that would be a way of doing it, I just don’t see the need. When using developer tools, minification doesn’t matter anyway, so I see no point in making this an option when it doesn’t make a bit of difference when looking at your site markup in the developer tools console.

I would suggest you figure out why it’s NOT working for you before you ask for a new feature that would make zero difference at this point to you.

And by the way, Minify HTML already doesn’t minify if admin, see one of the first lines of the source:

if ( !is_admin() ) add_action( ‘init’, ‘teckel_init_minify_html’, 1 );

Basically, you can’t even build a theme that works and you’re asking for features that already exist.

Nope, doesn’t need either of those. Also, you can just disable the junk without totally disabling wp_head and wp_footer. For example, using the following in functions.php:

remove_action( ‘admin_print_styles’, ‘print_emoji_styles’ );
remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 );
remove_action( ‘admin_print_scripts’, ‘print_emoji_detection_script’ );
remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ );
remove_filter( ‘wp_mail’, ‘wp_staticize_emoji_for_email’ );
remove_filter( ‘the_content_feed’, ‘wp_staticize_emoji’ );
remove_filter( ‘comment_text_rss’, ‘wp_staticize_emoji’ );
remove_action(‘wp_head’, ‘wp_generator’);
remove_action(‘wp_head’, ‘wp_shortlink_wp_head’);
remove_action( ‘wp_head’, ‘feed_links_extra’, 3 );
remove_action( ‘wp_head’, ‘rsd_link’ );
remove_action( ‘wp_head’, ‘wlwmanifest_link’ );

Anyway, none of this has anything to do with Minify HTML working or not. It runs at the lowest level (on the init action). I’ve never seen a theme that messes with the init level (nor should it). The plugin-in is fairly straight-forward. Runs on init as long as not is_admin() and minify is turned on.

Tim

• This reply was modified 8 years, 1 month ago by Tim Eckel.

It’s not that I’m not listening, it’s that not minifying for logged in users would make all content non-minified for sites where most users are logged in. Also, I thought it wasn’t minifying at all for you? But now it’s minifying too much? Which is it? Finally, this is a free plugin, with no money compensation. I programmed it and released it for free. There are no “customers” to listen to. If this was a paid plugin, and you paid, then you would be a customer. As it is now, you should be thankful for getting something for free. But, if you’d like to go to a paid model, I’m willing to add this feature for paying customers. But seriously, you’re being unreasonable and offensive to my hard work I’ve given you for free.

• This reply was modified 8 years, 1 month ago by Tim Eckel.
• This reply was modified 8 years, 1 month ago by Tim Eckel.
• This reply was modified 8 years, 1 month ago by Tim Eckel.
• This reply was modified 8 years, 1 month ago by Tim Eckel.

Yup, works perfectly with the latest release of WordPress. Running 4.7.2 on this site for example: https://www.renegadelife.org/ (notice the source is minified). Are you sure you activated the plugin and look in Settings->Minify HTML to be sure it’s Enabled.

It’s possible that you’re using some non-standard theme that would prohibit the use of Minify HTML, but any properly designed theme shouldn’t cause a problem.

I’ll need more details on exactly what website, theme, etc. you are running if you still can’t get it working. Basically, I’ll need to duplicate what you’re using on my end.

Version 1.94 is released which now allows you to turn off JavaScript minify which will resolve your problem. There’s a new option labeled “Minify inline JavaScript” from the Settings->Minify HTML menu.