Draikin

Thanks for the help, I followed the steps you listed and made the pull request.

I’ll do that, thanks. I’ll look into making a pull request, but I must admit I haven’t worked with Github a lot and I messed up with the pull requests when I contributed to Jetpack some time ago.

You’re correct in that people won’t mind applying the filter to enable the creation of gzip files. To be honest I’m not sure how much of a speed boost and decrease in CPU usage this actually grants, but I don’t see a downside to enabling it if you’re already using Nginx gzip_static anyway.

On a side note, did you never run into problems serving Gzip content from PHP in combination with Nginx? I had some weird issues with both WP Super Cache en CacheEnabler in that scenario. Nginx would appear to gzip the content again, causing decoding errors in the browser, even if gzip was disabled altogether in Nginx.

Thanks for the help! I haven’t done a lot of WordPress development, so bear with me ?? This seems to be working:

} else {
			// Write code to cache without doing anything else
			file_put_contents($this->cachedir.$this->filename,$code, LOCK_EX);
			if (apply_filters('autoptimize_cache_create_gzip',true)) {
				// Create an additional cached gzip file
				file_put_contents($this->cachedir.$this->filename.'.gzip',gzencode($code,9,FORCE_GZIP), LOCK_EX);
			}
		}

Is this what you had in mind when you said “behind a filter”? Contrary to what I posted above, I’m guessing you’d want this to be disabled by default? Or would this be worth adding an option in the Autoptimize menu for?

The Nginx config you’re using does indeed work, as it doesn’t get into the situation where PHP processing takes place with the gzip file already cached on the disk. I understand that it’s being compressed twice, but I’m just curious about what’s causing this, since it happens even with gzip being disabled entirely in Nginx. So in that regard, it would be nice to have the option to prevent Cache Enabler from sending gzip content to Nginx, without disabling the creation of .gzip files. But admittedly, this only happens in the configuration I posted above.

I didn’t resolve the previous problem, I’m just testing this from the copy of the website where I did get Cache Enabler to work. I may go back and try to fix it on the live website, but that will prove to be difficult when I can’t replicate the problem on the copy of the website.

I could be wrong, but I haven’t seen Cache Enabler alert the user to potential problems related to permissions? Something that the other caching plugins I used typically point out in their settings. Something like that would prove to be helpful. WP Super Cache also has the option to log various events in a debug log. That really helps to figure out what the plugin is doing and where it fails.

I made a new thread for the Nginx + gzip issue.

My previous example was overly complicated, this probably illustrates the problem better:

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

This, combined with “Pre-compression of cached pages.” in Cache Enabler will give a content decoding error (but only from the second time the page is loaded, the first time the page still displays correctly). Surprisingly, this happens even when I disable gzip in Nginx altogether. For example, Here are the headers for the first two requests on the same page in WordPress:

1st Page Load (this one displays correctly)

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Wed, 18 May 2016 19:35:57 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive

2nd Page Load (ERR_CONTENT_DECODING_FAILED in Chrome)

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Wed, 18 May 2016 19:35:59 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Cache-Handler: php
Content-Encoding: gzip

Perhaps I’m seeing the same thing described here: https://www.ads-software.com/support/topic/difficult-problem-with-double-content-encoding-gzip-content-encoding-gzip?replies=2

Is there a way to tell Cache Enabler to only create the .gz file, but not actually send gzipped content to Nginx?

@keycdn The .gz file is generated correctly (I can retrieve the HTML file from it manually). I got it to work, but perhaps someone can explain to me why the following error happens. Let’s say I have this in my Nginx config:

location / {
try_files /wp-content/cache/cache-enabler/${http_host}${cache_uri}index.html $uri $uri/ /index.php$is_args$args;
}

Now, this works. After the page is loaded for the first time and Cache Enabler creates the index.html and index.html.gz files, Nginx will retrieve the .gz file on the second try. But if I break the config by making it so that Nginx doesn’t find the cached file:

location / {
try_files /wp-content/cache/cache-enabler/${http_host}${cache_uri}index2.html $uri $uri/ /index.php$is_args$args;
}

This will produce a content decoding error in Chrome on the second try. But I don’t entirely understand what happens that causes the error. Since it doesn’t find index2.html, I imagine Cache Enabler will try to serve the file via PHP. But is it somehow gzipped twice in the process (once via PHP, and then again by Nginx)?

I made a completely separate test version based on a backup from the website, and there I can get Cache Enabler to work (also with Autoptimize), on my standard theme (child theme for Twenty Twelve). Which is actually annoying since I’m still not sure what’s causing the problem on the live website, and I can’t really afford to test it thoroughly there, so I might have to stick with WP Super Cache.

The main reason I actually wanted to try Cache Enabler is to see if I could pre-compression to work, and unfortunately I’m encountering the same problem there as with WP Super Cache. Enabling it on the test website also causes content decoding errors in the browser, despite the fact that I set “gzip_static on” in the nginx config file. I’m guessing it must be related to my Nginx config file somehow.

I tried using the TwentyTwelve theme, but I’m encountering the same problem. But I did notice that the first page load appears to work. The second one just gives me a white screen. In the error log, I’m now noticing a different PHP warning: it’s failing with ” No such file or directory” on /wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 212, which tries to read the cached file from the disk.

The only problem is, there’s no cached file. There’s not even a /wp-content/cache/cache-enabler/ directory. I’m not sure why, as it should have enough rights to write to that folder. Both WP Super Cache and Autoptimize can write to the cache directory, after all. And it’s the only error I’m seeing, I would expect some error related to writing the file prior to failing to retrieve it. So it’s like it’s not even trying to create the cached version.

@frank: I think the Nginx log is where the PHP errors are logged? The error I’m getting is in the first post, usually you get a more detailed error (which PH file and line number) but this isn’t giving me any more details. I’m using PHP 7.0 by the way.

PHP memory limit: I tried setting it to 64MB since that’s indeed often associated with this problem, but it didn’t make a difference.

Switching themes: I can’t easily test that at the moment, but I’ll look into that.

Thanks for the help so far!

Cache Minification is indeed disabled. Given that disabling all other plugins doesn’t resolve the issue, I’m assuming Autoptimize has nothing to do with this. The thing is that the error message doesn’t really tell me anything about where it’s failing, and the WordPress debug log doesn’t seem to offer any information either.

I gave up and installed the SSH SFTP Updater Support plugin. It instantly resolved the problem. I’m a bit wary of using too many plugins in WordPress, but in this case it really helped me out.

I’ve narrowed down the problem to this function in class-wp-filesystem-ssh2.php:

public function exists($file) {
return file_exists( $this->sftp_path( $file ) );
}

This returns false. PHPinfo() tells me that SHH2 is enabled:

SSH2 support enabled
extension version 0.12+dev
libssh2 version 1.5.0
banner SSH-2.0-libssh2_1.5.0

I’m not sure how to proceed. I’m not sure if this is relevant (“file_exists function no longer reports true when using an ssh2_sftp resource handle.”):

https://bugs.php.net/bug.php?id=71047&edit=3

But even forcing returns true gets me another error further down the line (” Could not fully remove the plugin…”), and none of the plugin’s files are deleted. Setting a temporary chmod 777 on the plugin folder doesn’t resolve the problem either.

Sorry, hadn’t gotten around to replying earlier. The font fallback seems like the ideal solution, but would there be a way (using a filter probably) to only load it when Youtube Lyte is actually being used on the page in question?

Concerning lyte on mobile, I wasn’t aware you needed to click twice there. I’d need to look into that, but in that case I think (2) would probably be the best option. Otherwise it’d confuse people who’re used to the regular Youtube embedded videos.

I’ll give the beta a try.

I’ll send you an e-mail. The preview looks good, a couple of minor things I noticed:

• About the bottom elements: personally I’d have those disabled by default since it no longer seems possible to display those on the preview. So this kind of betrays the fact that it’s a custom solution. That said it’s not a problem for me since I can just hide it using CSS.
• The font of the title is also different (in fact it seems to fall back to Arial in Firefox here), Google is using Roboto but that’s of course a Google font. So using @font-face would mean potentially slowing down load time and that’s something that Youtube Lyte probably wants to avoid. I’m not sure if there’s a perfect solution here. Personally I’d probably want to load the font to try and get a near-identical presentation but that’s just me.
• Another minor thing is that the timeline on the Youtube player still has some space between the left and right side. At the moment it runs across the entire width on your example.