data directory must be writable by webserver owner or invalid zipfiles will be produced by clippings cart.

[Jeremy Anderson]

version 1.5.2, freshly updated :)

To duplicate:

add an individual with media files to clipping cart. In the clipping cart screen, Go ahead and select "zip files", and "Include media," then click "Download Now."

If the webserver is unable to write to /var/www/webtrees/data, it will not give the website user an error, but will produce a 280kb zipfile which cannot be opened.

/var/log/apache2/error.log will contain a line similar to this:
[Mon Mar 24 13:50:01 2014] [error] [client 192.168.15.5] PHP Warning: fopen(/var/www/webtrees/data/clipping1190065829.ged): failed to open stream: Permission denied in /var/www/webtrees/modules_v3/clippings/clippings_ctrl.php on line 264, referer: https://www.YOURDOMAINNAMEHERE.com/webtrees/module.php?mod=clippings&mod_action=index&id=I33&type=indi&action=add1&level1=10&others=ancestorsfamilies&level2=10&level3=10

Setting file owner of /var/www/webtrees/data to be www-data user has resolved the issue.

It would be nice if this error could bubble back up to the GUI.

[fisharebest (fisharebest)]

The installation/setup script checks that the /data/ folder is writable.

Are you saying that to reproduce the bug, you must complete the installation - and then subsequently change the permissions?

[Jeremy Anderson (jeremy-angelar)]

I downloaded the zipfile, and extracted that on a linux box. I backed up /var/www/webtrees directory -> /var/www/webtrees.1.4.3 and moved the new 1.5.6 webtrees dir into /var/www/webtrees, then did a
cp /var/www/webtrees.1.4.3/data /var/www/webtrees

While I screwed up the permissions itself, it might be useful in the future if that error message could pop up to the web interface, so that the end-user would have some clue as to why the zipfile of their clippings is invalid.

But this may be such an edgecase that it's not worth pursuing, and if so, close the bug report, and I'll take no offense :)

[fisharebest (fisharebest)]

Since we *do* check for the correct file permissions during setup, I think it would be unreasonable for the code to check it again, each and every time it needs to write to the folder.

[Jeremy Anderson (jeremy-angelar)]

Good point -- I suppose with the click-to-update feature now implemented, this won't arise again.