I'm getting the following error messages when I run update.php (updating from 6.20)
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2068) in drupal_send_headers() (line 1044 of /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc).
* Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID '-14400' is invalid in drupal_session_initialize() (line 262 of /home/content/p/w/a/pwarwick/html/includes/session.inc).
* Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID '-14400' is invalid in drupal_session_initialize() (line 262 of /home/content/p/w/a/pwarwick/html/includes/session.inc).
The first message is new ... on previous executions of update.php (which also failed) I got the timezone messages. On this attempt I get the extra message.
Comment | File | Size | Author |
---|---|---|---|
#22 | 1006838-upgrade-timezone-warning-22.patch | 2.05 KB | coltrane |
#18 | 1006838-upgrade-timezone-warning-18.patch | 2.44 KB | coltrane |
#15 | 1006838-upgrade-timezone-warning-15.patch | 1.79 KB | coltrane |
#12 | 1006838-upgrade-timezone-warning-MAKE-IT-FAIL.patch | 960 bytes | coltrane |
#6 | 1006838-upgrade-timezone-warning-6.patch | 872 bytes | coltrane |
Comments
Comment #1
Patricia_W CreditAttribution: Patricia_W commentedI investigated the timezone problem and for user 1 in the Users table the timezone is (as noted above) -14400. Presumably this was valid for Drupal 6 but is not now. It is a varchar(8) variable so I could not change it to something like America/Toronto. I modified bootstrap.inc to hardcode the variable to "America/Toronto" and I do not get that error again.
Now, when I run update.php the first time I get a blank page, the second time I get:
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in drupal_send_headers() (line 1044 of /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc).
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in install_goto() (line 1046 of /home/content/p/w/a/pwarwick/html/includes/install.inc).
* Warning: Cannot modify header information - headers already sent by (output started at /home/content/p/w/a/pwarwick/html/includes/bootstrap.inc:2070) in install_goto() (line 1047 of /home/content/p/w/a/pwarwick/html/includes/install.inc).
Comment #2
TallDavid CreditAttribution: TallDavid commentedI'm also getting this notice on a site being upgraded from 6.19=>7.0-rc3:
Note to self: aft.c
Comment #3
coltraneAlso experiencing this ugly message when upgrading.
I wonder if suppression is adequate. Note, this notice was mentioned in #785184: Attempts to update a D6.16 site to D7
Comment #4
coltraneHere's a patch which checks if the maintenance mode is in update before trying to get the user's timezone.
Comment #5
coltraneMAINTENANCE_MODE isn't always defined so the patch in #4 causes notices on standard pages.
To clarify this issue:
Problem:
During an upgrade to 7 the user's timezone is still in an offset at the initial pages of update.php. It's not until user_update_7002() that it gets converted.
Solution:
A possible solution would be to only return the user's stored timezone from
drupal_get_user_timezone()
when not in update.php.Comment #6
coltraneThis patch adds a check if MAINTENANCE_MODE is not defined before returning the current users timezone.
This can only be tested on update.php when upgrading from Drupal 6 to 7.
Comment #7
smscotten CreditAttribution: smscotten commentedThe patch is the right way to go about this, but I just set my user 1's timezone to "0" and figured I'd change it back when I was done. That made the messages go away. Solution offered for other lazy bums like me.
Comment #8
chx CreditAttribution: chx commentedComment #9
smscotten CreditAttribution: smscotten commentedPatch works for me when applied to RC4. (And yes, I set my timezone back to -25200 before I tested.)
Comment #10
smscotten CreditAttribution: smscotten commented...and I had no troubles with this patch on 7.x-dev either.
Comment #11
coltraneHmmn, how to test this.
It's impossible, I think, to test the upgrade process, but we could try and replace $user->timezone with an offset before DRUPAL_BOOTSTRAP_SESSION to cause the error to appear on a standard page.
I'll see where I can get with that.
Comment #12
coltraneActually, the test method in #11 seems really hard to do and it turns out there is an upgrade path test!
And in fact we can trigger the error in the basic upgrade path test if the users created in the base database have a timezone set. So, this patch does this, and it will fail! muaahahahah
Comment #13
coltraneComment #15
coltraneOn http://qa.drupal.org/pifr/test/119654 you can see the timezone warning. This patch includes a proposed fix.
Comment #16
chx CreditAttribution: chx commentedThat looks nice & the test is somewhat along the lines of what I thought though I did not hope for such a small patch :)
Comment #17
webchickWelllll, hold up now.
I really do not like comments like this:
in a general-purpose API function in bootstrap.inc.
And the actual fix:
Seems to imply that if I put my site in maintenance mode, the time on all nodes is going to change to whatever the site/server timezone is set, which would be extremely jarring were I to live in, say, Japan, and have a site hosted in the US. We'll get support requests about that for sure, since Drupal seems buggy.
Is there not any way to hack around this from update.php/update.inc?
Comment #18
coltraneGreat points webchick, thanks.
Try this patch, which temporarily disables configurable timezones in update.php so as to use the site-wide timezone for session initialization.
I'm not sure if this would still cause a problem like "the time on all nodes is going to change to whatever the site/server timezone is set, which would be extremely jarring were I to live in, say, Japan, and have a site hosted in the US."
If we're saving nodes during update.php shouldn't it not use the currently logged in user's timezone if they aren't the author of the nodes? In other words, should we be worried about this, is it likely to happen?
Comment #19
bryancasler CreditAttribution: bryancasler commented#18's patch worked for me
Comment #20
chx CreditAttribution: chx commenteddo we really need to write back into the DB? won't globals['conf'] instead of variable_set suffice?
Comment #21
Damien Tournoud CreditAttribution: Damien Tournoud commentedAgreed with #20. Let's reroll and get this in.
Comment #22
coltraneThat makes sense, thanks for pointing it out.
Comment #23
Damien Tournoud CreditAttribution: Damien Tournoud commentedYay.
Comment #24
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.