Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After setting the default timezone in a installation profile or after refreshing the configuration page, there should be no timezone detection.
Comment | File | Size | Author |
---|---|---|---|
#11 | 1017020-install-timezone-detect.patch | 1.08 KB | tim-e |
#7 | install-timezone-detect-1017020-d7-7.patch | 1.32 KB | steinmb |
#6 | install-timezone-detect-1017020-6.patch | 1.26 KB | steinmb |
#3 | install-timezone-detect-1017020-3.patch | 1.28 KB | David_Rothstein |
#1 | install-timezone-detect-1017020-1.patch | 1.23 KB | David_Rothstein |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedYup, that makes sense. And it's basically what system.module already does for the timezone selection on user account pages.
How about this patch?
Comment #2
Jan_vStone CreditAttribution: Jan_vStone commentedSeems to fix the issue when you use variable_set('date_default_timezone') but not when using the _form_install_configure_form_alter hook. For that to work, the check if a default timezone has been selected should probably be done in the timezone.js javascript file.
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedI don't think there's any simple way for the timezone.js code to know who set the form element's default value or what their intention was.
However, we can switch to using #attached to add the JavaScript to the page, so that someone who wants to remove this in hook_form_alter() can do that more easily. That is done in the attached patch.
Comment #4
Jan_vStone CreditAttribution: Jan_vStone commentedThe solution/patch in #3 works with following code in form_alter (for future reference)
Comment #5
nod_Comment #6
steinmb CreditAttribution: steinmb commentedTime to re-roll patch.
Comment #7
steinmb CreditAttribution: steinmb commentedDrupal 7 backport. Tested with hook_form_alter() in a install profile and seemed to work perfect.
Comment #9
nod_Comment #10
cweagansFixing tags per http://drupal.org/node/1517250
Comment #11
tim-e CreditAttribution: tim-e commentedPatch for D7.
Comment #13
nod_Newt time, please end the name of your current patch with "do-no-test.patch" so that it won't mess up things, thanks :)
Comment #14
tim-e CreditAttribution: tim-e commentedoh, is that because this issue is 8.x ?
Comment #15
nod_yes :)
Comment #16
steinmb CreditAttribution: steinmb commented@tim-e Why did you remove comments in the D7 patch in #7? Do we not need them?
Comment #17
tim-e CreditAttribution: tim-e commentedThe patch in #7 didnt work for me since _install_configure_form() reinitialises $form_state['server_settings'] and so we lose the ['#attached'] element and timezone.js is still loaded regardless.
Comment #18
thyssimonis CreditAttribution: thyssimonis commentedIf you unset the #attributes the class timezone-detect is removed from the select and no timezone detecting will be run.
This wil work in D7
Comment #29
pameeela CreditAttribution: pameeela commentedAnyone know whether this is still valid in D9? Anyway needs a issue summary update with a bit more info and steps to reproduce.
Comment #30
longwaveThis looks to still be valid, the
core/drupal.timezone
library is attached to the site configuration form in the installer whether or not a timezone has already been selected.