[geeklog-devel] Integrated Web Installer and Online Config Feedback
Blaine Lang
devel at portalparts.com
Sat Sep 1 14:45:12 EDT 2007
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
More information about the geeklog-devel
mailing list