phpix2-devel

[PHPix2-devel] Made a bit of a change.

[Bryan K. <br...@wu...>]

Okie, I made a bit of a change in the way phpix works. I offloaded the
images onto a separate script, which deals with resizing and caching.

It's checked into the cvs server, so give it a whirl. 

Thing this means:
  a) Pages _feel_ faster (even though they aren't necessarily) when we
  have to do a bunch of conversions. The reason for this is the html
  renders, and then the pictures get filled in. Before you would wait
  for all the pictures to convert before anything would render.
  b) we can move the images out of the webroot.
  c) because images are not in the webroot, we can do security
  ourselves, without having to worry about .htaccess files.
  d) since we can do security ourselves, we can make password protected
  albums, login ability, and admin stuff (add,delete pictures).

My next project will be to try get a user login function, once I have
that, I'll do an admin interface. Then possibly a user comments section.

I'll clean up the code a bit more over the next while and add the
picture root stuff. (ie, having pictures out of the webroot) I'll leave
it so by default it works out of the box.

Bryan

perl -e 'map{print(pack(V,exp("21.$_")))}(21512211,40167979,2548395575,2745918245)'

Re: [PHPix2-devel] Made a bit of a change.

[William B. <boo...@ro...>]

Sounds good to me. How about someone figuring out how to make PHPix
into a PHPNuke module. The image galleries that are out there for
PHPNuke are not nearly as nice as PHPix.

Bryan Kilian said:
> Okie, I made a bit of a change in the way phpix works. I
> offloaded the images onto a separate script, which deals with
> resizing and caching.
>
> It's checked into the cvs server, so give it a whirl.
>
> Thing this means:
>  a) Pages _feel_ faster (even though they aren't necessarily)
>  when we have to do a bunch of conversions. The reason for this
>  is the html renders, and then the pictures get filled in. Before
>  you would wait for all the pictures to convert before anything
>  would render.
>  b) we can move the images out of the webroot.
>  c) because images are not in the webroot, we can do security
>  ourselves, without having to worry about .htaccess files.
>  d) since we can do security ourselves, we can make password
>  protected albums, login ability, and admin stuff (add,delete
>  pictures).
>
> My next project will be to try get a user login function, once I
> have that, I'll do an admin interface. Then possibly a user
> comments section.
>
> I'll clean up the code a bit more over the next while and add the
> picture root stuff. (ie, having pictures out of the webroot) I'll
> leave it so by default it works out of the box.
>
> Bryan
>
> perl -e
> 'map{print(pack(V,exp("21.$_")))}
(21512211,40167979,2548395575,2745918245)'
>
> _______________________________________________
> PHPix2-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpix2-devel


____________________________________________________________________
Disclaimer: The opinions expressed in this email are not necessarily
mine, as I've not yet had my medication today.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--------------------------------------------
This email originated from Booster's Dilemma
http://boostersdilemma.com/

Re: [PHPix2-devel] Made a bit of a change.

[Neale P. <ne...@wo...>]

Someone's already done that.  They even promised to send the code to me
once, but I never got it.

I think his site had something to do with fishing.  Nice enough guy, he
probably just got too busy and forgot he was going to send me his code.

Or you could just do it yourself, which might be faster than trying to
find the version that's already been done :-)


So then, William Borrelli <boo...@ro...> is all like:
> Sounds good to me. How about someone figuring out how to make PHPix
> into a PHPNuke module. The image galleries that are out there for
> PHPNuke are not nearly as nice as PHPix.

> Bryan Kilian said:
>> Okie, I made a bit of a change in the way phpix works. I
>> offloaded the images onto a separate script, which deals with
>> resizing and caching.
>>=20
>> It's checked into the cvs server, so give it a whirl.
>>=20
>> Thing this means:
>> a) Pages _feel_ faster (even though they aren't necessarily)
>> when we have to do a bunch of conversions. The reason for this
>> is the html renders, and then the pictures get filled in. Before
>> you would wait for all the pictures to convert before anything
>> would render.
>> b) we can move the images out of the webroot.
>> c) because images are not in the webroot, we can do security
>> ourselves, without having to worry about .htaccess files.
>> d) since we can do security ourselves, we can make password
>> protected albums, login ability, and admin stuff (add,delete
>> pictures).
>>=20
>> My next project will be to try get a user login function, once I
>> have that, I'll do an admin interface. Then possibly a user
>> comments section.
>>=20
>> I'll clean up the code a bit more over the next while and add the
>> picture root stuff. (ie, having pictures out of the webroot) I'll
>> leave it so by default it works out of the box.
>>=20
>> Bryan
>>=20
>> perl -e
>> 'map{print(pack(V,exp("21.$_")))}
> (21512211,40167979,2548395575,2745918245)'
>>=20
>> _______________________________________________
>> PHPix2-devel mailing list
>> PHP...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpix2-devel


> ____________________________________________________________________
> Disclaimer: The opinions expressed in this email are not necessarily
> mine, as I've not yet had my medication today.
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF


> --------------------------------------------
> This email originated from Booster's Dilemma
> http://boostersdilemma.com/



> _______________________________________________
> PHPix2-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpix2-devel

Re: [PHPix2-devel] Made a bit of a change.

[Neale P. <ne...@wo...>]

So then, Bryan Kilian <br...@wu...> is all like:
> Okie, I made a bit of a change in the way phpix works. I offloaded the
> images onto a separate script, which deals with resizing and caching.

Good idea!

Re: [PHPix2-devel] Made a bit of a change.

[Bryan K. <br...@wu...>]

Well, let's have a quick discussion:

How would we like password protection to work?
There are two ways I can think of which seem to fit nicely:

a) single file with username:password:album1,album2,album3

Pro: Single file
     Easy to modify and add new albums for a user.
Cons: Allow based password protection, ie, deny all but the albums
      you specify. Could get nasty with lots of albums.
       - suggestion, make a * and -album1, although this would require
         more parsing, it would allow you to do something like:
         username:password:*,-album1,-album2
      What do you do about nested albums? (album1/album2)?
      requires special file handling to create the password file.

b) .htpasswd files in each album you want protected, as well as a master
   .htpasswd in the script dir.

Pro: * Simple design.
     * Files can be created with the htpasswd util distributed with
       apache.
     * deny based. If you want to allow access to an album you don't put a
       .htpasswd in the dir (and also don't have the master one)
     * works well with nested albums. (searches down the tree for a
       password file)
     * Works the same way as the current config override system.
Cons: * Multiple files.
      * Slightly more work to upkeep, although good design of the album
        heirarchy could minimise that.
      * Might have to have the same password file in multiple locations.
         - Could be solved with soft links
      * Can't have a master password file without closing all the album
        dirs.

Any thoughts?

I currently have a working version of type 2, take a look at
  http://wuzzle.org/photos/new/phpix

  You should be able to view the main page fine, and CVS, but if you try
  view Sample Album, it should prompt you for a user/pass.

  user: test
  pass: ook

  I can modify it for type a) pretty easily. or possibly a hybrid. Now
  that the framework is in, the way we want to apply it is easily
  changed.

Bryan  
      
On Thu 2001-11-01 (10:11), Neale Pickett wrote:
> So then, Bryan Kilian <br...@wu...> is all like:
> > Okie, I made a bit of a change in the way phpix works. I offloaded the
> > images onto a separate script, which deals with resizing and caching.
> 
> Good idea!

perl -e 'map{print(pack(V,exp("21.$_")))}(21512211,40167979,2548395575,2745918245)'

Re: [PHPix2-devel] Made a bit of a change.

[Neale P. <ne...@wo...>]

So then, Bryan Kilian <br...@wu...> is all like:

> I currently have a working version of type 2, take a look at
>   http://wuzzle.org/photos/new/phpix

Yeah, I would vote for type 2 as well, but not everyone is running
apache.  However, I'm a big fan of HTTP authentication (since I'm a big
opponent of cookies).  So maybe the hybrid is the way to go.

But I can't really say what's the best way to do this, since I wouldn't
have a personal need for it.  I would imagine, though, that more folks
would want to use the server for authentication than phpix itself, since
that allows you to have a unified auth scheme for all your stuff: html,
phpix, and whatever else you happen to run.

Neale

Re: [PHPix2-devel] Made a bit of a change.

[Bryan K. <br...@wu...>]

On Fri 2001-11-02 (10:19), Neale Pickett wrote:
> Yeah, I would vote for type 2 as well, but not everyone is running
> apache.  However, I'm a big fan of HTTP authentication (since I'm a big
> opponent of cookies).  So maybe the hybrid is the way to go.
Type two should work for IIS as well, although you will need to tweak
things and pass through authentication. (I'll dig up the page on php.net
that explains it and stick it in a doc).

> But I can't really say what's the best way to do this, since I wouldn't
> have a personal need for it.  I would imagine, though, that more folks
> would want to use the server for authentication than phpix itself, since
> that allows you to have a unified auth scheme for all your stuff: html,
> phpix, and whatever else you happen to run.
I have a personal need for it. (We have a group that wanted to share
photos, but have it closed off to the public). But I'm quite happy with
either design. I coded the second form because it fits in with the way
the rest of the config overrides work.

Also, if you wish to use your own auth, you can just set $use_auth to 0
in config.inc, and provide your own. It won't be able to auth a
particular album though, since the scripts get run from a single dir.
you'd have to auth the whole thing, or not at all.

I was also thinking of providing a "login" link that logs you in, and if
you're not logged in, PHPix doesn't even _show_ albums you're not
allowed access to. This would only work well with type 1 auth. Type 2
would require a tree traversal and that might slow us down a little.

Oh, while I was at it, I got tired of the copying index.php around, so I
modified it to display what dfl_index.php used to display if config.inc
is not found. This allowed me to delete album.php and dfl_index.php and
still have the full functionality of the default install. (Also makes it
much easier when checking things into CVS.)

For some reason, I've just been having the urge to code recently :-)

Bryan

perl -e 'map{print(pack(V,exp("21.$_")))}(21512211,40167979,2548395575,2745918245)'