Re: [Phpslash-devel] setup.php

[Luis M <le...@ho...>]

Hello Mike,

>On Mon, 2003-03-17 at 23:28, Luis M wrote:
> > >Is this posted somewhere to take a look at?  mailman's digest garbled
> > >the attachment pretty badly so I'd need to download it from somewhere
> > >else.
> > Working version (revised):
> > http://www.latinomixed.com/setup.php
>
>This looked nice.  Might be good to have the setup.php guess the right
>answers to the location, but other than that it looks quite hopeful.

that's an idea... I'll keep it in mind.

>
> > Script compressed:
> > http://www.latinomixed.com/setup.php.bz2
>
>I suspect that your server isn't set to recognize .bz2's mime types.  I
>could be way wrong on that, but I couldn't download it.
>

Using wget works for me here. it seems to crash my mozilla (v1.4a):

wget http://www.latinomixed.com/setup.php.bz2

I also put the file in this ftp url:

ftp://ftp.latinomixed.com/downloads/setup.php.bz2 (use PORT and not 
PASSIVE).

> > I figured a better way to parse the file. It now just submit the data to
> > itself and then the user will have to save the output using the "Save 
>As..."
> > command from the browser window.
>
>This is just my 2c on this issue.  But I would think that the easiest
>thing from the user perspective would be to:
>1) check to see if the config.ini.php has write permissions
>a) if so write to directly to the file (with confirmation)
>if(is_writeable{config.ini.php})
>
>b) if not send the config to the user via:
>header ("Content-type: application/txt\nContent-Disposition: inline;
>filename='config.ini.php'");
>
>Think that this is valid, I had it as
>application/csv\nContent-Disposition previously.


I will experiment using different headers on different browsers to see what 
happens, but I know it will work for all browsers (even lynx) if one only 
allows the file to be presented as HTML and then let the users save it 
locally. Joe didn't want to deal with writing the file to the server because 
of permission issues and just more questions to the FAQ from newbies.
My idea of a setup.php is to be as easy as possible on newbies, hardcore 
phpslash users will go their way with their vim's or emacs. Of course, if we 
get the setup.php right, then core users could run the initial setup.ini.php 
thru the setup.php first (just for convenience) and then if needed edit it 
later by hand (to add extra features).


>
> > Save this resulting file as Plain Text, and
> > give it a valid name "setup.ini". Of course the user will put this file
> > OUTSIDE of the web server space, thus there is no need to add the "; 
><?php
> > die() " lines ... but, to be safe, we could add those lines regardless.
>
>For security, the config.php could check to see that setup.php has been
>deleted before allowing the user to log in.  This way they could see
>that its working and then delete it. either or both of these could be
>used to add security to make sure someone else can't edit the config
>afterwards.
>if(is_file(setup.php))
>if(is_writeable{config.ini.php})

Well, setup.php is harmless if it only allows the config-dist.ini.php file 
to be used. It's only when we start allowing users to pass arguments with 
their own files that the problems start getting complicated. At that point 
we might just check first that there is a valid instalation of phpslash 
(checking if setup.php is loadable and using the login stuff to get the 
users to login with a valid username/password)... but that's a lot more than 
what is needed... we only need a simple way to get phpslash setup the first 
time -- with newbies and Mac users in mind :-)


> > The reason I did this is because sending a header to the browser that 
>this
> > file is type text/ini or text/whatever, might cause the browser to 
>display
> > the file anyway. So the "save file" would not do what it's supposed to 
>do.
>
>True..  But its also another step for a user to go through..  What
>browsers would mix up the header?

:-) it's just a matter of testing browsers to see what works for all :-) or 
adding an extra step and skip the testing part...


>
> > I added other minor enhancements. I plan to allow the users to "preview" 
>the
> > file and possibly feed it back to the same form to be re-edited... but
> > that's in the future.
>
>Only so much time..  Does the script populate the database or just write
>the config.ini.php for you?
>

it might be nice to get to that point, but for now is just to get a .ini . I 
think that populating the database will get us in a whole different mess: 
users will have to definitely remove the setup.php file from their 
instalations when finished, users will have to provide the .sql file they 
want/need according to whether they are upgrading or are setting phpslash 
for the first time, etc...

talking about upgrading, it would be nice to pick the settings from the past 
config.php3 files for those users... but then again, that's another big mess 
:-) i'm just trying to keep it simple.


----)(-----
Luis Mondesi
System Administrator
LatinoMixed.com

le...@ho...

"...The Mac does this so smoothly, it feels like an extension of your mind." 
- Paula Speer, MacWorld Magazine 2003-04

Public signature: http://www.latinomixed.com/lems1/public-a.asc


_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis ! 
http://www.msn.fr/msger/default.asp