Re: [Phpslash-devel] back-end install wizard

[Joe S. <joe...@us...>]

On Thu, Nov 06, 2003 at 05:10:21PM -0500, Luis M wrote:
> >> >I backported Evan Hughes' install wizard for back-end to phpslash.  It 
> >is
> >> >in cvs now.  If you do an anon checkout it may not be mirrored yet.
> >>
> >> yoohooo!! and I thought my migration process was going to be bad. That
> >> sounds great. After using an Install Wizard, I'm thinking about simply
> >> dumping my tables and moving my template dir to the new instalation; 
> >then
> >> test and retest until I get things stable enough -- while taking notes 
> >and
> >> fixing bugs as I go. That way I will have a more solid upgrade path for 
> >my
> >> production sites.
> >>
> >
> >No upgrade script for the tables yet.  But yeah, I've been doing more and
> >more from this base.
> 
> Oh, it would be even better if you could just incorporate that into the 
> setup_config.php itself a la run-parts in debian :-D
> say, have a directory called "post_setup", "pre_setup" or whatever, and e/a 
> file in this directory is considered as a php script that needs to be run 
> before and after setup respectively. That way sysadmins/webmasters can just 
> have those scripts ready to upgrade their sites when new releases come out. 
> Say that users diff the tables.sql file from the pass release against the 
> new one and note the new tables they have added to their sites... etc... 
> those directories could then be removed once the setup/upgrade is done.
> 
> >> >Luis - can you see if you can add your download option?  Currently if 
> >it
> >> >can't write the ini file it displays it for cut and paste.  Also see if
> >> >maybe we could graft your editor on for modifying the other options, or
> >> >expand the questions.  It currently only does the bare minimum to get
> >> >started.
> >>
> >> Not a problem. However so far I get this when doing "cvs update"
> >> $> cvs update
> >> ssh_exchange_identification: Connection closed by remote host
> >> cvs [update aborted]: end of file from server (consult above messages if
> >> any)
> >>
> >> So, I guess SourceForge is having problems, again. This might be the
> >> begining of the end for such a nice project? Don't know for sure yet but
> >> they are always having problems.
> >>
> >
> >This is what I used:
> >
> >cvs -dj...@cv...:/cvsroot/phpslash co
> >phpslash-dev
> >
> [snip]
> It's already fixed. They had a hicup for a few minutes. I already found and 
> committed minor fixes.
> Which brings this to mind, the config-dist.ini.php and config_setup.ini.php 
> are essentially the same file. We should be able to just move (rename) 
> config_setup.ini.php to config-dist.ini.php for now (in CVS) and change the 
> config_setup.php to use this file instead. That way we are not going to be 
> doing double work every time we add a new variable to the ini file.
> 
> 
> >
> >I've thought about that too.  Just make the alpha release a dated
> >snapshot.
> >
> >Joe
> got it. i think it creates less fuzz in the CVS rep.
> 
> Just a few things to keep in mind (I have to run; I will continue later 
> with this):
> 
> 1. when there is a database already setup but there is no table in it, the 
> script config_setup.php fails

I've introduced some notices and warnings too.  Will look into this.

> 2. if the server cannot write to the config.ini.php file, the 
> config_setup.php fails (no error printed)

I got the output displayed for cut and paste.

> 3. config_setup.php seems to be very fragile... in other words, lots of 
> things can go wrong using $var+"string" to call a function. Especially 
> since $var is assigned from something submitted from a browser... 
> suggesting that it might fail if a browser mangles the strings or if users 
> inject something... etc... i'm sure we can find a million things why this 
> would not be wise. However, it works for now and we might change things 
> later to improve it.

I'm sure this is true.

> 4. users have to be reminded to remove the config_setup.php file from the 
> public site inmediately after setting the site up... if the script could 
> remove itself it would be even better

back-end nags at you if you login and these files are still there and/or
the ini file is writable.  Is this best or should we refuse to run?

> 5. if writing to the server's config.ini.php is not an option, then i will 
> incorporate the code to push the file to the user's browser (as you 
> suggested Joe).

good deal.  

> 6. ... i have a lot more things, but I'll try to keep them in mind...
> 
> 
> 
> ----)(-----
> 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 Search, le moteur de recherche qui pense comme vous ! 
> http://search.msn.fr/worldwide.asp
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel