Hi John
1) I didn't notice anywhere to choose the path for the install. (This
might
be because I only tested with cli?) That makes it kinda hard to figure
out
where the installed version went :) I eventually found it in PROGRA~1,
which
might be the default for registry-based installations but was (perhaps
strangely) not where I'd have immediately expected it to be from a
desktop
test install.
2) Same goes for the php.ini, the whereabouts of which can be fairly
critical depending on the setup.
(Those two I think are probably important.)
On the page where you choose the components to install, you'll see the
location underneath the tree widget, with a browse button to locate
where to put it. It's somewhat non-obvious though, I'm not sure how
much of an issue it is ( I know many MSI based installers are laid out
in the same fashion ).
Too much information on that page, is why I didn't notice it. I think it
probably
needs a design rethink, but see what other feedback you get - it's been a
long
day here ;)
3) is there some way to have (version-compatible) components 'install on
demand', rather than download the whole lot at one go?
(Would be useful if...)
4) enabling extensions via the installer at present simply means adding
them
to the end of the existing php.ini, i.e. the same module can be listed
twice, once disabled and once enabled. Is there no way to do a search and
replace on the existing string or simply write that part of the file from
scratch? - because at present, people will still need to make manual
modifications to their .ini following installation, and it's confusing.
What I'll probably do is remove the extension directives from where
they normally are and keep them at the bottom; this is in line with
how many packages that edit the php.ini file work.
Yep good - note a few minor problems with layout though:
; Local Variables:
; tab-width: 4
; End:
[PHP_JSON]
extension=php_json.dll
- it shouldn't be after vi settings (simply write them last?), and
'extension' is not a PHP_JSON directive - it's a [PHP] directive and should
be part of the main clause.
5) is there - or will there be - a way to update components via the
installer? or even the core? (would mean disabling/deleting
non-compatible
components)
It will support upgrading from one PHP version to another, and will
upgrade the included components that come with that version.
That's very cool, but it also needs to check the version compatibility of
whatever PECL-only extensions happen to be loaded... otherwise there's a
chance they'll mysteriously stop working.
6) is there - or will there be - any way to set up the chosen server
configuration via the installer (for all servers or even just for
Apache?) -
again, I didn't test with a server install so this might be in place
already.
IIS CGI and Xitami will be configured automatically ( and we could add
Sambar to that list if there is interest ), but Apache uses a wierd
config file format that I don't have a good tool to edit.
httpd.conf's weird? It's only a text file :) the complication's in the fact
that there's more than one way to set it up. But you could offer automated
basic CGI setups pretty easily using the paths you've already been given for
php.exe and php.ini, and the module setup actually isn't that complicated
either, assuming you already know it's an apache module setup that's
required.
7) how about further php.ini modifications? - remembering that the
existence
of many directives depends on the extensions installed.
(These come under 'would be sweet if...')
We do many of these, such as enabling cgiforceredirect,
upload_tmp_dir, and session.save_path, along with adding Registry Keys
and Enviroment variables that are needed under Windows ( after install
try typing 'php -v' at the command line and it should find the PHP
install correctly ). I also register .php files to open with
php-win.exe if you install the 'Script Program' option.
Actually typing php -v and php -m was how I found out it was registered :)
Didn't know you'd set some of those options because I only tested a couple
of odd extensions to see how it was set up. That said, gd was one of those
extensions, and I didn't see an option to reset gd.jpeg_ignore_warning - did
you only look at directives involving paths for now?
Further comment: I personally think it creates more problems than it
solves
to differentiate between core and PECL extensions. IMHO it'd be better to
throw them all together in alphabetical order and simply have everything
'already on' that is enabled by default. This'll also help when items get
shifted around, as they inevitably do... components shipped with the core
that aren't yet in PECL would need to be downloaded with the core anyway
because there's no other way to reach them individually, so there _is_
that
difference, but that 'core list' is not writ in stone and changes quite
frequently.
I agree and disagree. While it will be simplier to install the
extensions, it would also be helpful to know which ones *are*
supported and which ones *are not*. I'd welcome any suggestions here.
Well, since there's no way to get that information anyway until you try to
download a .dll that doesn't exist or is incompatible with the version of
PHP you're running, I'd suggest trying to download a .dll and producing
error messages in those cases. Everything in PECL (that is released at all)
has a package.xml file that contains all sorts of useful information
regarding versioning, requirements and maintenance status... perhaps ask
Edin to supply that file via a channel that also supplies the .dll (where it
exists)? (Note: my understanding of channels is very, very hazy and I'm
probably sending you the wrong direction by even using the term, but Edin'll
know what I mean...)
oh ps - PEAR install yes/no doesn't appear to work - you get .phar either
way. Is that intentional for now?
WFM, can anyone else confirm this?
My bad, I didn't spot that it's enabled by default. Back to the TMI thing...
I honestly think you should split that page into separate serial pages for
a) the actual PHP install, b) the server stuff, c) the extensions, d)
peripherals (aka PEAR and docs). I'm not a naive user by any stretch of the
imagination, but I'm missing things all over the shop on that page.
- Steph
Thanks for the feedback....
--
Later,
John Mertic
"Explaining a joke is like dissecting a frog: you
[EMAIL PROTECTED] understand it
better, but the frog dies in the
process."
-Mark Twain
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
