Truncated HTML output

SubJunk

Hi,
I've used zenphoto for around 4 years and continue to be grateful for the development.
Today I have tried to upgrade one of my websites to version 1.3.1.2 and it works well, except for a very strange thing.
It seems to be cutting off the end of the page code each time, at inconsistent lengths; if I refresh the page it outputs either more HTML or less HTML than before.
You can see it at http://www.dualmonitorbackgrounds.com/testing/

Any help would be great.

sbillard

This is caused by the browser "timing out" befor all the HTML is delivered. Not sure what would cause that, though. But you can try the html cache plugin. That would at least take most of the Zenphoto processing out of the loop.

SubJunk

Thanks for the reply, sbillard.

I don't think using the html cache plugin is an option since the pages need to be dynamic because of the "resolution preferences" option.

The page seems to load quickly for me, it's strange it would time out. After a browser refresh it only takes 2-3 seconds to load (less if we exclude image loading time). Are you sure that is the problem?

sbillard

That is the most likely reason. And your statement about the refresh would tend to confirm. That data is probably comming from a cache somewhere down the line that did not time out.

The only possible causes are
1. slow delivery of the PHP output to the client
2. PHP script failing to complete.

There is really no way to tell the difference unless the server logs show indications of #2. 2 is also not very likely since one would expect that the server would be repeatable. But perhaps there is something on the server that is at issue.

For instance it might be having slowness retrieving files from the file system, but cache recent file requests. Then it may fail the first time to deliver all the files but succeed the second because some of them were already present in its cache.

What version of Zenphoto were you running previously?

SubJunk

I was running version 1.2.6 (and the main site, http://www.dualmonitorbackgrounds.com still is), and I updated incrementally to 1.2.7, 1.2.8, 1.2.9, then 1.3.1.2.

I didn't notice the problem with 1.2.9, but I can revert to that version to check if that would help so I can pinpoint which version it starts with.

Edit: Confirmed that 1.2.9 works fine, now I'll test 1.3

SubJunk

Looks like I can't edit my previous post anymore, sorry for the double-post.

I've just confirmed that it first occurs with version 1.3.0.

sbillard

I notice that you do have the static html cache enabled on that site. Is it possible that it is not there on the 1.3 versions?

If you have a public test site with 1.3 that might help us. Also, does the problem show in one of the distributed themes?

SubJunk

After more testing I've narrowed it down to build 5099; build 5098 works perfectly, while the problem starts happening with 5099.

The problem happens with all themes.

I do have static html cache enabled but it doesn't need to be since I have excluded all pages (it was enabled in previous versions of the website and I just never disabled it), in fact I will just disable it now.
*disables it*
OK, with static html cache disabled, version 1.3.1.2 works perfectly. So I guess it's either a problem with static html cache or maybe the required syntax was changed from build 5098 to 5099?

I had the following in the plugin options input box:
`search.php/,contact.php/,image.php/,index.php/,album.php/`

In conclusion, disabling the static_html_cache plugin fixed the problem for me.
If there's any more testing you'd like me to do in order to identify why the plugin does that I would be happy to.

acrylian

I don't remember that we did change the internal behaviour that much. Are maybe the permissions wrong on the cache_html folder (although you should get an error about that I guess)?

The static_cache_plugin requires at least php 4.3 or later (uses file_get_contents()). Before there was an fallback for older php versions but since Zenphoto recommends to use php 5.2+ at all (although not being strictly php 5) we did threw that out sometime, I think.

kagutsuchi

Looking at changeset [5099], I'd bet that the problem is caused by `ob_end_clean()` discarding the rest of the output. Perhaps there is some race condition being caused in which longer pages won't output the entire buffer before it's cleaned?

I haven't looked at the plugin extensively, but perhaps it would be better to call `ob_end_flush()` instead.

sbillard

This call does seem in the incorrect place at least. It will be called even for pages excluded from caching [sic]. Acrylian is the developer familiar with this plugin. But, SubJunk, if you can test, move the call to just before the "}" which is currently above the line.

edit: Actually, I do not see why that line is there at all. It should not be there if the page is not cached and should not be needed if it is.

acrylian

`ob_end_clean` is there to clear the buffer/free the memory after caching as far as I remember (did not look at the plugin for quite a time..). I agree it should not be needed if the page is not cached at all... Must again have been there for "ages"...

sbillard

Well, it was in fact added by the changeset [5099]. But probably what should be done is have positive control of the buffer. [5972] adds a memory of if the output buffer is opened and tests for this before closing. I think [but cannot guarentee] that the static_html_cache file of this revision will be compatible with the base 1.3.2.1 release, so if you can try it in a test we would appreciate it.

acrylian

will be compatible with the base 1.3.2.1 release,
1.3.1.2 of course...;-)

SubJunk

Good work, it is fixed in build 5972

sbillard

Thanks for your help in finding this!

SubJunk

Thanks for the fix and all the work you do on zenphoto, you guys are great

SubJunk

The update is live now and there's more thanks for you guys at the Multi Monitor Group blog, http://www.multimonitorgroup.com/news/?p=47
Cheers