this can either happen uncoditional or with an SQL statement checking they are empty first:
$setup_info[wiki][autodeinstall] = "SELECT COUNT(*)<=3 FROM egw_wiki_pages";
which would deinstall wiki if it has only the 3 default pages in it
Was caused by (unnecessary) transaction around defaul_records processing, causing during transaction inserted rows where not (yet) commited and therefore could not be read.
- changing config in setup did not update or unset the cache --> instance was NOT using it
- new installs failed, because cache was not configured
- cache command to not configured cache gave fatal error, now they throw a (catchable) exception
- fixed not working vfs-image-dir
- deleteing image-maps when:
+ apps get installed, updated or removed
+ admin >> register hooks
+ admin >> site configuration: vfs-image-dir get changed
- fixed not displayed validation errors (thought there were no validation) in admin >> site config
--> you need to register hooks, in order to get the admin >> site configuration validation hook ;-)
- DB schema update for account_pwd to varchar(128) to accomodate sha512_crypt hashes
- enable automatic migration to sha512_crypt, if on SQL or LDAP (but only on Linux, as OpenLDAP has not native support for it)
installation time --> nice user experience and cleaner look (by hiding
exotic prefs by focing them to a usual value):
- settings returned from settings hook can contain values for keys
'default' or 'forced'
- if settings hook require part of api or application, which are not
available during installation time: use a method hook (instead of
an old $app/inc/hook_settings.inc.php file), and check if
$hook_param['setup'] is true
- default prefs created so far in setup/admin_account.php got removed
- common prefs in preferences_hooks::settings() got reworked to set
default and forced prefs
- calendar prefs in calendar_hooks::settings() got reworked to set
default and forced prefs
--> I will rework prefs of all our (default) applications according to a
best practice list of Stylite consultants
- cleaned up exceptions in cli code (no need to log, as it goes direct to the user)
- regarding small rpm redirect header (< 200 bytes) as no header
- fixed wrong detected vars for cli install (eg. webserver_url)
- fixed egw_cache to not stall if system_charset is not yet in db
- add feature to allow apps to choose to be automatic installed on
updated: $setup_info[$app]['autoinstall'] = {true|'1.x.xxx'};
- run default_records.inc.php (if exists) also for apps without tables,
as they might need to initialise some stuff
- create, edit & update the header
- install & update eGW
- config eGW
- create admin account
- install & update languages
- create & restore (install) backups
---> update, languages & backup can work for all domains at once
---> for use in 1.2 you have to update/switch the whole setup app to HEAD/trunk
+ setup_demo gives errors under postgres
+ setup_demo can save special chars in the admin name
- renamed setup_demo into admin_account, as setting up demo accounts is the least used function of it
- fixed warning db::delete missing params, if delete_all was checked
1) phpgw_lang(uages) --> egw_lang(uages)
2) mysql 4.0+
- charset gets now set for the connect
- charset gets used for new tables
- some columns shortend to deal with 1000byte (= 333 utf-8 chars) limit for indexes
- update to 1.0.1.019 fixes the charset of existing tables
- phpgw_accounts --> egw_accounts
- phpgw_acl --> egw_acl
- phpgw_log(_msg) --> egw_log(_msg)
- phpgw_config --> egw_config
- phpgw_applications --> egw_applications
This requires code-changes in many apps. Quite often I was able to replace the db access, with calls to the appropreate classes.
2) $GLOBALS['phpgw{_info}'] ==> $GLOBALS['egw{_info}']
3) moved setup-classes from phpgwapi/inc back to setup/inc (they are not used anywhere else, but in setup)
