Re: [Phpgroupware-users] rc3 demo-installation at http://de.demos.phpgroupware.org

[Marcus Frischherz]

I'd be happy to supply all info needed to address this problem, it's 
just, that so far noone has aked more info than the opsys and PHP Apache 
versions. Whom should I send the table dump?

btw: After my first very frustrated message I continued playing, and I 
found out, that after I turned off the info array caching (for another 
reason, I found this hint concerning the display of the correct version 
on the logon screen in the FAQ), thinks looked considerably better. At 
least I am now ablw to store most new preferences most of the time. 
Before it was nada and never.

My main reason for upgrading are the calender alarms, I really would 
like to have them, and they work.

Unfortunately I can't get e-mail to work. Something is broken with the 
authentication (I use U-washington imapd), it worked fine in 0.9.14. And 
I don't get the e-mail to the other attendees of an event anymore, they 
also used to work fine (maybe related to e-mail not working). btw... 
where is the e-mail password stored? In the phpgw_anglemail table?

Question: FAQ seems to indicate that starting from rc1 one _should_ turn 
off register_global, and this is also repeated in the documentation, so 
I did it. However, in the setup/manage applications I have underneath 
the name of each application the line "register_globals = on", what's 
that supposed to mean? Should I turn on?

And I have another problem there (with my rc3 tarball + cvs update):
"infolog-Post-install Dependency Failure:(appname: phpgwapi; versions: 
0.9.13,0.9.14,0.9.15,0.9.16; appname: etemplate; versions: 
0.9.15,0.9.16; ))P -" is that a problem?

Marcus

Chris Weiss wrote:

> Marcus Frischherz (address@hidden) wrote:
>  
>
> > I filed this already 11/24/03 as bug #6739, and it is still open. This
> > kind of surprises me. Do phpgw developpers expect that everyone cleans
> > out their database when upgrading the versions?
> >
> >    
>
> consider the possibility that you're the only one with the problem, possibly
> due do some user data in the prefs causing the prefs update to not work
> cleanly.  Please check your original prefs table for data that might not be
> escaping properly or is too long to fit into the new table structure.  Or, if
> possible, dump the table and clean any sensitive data out, replacing with X's
> to keep the data the same length (serialization cares about length), but leave
> in anything that's not plain ol' letters and numbers.  This way someone can
> run it in debug and hopefully figure out what's causing it to fail.
>
>
>
> _______________________________________________
> Phpgroupware-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-users
>