[geeklog-devel] Web Installer and integrated online config testing

[Blaine Lang]

I just completed an install on my hosted UNIX server of the latest CVS 
code where the system related files outside of webroot.

The install worked (as expected) without editing of a single GL file 
(which was our goal). The install prompted me initially for the path to 
the db-config.php where we will store the DB access and security related 
config settings.

Next it nicely showed me any folders that i need to change permissions 
for. I also had the big "Install" or "Upgrade" buttons and I did not try 
forcing past the directory perm settings - so I am not sure if it would 
have proceeded. I think we may NOT want to show a user these buttons 
until they have the directory permissions set correctly - even though 
most of the directories will not effect the installation but some will.

It complained the logs folder was not 777 even after I ensured it was. 
It continued to report it was 775 until I changed the 3 log files in the 
folder to 777 so thats and issue to fix and identify the files within 
the logs folder.

Instead of the "Install" "Upgrade" buttons at this point, we should have 
a button labeled "Re-check Permissions" as some users may or may not 
know to use refresh. We are targeting the new installer at a non-techie.

After that it all went smooth and the site came up.

We should have <?> help links for each of the fields in the main setup 
form once install is pressed. These would link to a single HTML file 
with linked anchors.

Should we still leave an admin/install/install.php stub that redirects 
to admin/install/index.php ?
Maybe even have public/index.php redirect to the admin/install/index.php 
if the site has not been installed yet.


Online Config Feedback:

- Error doing "Save Changes" in the config manager
 > Invalid argument supplied for foreach() @ 
/home/bl248/geeklog_systemfiles/system/classes/config.class.php line 471

Line :     foreach ($this->config_array as $param_name => $param_value) {
$this->config_array is null

- Suggest we remove the 'Core' Tab which is designed to support multiple 
plugins or other components that want to hook into the online config 
manager.
- Suggest we use a selectbox to select which component to administrate 
the configuration for. I don't like the dual tabbed navbar - atleast not 
if it's the same style and think a basic selectbox would be more 
appropriate. Still it should not be shown if there is only 1 config 
module -as the default GL is.
- Re-order the Config tabs so more important config settings are first
  > Site, Language and Local, Users, Images, Miscellaneous, Theme, 
Topics and Daily Digest, Story

I am not a fan of the (X) idea to reset an config item or disable it. 
Most config items should never be disabled but yes an option to reset to 
default would be handy. Some settings like the copywrite notice, a 
siteadmin may want to disable - but why not just set to NULL and any 
site code checks for that if its appropriate. I think disabling a 
setting or removing it from the $_CONF should not be done and may break 
other code. Any use where optionally a setting like copywrite could be 
disabled can just check for a NULL or '' in the setting.

Can you add comments to your JS code in the configuration.thtml - we can 
figure it out but comments will help.
If you don not need to dynamically alter the JS code by using template 
variables, then I suggest pulling the JS code out of the template and 
place the JS in the /javascript folder and use an include to pull it 
into the template. Makes the template easier to manage since really this 
is would be done by themers and not coders.

For the devel list: our focus for the SOC project was on creating a very 
flexible config class integrated into the new web-based installer. 
Having said that we needed a working UI and Aaron has done a nice job in 
creating a flexible set of classes for the UI and we now have an online 
configuration editor.


Regards,
Blaine