Closed CarstenMeiselbach closed 7 years ago
@CarstenMeiselbach This sounds like an issue with the Apache PHP handler; are you running as FastCGI? Also, can you tell me which version of Comet Cache, Apache, and WordPress you're testing with? Also can you tell me if you tried testing this in a clean WordPress installation?
Hello "Raam Dev",
thanks for your reply.
Testing done within Managed Server host at my provider and also locally. Locally this problem didn't occur. Local test was done with same Apache, PHP, Wordpress & Plugins versions. But maybe since I'm using a Bitnami Wordpress Package, packages made available against the ones from my (problematic) hosting are too different..
Comet Cache Pro runs fine with PHP 5.6.12 (current used Version on managed host), with PHP 7.0.6 it fails. I've tried to disable several Plugins that might also interfere without any positive results. I didn't tried a clean Wordpress installation, didn't had the time yet, but I try to push this..
Kind regeards
Hi again,
I've done an clean Wordpress installation test. Apache 2.4, PHP 7.0.6, Wordpress 4.6.1, Comet Cache Pro v160917, Theme "Twenty Fifteen" and no further Plugins. => same >negative< result. If I'm enabling HTML Compression Feature, "End of script output before headers" appear as named.
PHP Info that might help: http://bettinameiselbach.de/wordpress/phpinfo.php
Comet Cache Pro Settings: http://bettinameiselbach.de/wordpress/comet_cache-options.json
Please note: you need to clear the Cache for your testing. An already cached page won't through that error, the page needs to being created for the cache including HTML Compression settings.
Any further ideas?
Kind regards, Carsten
@CarstenMeiselbach Thank you very much for the additional details. We'll try to reproduce this and see if we can figure out what's going on.
@raamdev
Tested on clean installation, WordPress 4.6.1 running Twenty Sixteen theme (Apache 2.4, PHP 7.0.1 + Comet Cache Pro v160917). Was unable to reproduce any error after enabling all HTML Compression settings.
Means: my PHP Settings needs some adjustment to be run with Comet Cache Pro?
@CarstenMeiselbach I also tried to reproduce this and I was unable to find any problem with PHP 7 + Apache 2.4 + Comet Cache Pro HTML Compressor. It still sounds to me like there might be an issue with the Apache PHP handler, perhaps an issue with a specific version you're running.
If you're using a web hosting company, I suggest contacting them to inquire, otherwise if you're setting this up your own you might try searching Google for others who have had this issue with PHP 7; it appears there are several reports.
If there's something that Comet Cache is doing to cause this behavior, we'd love some additional details so that we can take a closer look.
Hi! I've done some additional testing. What I've found out now is that not all HTML Compression settings are going to fail, only the ones for combining CSS or JS files into fewer files are problematic. With the following settings, my system works with PHP 7:
Please note: Theme "Twenty Fifteen" doesn't make use of external CSS / JS resources..
But overall I'm still curious because I want to use that feature again. Do you have any idea what this feature failes?
Please note: I tried a couple of PHP Module settings without any effect. Overall it seems to be a problem with one of the modules I'm using, but I don't have a clue which one. Checking Google entries didn't helped too, I tried this already. Also file access setting for "755" are already done, not my problem..
Kind regards.
Additional note: I tried another Plugin "WP Minify Fix" (and some others) for CSS / JS / HTML compression and combine-jobs. It runs fine! So in the end it's really an issue with Comet Cache Pro.
When you're doing your tests make 100% sure ... ... not to test with the Browser which is logged in. In this case, HTML Compression are not running. Use a different Browser which hasn't a Wordpress Login Session Cookie present for your Frontend-Test. ... always test with a Cache clear in advance. The page requested must being fetched fresh.
@CarstenMeiselbach Thanks for the additional info. We still haven't been able to reproduce this issue on any of our PHP 7 test sites and we need to reproduce the issue to debug it.
@jaswsinc Any ideas on this one?
@CarstenMeiselbach writes...
I'm gettting following Server error (found within Apache Error Log) within my PHP 7.06 (Stable Release):
"End of script output before headers".
If I understand correctly, it's this error we are chasing down.
If so, that particular error message comes from Apache whenever a script dies for almost any reason. The error itself doesn't point to Comet Cache specifically, nor does it show which file the error was triggered in, or on which line of code that it was triggered.
So it sounds like the debugging on your end so far has consisted of trial and error with various plugin combinations and configuration changes. The next step would be to narrow this down by looking at the underlying PHP error log and not just the Apache error log.
Comet Cache being active might appear to be the problem on the surface, but in a platform like WordPress where you have multiple codebases being merged together at runtime, having one plugin active when problems occur doesn't necessarily mean it's that plugin that contains a bug. It could just be that having a certain plugin active together with others creates an internal conflict between the two in certain scenarios.
So looking at the PHP error log would help. You should find errors that reference specific lines of code. If you can post excerpts from your PHP error log we can help you make sense of those. If it is Comet Cache at fault, your PHP error log should show this. Or, if it's an error being triggered in another plugin, that only occurs when Comet Cache is active, it will show you that too.
See also: https://codex.wordpress.org/Debugging_in_WordPress
define('WP_DEBUG', true);
Hello "Jaswsinc", sure, I'm a Software Developer myself, I know about this type of error, hard to fix.
My debugging was done within a fresh Wordpress installation with Comet Cache Pro as the only Plugin. Done within the same Hosting Environment than my running Website. Apache 2.4, PHP 7.0.6, Wordpress 4.6.1, Comet Cache Pro v160917, Theme "Twenty Fifteen" and no further Plugins.
PHP Errors itself didn't occur, Error Logging and Display Output are enabled, WP_Debug setting active. Only error that could made visible is found within Apache Log.
For your reference: Test Website (generating HTTP 500): http://bettinameiselbach.de/wordpress/ PHP Info: http://bettinameiselbach.de/wordpress/phpinfo.php
And that's my plugin. Since no further error info is thrown, it's hard to debug. I'm sure it's a problem with one of my PHP settings. I've attached my current settings, maybe that helped.
I appreciate your feedback. Big thanks for that and also for this great plugin!
Now it's about 10 days ago since my last questions / feedback. Any futher ideas and notes from your side concerning my problem?
@CarstenMeiselbach As far as we can see, this is not a Comet Cache issue but an issue with either your PHP configuration or your Apache configuration. We haven't been able to reproduce this issue at all, so it's difficult to offer any specific advice.
Note that our resources are limited and we're not able to provide support for issues with your server configuration (see our support policy).
Jason is currently on vacation, but when he gets back I'm sure he'll follow up here with any other ideas he might have.
Hello,
if I'm going to enable all HTML Compression features, I'm gettting following Server error (found within Apache Error Log) within my PHP 7.06 (Stable Release):
"End of script output before headers".
If I'm going to disable the HTML Compression feature, Caching works fine.
Please note: I'm currently doing a switch from PHP 5 to PHP 7. My first guess concerning the "End of script output before headers" errors were related to Security Issue or just PHP Syntax etc. errors. Everything works fine except for your HTML Compression feature. I tried to find another Plugin that might produce this issue, but form everything I've testet I can tell, that this seeems to be the source. I dont' have another Error log etc. to be naming here.
Any ideas?
Kind regards,
Carsten