It seems as though quite a few people are using phpix2, and I've only heard of one real problem with it (it seems as though a certain SUSE installation isn't paying attention to the setuid bit on convert--weird).
If nobody can come up with any bugs by February 15, I'm going to do a stable release, tell freshmeat, etc. (Is that a long time to wait? I don't know, I work at a firewall company, we're very cautious :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the work you're doing on phpix to make it even better, sounds very promising (will download it this weekend and play with your changes). There's one more thing I'd like to see to make really happy:
It should be possible to have a local configuration file per album, allowing overrides of the default settings like defaultsize, viewsizes, etc.
Another thing I'd like to see is phpix enforcing the viewsizes set in the config file. This way we could prevent DOS-attacks by people modifying the URL containing the imagesize, thereby creating all kinds strange sizes.
regards,
Heiko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had no problems with phpix2 yet. I _have_ made a number of changes to the source though. (For instance, being able to supply a stylesheet for IE and another for other browsers.)
Things I'm contemplating doing are:
1) Grab the stylesheets from the directory you're viewing, then the default if that doesn't exist.
2) Allowing different directories to set their own defaults.
And a couple of other things.
Ok, I've fixed the security issue, added the ability to put a style.css in any album dir, and moved the __desc.txt items to the actual pics dirs. (I was tired of them disappearing everytime I rm-rf'd the cache dir to do more testing)
Problems: The style sheets aren't commutative. If you put a new stylesheet in albums/Pics1, then albums/Pics1/Pics1B won't get that stylesheet. I may decide to fix that. Dunno.
I was thinking about being able to override settings in the album dirs, It's easy to implement, but I worry about someone redefining a dir that's already been used for something. (the settings overrides, of necessity, wouldn't be included before anything runs)
I uploaded a patch that will update the standard distribution (After you've typed make ;-)) The changes are in index.php, view.php and common.inc
Bryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I've updated the patch a bit.
Now a style.css will be applied to any directories below it too. This means you can have a single stylesheet at the base of your tree, and it'll work throughout that album.
I've also added a config option: $show_albums, which gives you the option to hide the albums link on the navbar. This is useful if you have different albums and want to link to them from different places on the site. (By modifying the $site_home dir, you keep your site map simpler - See the config overrides below)
I also removed the EUID check in the convert.sh, I don't see why it's needed, and it was stopping me chowning a picture dir to a user on my machine for them to maintain it.
I also made it possible to override settings in subdirectories. If you create a .config file in the directory, it will use the settings from that. (For default pic sizes, number of thumbs a page etc) The .config applies like the style.css override, it will be used in directories under the one it was placed in too.
Going to http://wuzzle.org/photos and clicking on Andrea or Wedding will show you what I mean. Wedding makes use of a modified config and a new stylesheet, and Andrea is currently set up with the default stylesheet. (Andrea's pics are in her home directory, owned by her, and I merely linked to her directory from the albums dir.)
I'm still a bit worried about the config overrides, as it implies you trust the person with the overriding config file, since it gets executed, it's a security hole waiting to happen. (At least it's not externally exploitable, it can only be done by someone you've allowed to make changes)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-01-09
Niiiice. :-) I'll take a look at that patch tomorrow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems as though quite a few people are using phpix2, and I've only heard of one real problem with it (it seems as though a certain SUSE installation isn't paying attention to the setuid bit on convert--weird).
If nobody can come up with any bugs by February 15, I'm going to do a stable release, tell freshmeat, etc. (Is that a long time to wait? I don't know, I work at a firewall company, we're very cautious :-)
Neale,
thanks for the work you're doing on phpix to make it even better, sounds very promising (will download it this weekend and play with your changes). There's one more thing I'd like to see to make really happy:
It should be possible to have a local configuration file per album, allowing overrides of the default settings like defaultsize, viewsizes, etc.
Another thing I'd like to see is phpix enforcing the viewsizes set in the config file. This way we could prevent DOS-attacks by people modifying the URL containing the imagesize, thereby creating all kinds strange sizes.
regards,
Heiko
I've had no problems with phpix2 yet. I _have_ made a number of changes to the source though. (For instance, being able to supply a stylesheet for IE and another for other browsers.)
Things I'm contemplating doing are:
1) Grab the stylesheets from the directory you're viewing, then the default if that doesn't exist.
2) Allowing different directories to set their own defaults.
And a couple of other things.
My Albums: http://wuzzle.org/photos
Bryan
Ok, I've fixed the security issue, added the ability to put a style.css in any album dir, and moved the __desc.txt items to the actual pics dirs. (I was tired of them disappearing everytime I rm-rf'd the cache dir to do more testing)
Problems: The style sheets aren't commutative. If you put a new stylesheet in albums/Pics1, then albums/Pics1/Pics1B won't get that stylesheet. I may decide to fix that. Dunno.
I was thinking about being able to override settings in the album dirs, It's easy to implement, but I worry about someone redefining a dir that's already been used for something. (the settings overrides, of necessity, wouldn't be included before anything runs)
I uploaded a patch that will update the standard distribution (After you've typed make ;-)) The changes are in index.php, view.php and common.inc
Bryan
Ok, I've updated the patch a bit.
Now a style.css will be applied to any directories below it too. This means you can have a single stylesheet at the base of your tree, and it'll work throughout that album.
I've also added a config option: $show_albums, which gives you the option to hide the albums link on the navbar. This is useful if you have different albums and want to link to them from different places on the site. (By modifying the $site_home dir, you keep your site map simpler - See the config overrides below)
I also removed the EUID check in the convert.sh, I don't see why it's needed, and it was stopping me chowning a picture dir to a user on my machine for them to maintain it.
I also made it possible to override settings in subdirectories. If you create a .config file in the directory, it will use the settings from that. (For default pic sizes, number of thumbs a page etc) The .config applies like the style.css override, it will be used in directories under the one it was placed in too.
Going to http://wuzzle.org/photos and clicking on Andrea or Wedding will show you what I mean. Wedding makes use of a modified config and a new stylesheet, and Andrea is currently set up with the default stylesheet. (Andrea's pics are in her home directory, owned by her, and I merely linked to her directory from the albums dir.)
I'm still a bit worried about the config overrides, as it implies you trust the person with the overriding config file, since it gets executed, it's a security hole waiting to happen. (At least it's not externally exploitable, it can only be done by someone you've allowed to make changes)
Niiiice. :-) I'll take a look at that patch tomorrow.