only if you select more then one timezone to display in it)
- moved generation of beautified timezone array to egw_time
- moved all preferences hooks to a new class preferences_hooks (updated
version so setup updates hook data, or you need to call admin>>update
hooks)
--> recogniced it's so old and dusty, it does not make sense any more
--> moved content_header() method to html class
- fixed calls of browser->content_header to use html::content_header
instead
calendar, plus a first calendar implemenation.
This implementation just replaces following calendar_bo methods:
- date2ts($date,$user2server=False)
- date2array($date,$server2user=False)
- date2string($date,$server2user=False,$format='Ymd')
- format_date($date,$format='')
which static methods from egw_time.
If your server is in same timezone as the user, you should experience no
difference. As a small test, you can switch to an other timezone (eg.
UTC) to recognice on a weekly repeating event (which still repeats on
equal server time!) that it moves by one hour when daylight saving
changes. This switching to a TZ with different daylight saving rules,
was not working before.
Happy testing :-)
WebDAV RFC 4918 allows a full url or a path as <D:href>:
http://www.webdav.org/specs/rfc4918.html#ELEMENT_href
Some clients can NOT deal with one or the other:
- KAddressbook (at least in 3.5) can NOT subscribe to addressbooks (it
does not find them) if just a path is used
- iCal in OS X 10.6 generates wrong requests, if a full url is used
register cookies in $_REQUEST any more by default (there's now a php.ini
variable 'request_order' to controll that, but we want to work with a
default configuraltion):
- session restore was not working, as only $_REQUEST[sessionid] was checked
- multi domain installs not working, as domain cookie was not checked
- encrypted session were not working, because kp3 cookie was not checked
--> there's now a static method egw_session::get_request($name), which
checks $_REQUEST[$name], $_COOKIE[$name] and for that Safari bug also
$_COOKIE[ucfirst($name)]
--> overcome problem reported by krupka(at)depag.de on the german list: password get's lost if contact get saved, because it had to remove the account first to add the addressbook object classes
- docu update
"
- when updating all langs, do a transaction for each lang and update the cache after commiting the transaction (before the transaction was about all langs and the cache update withint the not commited transaction)
- fixed problem with autoloading of languages, check used filectime, update used filemtime, which can differ of cause"
- update the tree-level cache, as we can not effectivly unset it in a multiuser enviroment,
as users from other - not yet updated - instances update it again with an old version!
- add_app(): we have to use array_merge! (+= does not overwrite common translations with different ones in an app)
array_merge messes up translations of numbers, which make no sense and should be avoided anyway.
"
