Multiple issues with PHP that works as CGI

[GoogleCodeExporter]

WebOpt can't be installed.
Settings can't be save.
Root and current directories has incrorrect values.
Bitrix doesn't work.
...

Sorry, but I have no time to describe all problems. Just test WebOptimizer
on Bitrix (last version) with PHP (as CGI).

Original issue reported on code.google.com by levin.se...@gmail.com on 7 Jul 2009 at 7:23

[GoogleCodeExporter]

Please re-check root and current directories in config file. Sometimes it's 
impossible 
(or almost impossible) to calculate paths automatically -- so you need to set 
them 
manually.

Please confirm that 'handy' installation with all correct paths doesn't work. 
If so 
please provide any information that may help to resolve this problem...

Original comment by sunny.dr...@gmail.com on 7 Jul 2009 at 9:01

• Added labels: Component-Logic, Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Sunny, with my 0.5.3.5 installation everything worked fine. All preferences 
were saved.

I had some issues on a German 1&1 shared host. Main issue:

Cache:
* CSS gzip was created in wbo/cache but wasn't delivered
** Nothing was added to the .htaccess file and I did not add the rewrite rules 
for
static .gz files manually. This is *no* wbo issue as I believe that the Apache 
is a
pretty old patched 1.3 without the necessary modules.
* HTML gzip files were not created. HTML files were cached but not gzipped.
** The cache purging worked fine but I want compressed output and this 
definitely did
not work.

Gzip is working: I switched back to Textpattern full page cache plug-in 
asy_jpcache
which creates .gz files and complete etag cache headers.

I will switch to wbo and the HTML full page cache immediately because of the 
working
cache purging mechanism when the HTML gzip is working :)

The Textpattern diagnosis (extract):

Textpattern-Version: 4.0.8 (r3085)
(...)
PHP-Version: 5.2.10
GD-Graphikbibliothek: bundled (2.0.34 compatible); Unterstützte Grafikformate: 
GIF,
JPG, PNG.
(...)
MySQL: 5.0.67-log
Regionale Einstellungen: de_DE.UTF-8
Server: Apache
PHP Server API: cgi
RFC-2616-Header: 0
Betriebssystem des Servers: Linux infong 2.4 #1 SMP Thu May 28 16:09:02 UTC 
2009 i686
GNU/Linux Linux infong 2.4 #1 SMP Thu May 28 16:09:02 UTC 2009 i686 GNU/Linux
(...)

Inhalt der .htaccess-Datei: 
------------------------
# MM: einfach mal rausgenommen: index.html
DirectoryIndex index.php
# PHP bei 1und1 mit PHP5 oeffnen (default:PHP4)
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
#Options +FollowSymLinks
#RewriteBase /relative/web/path/
# MM Notwendig bei 1und1 wenn TP in '/' residiert
RewriteBase /
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_FILENAME} -f [OR]
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^(.+) - [PT,L]
 RewriteRule ^(.*) index.php
</IfModule>

#php_value register_globals 0

Original comment by merzmar...@gmail.com on 24 Jul 2009 at 10:32

[GoogleCodeExporter]

So the main issue is HTML cache w/o gzip (when gzip is possible)?

Original comment by sunny.dr...@gmail.com on 10 Aug 2009 at 1:33

• Changed state: Accepted

[GoogleCodeExporter]

> "So the main issue is HTML cache w/o gzip (when gzip is possible)?"

Yes. I want to use 'cache all HTML' for a full page cache managed by wbo.

The cached output was not gzipped.
No gzip header was sent.
No etag was transmitted.

Let me know when a solution is available. I promise to test it ASAP.

Off topic: I miss a documentation which explains how to put eg Google AdSense
Javascript into the header so that wbo can optimize the scripts/the script 
loading.

Original comment by merzmar...@gmail.com on 10 Aug 2009 at 2:11

[GoogleCodeExporter]

A point from above to take care of: CSS gzip was created in wbo/cache but wasn't
delivered

a) What is the difference between gzipping HTML and CSS?
b) Why was the gzipped CSS file not delivered?

Original comment by merzmar...@gmail.com on 10 Aug 2009 at 2:37

[GoogleCodeExporter]

ok, issue is clear. I will try to reproduce and fix it.
ETag for HTML isn't sent at all (on HTML caching). This can be an additional 
feature.

CSS gzip is delivered only if
 * You have mod_deflate + mod_filter or mod_gzip in Apache
 * or you have .gz files and mod_rewrite + mod_mime in Apache
 * or CSS files are managed via PHP.
of course .htaccess must be accessible for web srerv to write into (for first 2 
cases). Please write how CSS files are served for your website - through PHP or 
as 
raw CSS.

General difference between HTML and CSS gzip is that former is dynamic but 
latter can 
be (and is in most of cases) static. So gzip for HTML is absolutely dynamic 
(via 
PHP). Gzip for CSS/JS is static in all possible cases (only if we can't provide 
proper combination of headers statically PHP engine cares about them).

Google AdSense can't be added to the head but there is a way to add it to the 
</body> 
and load after all other resources. There is an option in WO config -- 
Unobtrusive 
JavaScript (and Unobtrusive Ads there).

Original comment by sunny.dr...@gmail.com on 10 Aug 2009 at 3:44

[GoogleCodeExporter]

> CSS gzip is delivered only if
 * You have mod_deflate + mod_filter or mod_gzip in Apache

Looks like my Apache doesn't support it. I never got a header feedback 
'deflate'. For
this reason I have deleted an 'if mod defalte' section in my .htacccess.

 * or you have .gz files and mod_rewrite + mod_mime in Apache

Clean URLs via <IfModule mod_rewrite.c> work fine.

 * or CSS files are managed via PHP.

I am using one static CSS file. wbo cached the CSS file in two versions (full &
compressed .gz). The .gz was not delivered and no rewrite rule was added in 
.htaccess.

"of course .htaccess must be accessible for web srerv to write into (for first 
2 
cases). Please write how CSS files are served for your website - through PHP or 
as 
raw CSS."

I am using one static CSS file. But as I use Textpattern I could also use the
original delivery via PHP.

Original comment by merzmar...@gmail.com on 10 Aug 2009 at 4:55

[GoogleCodeExporter]

is .htaccess accessible to write for the web server? This can be main issue. 
Also there 
should be enabled settings in Web Optimizer config regarding these modules 
(mod_rewrite 
and mod_mime). Web Optimizer (during installation) tries to detect allowed 
Apache 
modules. Maybe they are not detectable (due to environment) but are enabled.

Original comment by sunny.dr...@gmail.com on 10 Aug 2009 at 6:43

[GoogleCodeExporter]

ETag to HTML cache was added today.

About gzip only for not-cached HTML pages. The only possible suggestion I can 
make is 
the following. You have some cached HTML pages but all documents had been 
created 
before you activated gzip for HTML -- so cached docs are outputted w/o gzip 
(Web 
Optimizer caches HTML pages in the final view -- gzipped or not gzipped -- to 
save 
CPU).

I can't reproduce this situation (gzip for not-cached pages and no gzip for 
cached 
pages) on mod_php. Maybe you can just allow you web server to handle all gzip 
logic 
or give more details about this situation (can you trace what settings and what 
logic 
lead to this?).

Original comment by sunny.dr...@gmail.com on 11 Aug 2009 at 1:38

[GoogleCodeExporter]

> is .htaccess accessible to write for the web server?

Yes. mod_rewrite is working fine. ISP support says mod_mime is not available.

> ETag to HTML cache was added today.

Fine.

!My Environment! Re. gzip & mod_deflate & mod_mime: I called the support and 
they
told me that those apache modules are not activated because of serverload 
issues...

Gzip is only accessable via PHP (zip, zlib), not as Apache module.

My feature request: I want HTML output for one URL to be cached and then 
delivered in
one gzip compressed file.

I can fully understand & accept if you say "No, I will not support optimization
features which are not directly supported by the web server".

Original comment by merzmar...@gmail.com on 14 Aug 2009 at 1:12

[GoogleCodeExporter]

:) I can't detect the problem to fix it. So I understand that there are a lot 
of 
servers with 'wrong' settings, but I can't find the 'right' environment to 
repeat your 
trouble (and fix it therefore)...

Have your cleared the cache and tried once more? It was the only suggestion 
from my 
side -- that there are not-gzipped cached files that are outputted.

Original comment by sunny.dr...@gmail.com on 14 Aug 2009 at 9:57

[GoogleCodeExporter]

The issue/workaround is that wbo has to compress the cache files via PHP and 
not via
a server module.

And Yes, I have reproduced the issue multiple times. 

1. No compressed cache files were created.
2. No .htaccess rule was written to deliver the (non existant) gzipped files.

The only solution I see is to compress the files via PHP and to add an option to
.htaccess.

Question: Should wbo be able to compress the HTML cache files via PHP if no
compression apache module is present?

On the other hand I have a working full page cache solution which

a) is only creating gzipped files and
b) only delivers the gzipped files

I have never tested what my hosted server does when a browser doesn't accept 
'gzip'.
Somehow it simply works.

What I can do to help:

* Install the latest wbo version
* Let it run
* Give you access to wbo to check the configuration and the output

Original comment by merzmar...@gmail.com on 14 Aug 2009 at 11:01

[GoogleCodeExporter]

If you can provide access to file system (to trace wbo behavior) -- it will be 
great 
and definitely help. Maybe via e-mail or skype: sun-ny-bear

Original comment by sunny.dr...@gmail.com on 15 Aug 2009 at 5:30

[GoogleCodeExporter]

Status update:

At the moment I am using wbo AND asy_jpcache with Textpattern.
asy_jpcache is storing gzipped full page versions (being included inside 
index.php).
wbo is doing the rest (being wrapped around index.php). wbo only caches CSS but 
not
the HTML output.

I am not really sure if this scenario is a wise solution. I am not sure where 
wbo is
optimizing the output or if all gets worse by using both solutions:

* Worst case scenario:

Page is requested.
Textpattern renders page.
asy_jpcache creates gzipped cache file if not exists.
wbo gets the gzipped file.
wbo unzips the file (?).
wbo does what wbo has to do.
wbo gzips the file again (?).
If 'cache hit=yes' the last four wbo steps are always repeated (?) before the 
page is
delivered:(

* The best of two worlds?

Page is requested.
Textpattern renders page.
wbo does what wbo has to do.
asy_jpcache creates gzipped cache file.
If 'cache hit=yes' the cached gzipped file is delivered.

Only the last step is necessary if a page is requested (?) :)

Original comment by merzmar...@gmail.com on 16 Aug 2009 at 10:18

[GoogleCodeExporter]

The last scenarion can be a proper solution. wbo doesn't unzip page, it 
operates with 
raw content and hopes that it isn't gzipped (so gzipped content just isn't 
parsed). In 
this situation you need to insert wbo call before asy_jpcache logic or allow 
wbo to 
gzip page (and add wbo logic after asy_jpcache outputs the cached -- not 
gzipped -- 
page).

The last way was implemented for Joomla System-Cache plugin, but it isn't the 
best one.

Original comment by sunny.dr...@gmail.com on 16 Aug 2009 at 11:52

[GoogleCodeExporter]

> "wbo doesn't unzip page" + "gzipped content just isn't parsed"

OK, the code is parsed and "minify HTML" and other wbo actions are executed.
So it looks like 'the best of two worlds' scenario is at work.

Is there a possibility to get a verbose debug output from wbo?

The combination of "Content-Encoding: gzip", "Etag: "jpd-375038090.87202" and
"X-Cache: asy_jpcache v2 - file" seems to prove the 'right' scenario.

FYI: A 304 'not modified' header:

Date: Sun, 16 Aug 2009 13:19:42 GMT
Server: Apache
Cache-Control: no-cache
Content-Encoding: gzip
Etag: "jpd-375038090.87202"
Expires: Sat, 15 Aug 2009 20:47:12 GMT
Vary: Cookie
X-Cache: asy_jpcache v2 - file
X-Powered-By: PHP/5.2.10
Last-Modified: Sat, 15 Aug 2009 20:41:55 GMT
Content-Length: 20191
Content-Type: text/html; charset=utf-8

> "insert wbo call before asy_jpcache logic"

Yep, the wbo call is wrapping the complete index.php and include jpcache.php is 
one
before publish.php.

> "or allow wbo to gzip page"

That's the main reason for the whole thread: I can't get wbo to deliver gzipped 
HTML
output :( (See comment #2 & following)

Original comment by merzmar...@gmail.com on 16 Aug 2009 at 1:44

[GoogleCodeExporter]

Just tested 'gzip HTML' again (asy_jpcache is off). No gzip recognizable. The
delivered size is 85 KB compared to "Content-Length: 20191" sent via 
asy_jpcache.

The 200 header:

Date: Sun, 16 Aug 2009 14:02:12 GMT
Server: Apache
Cache-Control: private, max-age=300
Expires: Sun, 16 Aug 2009 14:07:13 GMT
X-Powered-By: PHP/5.2.10
Last-Modified: Sat, 15 Aug 2009 20:41:55 GMT
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

The 304 header:

Date: Sun, 16 Aug 2009 14:06:20 GMT
Server: Apache
Cache-Control: no-cache
Expires: Sun, 16 Aug 2009 14:07:13 GMT
X-Powered-By: PHP/5.2.10
Last-Modified: Sat, 15 Aug 2009 20:41:55 GMT
Content-Type: text/html; charset=utf-8

Conclusion: Gzip HTML via PHP is not working in wbo 0.5.4.

Original comment by merzmar...@gmail.com on 16 Aug 2009 at 2:08

[GoogleCodeExporter]

If there is 'htaccess' enabled and 'mod_deflate + mod_filter', wbo doesn't send 
gzipped 
output (relies on web server - i.e. Apache - to gzip it).

So as I see you've found the proper solution, but some troubles are still not 
resolved. 
I mean 'strange' behavior with gzip (htaccess via PHP) and cache (cached pages 
are not 
gzipped).

Original comment by sunny.dr...@gmail.com on 16 Aug 2009 at 2:41

[GoogleCodeExporter]

> "If there is 'htaccess' enabled..."

Oops, yes, .htaccess is enabled all the time but as I wrote in another thread 
nothing
is written to .htaccess. Only the time stamp is refreshed.

If I understand you right DISABLING .htaccess helps to trigger Apache to gzip 
the
JS/CSS/HTML output on the fly?

This might be the clue and I will test it with my wbo 0.5.4 installation by 
disabling
all .htaccess options in the config file.

Fast check after disabling...

OK CSS is compressed now :)

Date: Sun, 16 Aug 2009 16:02:34 GMT
Server: Apache
Cache-Control: private, max-age=315360000
Content-Encoding: gzip
Etag: "1250438534-gzip"
Expires: Tue, 12 Jan 2021 08:02:14 GMT
X-Powered-By: PHP/5.2.10
Content-Length: 13404
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Content-Type: text/css; charset: UTF-8

All right, that's a step forward, more will follow soon...

PS: That easy solution is definitely worth a wiki page!

More to test: wbo gzipped HTML full page cache against wbo raw HTML + 
asy_jpcache
gzipping the raw HTML.

Re. "wbo gzipped HTML" Is there a possibility to configure the gzip compression 
level?

Original comment by merzmar...@gmail.com on 16 Aug 2009 at 4:14

[GoogleCodeExporter]

Hmm. I will think about wiki page for gzip options

There is no option to tune gzip compression level (9 is default for PHP, for 
Apache 
internal default level is used as there were some troubles with setting it via 
.htaccess). Is it required? If so we need 3 different options (HTML, CSS, JS) 
and low 
support from .htaccess (the latter must be investigated properly).

Original comment by sunny.dr...@gmail.com on 16 Aug 2009 at 4:20

[GoogleCodeExporter]

No, I am not sure about adding gzip compression levels to the options.
At least not in the admin UI.

As compression level 9 is the highest possible AFAIK to leave this with PHP as 
the
default is totally OK. And as we are talking KB and not MB CPU or memory 
performance
shouldn't be an argument for complicating the wbo gzip configuration. High level
websites will use mod_deflate anyway. (Remember: In my case I am always talking 
about
a patched Apache 1.3 & CGI with limited configuration options!)

Maybe for the advanced tuners in the config file?

Original comment by merzmar...@gmail.com on 17 Aug 2009 at 11:22

[GoogleCodeExporter]

Added optional gzip_level for HTML/CSS/JS (for CSS/JS works only if they are 
outputted 
as PHP) with rev.401. Will be in 0.5.5

Original comment by sunny.dr...@gmail.com on 17 Aug 2009 at 1:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Status update: Tested wbo 0.5.5 on two sites with different Apache versions and
configurations (2 ISPs & 2 different shared hosting solutions)

BTW: wbo 0.5.5 live update went well. Nothing is broken. Minor typos & UI design
issues detected.

My resume for running wbo on Apache with PHP as CGI so far:

* All .htaccess options turned OFF = Gzip works via PHP/Apache
* HTML full page cache is delivering pages fine. 
* Will have to check cache purging
* ! HTML full page cache issues: 
** ! Some pages are stored BUT a) not minified to one line & b) not gzipped. 
There
seem to be hickups in the code! 
** ? Q: Or can browser requests without 'Accept-Encoding gzip,deflate' trigger 
that
behavior? Or bots?
** ? Q: If 'minify HTML to one line' aka 'Shrink HTML to the one string' fails 
will
gzipping via PHP still be triggered? I have now turned off 'minify HTML to one 
line'
and will watch the cache for a while.
* 'Verify files mtime' is turned off and looks good so far.
* ! Documentation: Don't flush pages if you want to cache full pages via wbo.
Flushing kills HTML cache!
* Using dataURI: works great.
* ! Efficiency: Using the CSS sprite option(s) always blows up the CSS transfer 
and
sprites have browser issues.
* No CSS sprites is the way to go to be on the safe side.

Original comment by merzmar...@gmail.com on 17 Aug 2009 at 9:54

[GoogleCodeExporter]

Edit/Correction!

<--
* Using dataURI: works great.
* ! Efficiency: Using the CSS sprite option(s) always blows up the CSS transfer 
and
sprites have browser issues.
* No CSS sprites is the way to go to be on the safe side.
-->

After a lot of reading and testing I have to commit that it is the other way 
round:

* Don't use dataURI:. Using dataURI: only works great in up to date browsers.
* Using an extra sprite and excluding IE6 via CSS hacks is the way to go to be 
on the
safe side.

Original comment by merzmar...@gmail.com on 18 Aug 2009 at 4:01

[GoogleCodeExporter]

Original comment by sunny.dr...@gmail.com on 18 Aug 2009 at 6:05

• Changed state: Fixed