Shouldn't changing a user's Drupal locale also change $user->timezone? - drupal

I must be missing something really obvious here:
I have a user whose locale is set to America/Los Angeles. When I look in the 'users' database table, they have a value of -28800 for the timezone field. This makes sense; 8 hours before GMT = -28800 seconds.
But now, when the user changes his locale to America/New York, the value of timezone stays the same, rather than switching to -18000, 5 hours before GMT. Why isn't this change happening? If I'm looking in the wrong place, where would I find a timezone value that matches their locale?
The server's timezone is also set to America/Los Angeles, if that matters. Thanks!

Sounds like a bug. What version of Drupal? Either way, you should be able to fix it fairly easily with hook_user. You'll need to do a user_save and explicitly define the new timezone value. It'd be something like this:
function trnAccount_user($op, &$edit, &$account, $category = NULL) {
switch($op) {
case 'update':
user_save($account, array('timezone' => $myTimeZone);
break;
}
$myTimeZone is a placeholder. Do a print_r on the incoming $edit within this hook and you should be able to find where the timezone change has been recorded then just replace $myTimeZone with that array path (for example... $edit['values']['timezone']). If its not coming through at all then something is wrong with the form you're using the change the locale.
If you're using a form you wrote yourself, you could also handle this in the submit function for that form.

ARGGH -- FALSE ALARM. Just as I was wrapping all this up, I thought it might be worth checking another of my Drupal sites to see what happens with $user->timezone there. Turns out that it's working correctly -- change the locale in the user edit page and $user->timezone changes as it ought to. Thus, I'm screwing the pooch somewhere in my current site; Drupal itself seems to be OK. Apologies for wasting your time; but many thanks in any case.

Related

Setting a global currency dropdown

I would like to setup a dropdown listing some currencies on all the pages of my website (Symfony 4.4).
The value set in this dropdown will then be used to adjust/convert the prices to the user's favorite currency.
I have been playing around some sessions parameters but it's not satisfactory. I feel like I need to place a hook in of the events, but I am not sure which event I should use.
I am thinking something like this
-- Request --
-- Event catcher --
If (currency not set in the session) then set currency to default (e.g. USD or EUR), I will probably base this on the user's locale
-- Send reply --
The tricky bit is to change the currency. I guess I need to set a route to change the session parameter and redirect to the current route.
I also thought about adding the currency in the route (which would be my favorite option), but I already have a language prefix (_locale) and I am not sure how I can apply multiple prefixes...
Thank you for any help or direction
For those interested, I ended up creating a Form that I called through a separate render query containing the new currency value and a redirect path to the current page.

CakePHP: FrozenTime from database without timezone

I'm on "Europe/Rome":
debug(new \Cake\I18n\Time());
Output:
object(Cake\I18n\Time) {
'time' => '2016-03-23T14:18:17+01:00',
'timezone' => 'Europe/Rome',
'fixedNowTime' => false
}
If I save a post (for example), the datatime is handled properly.
The problem occurs when I retrieve data. This post has been just saved:
debug($post->created);
Output:
object(Cake\I18n\FrozenTime) {
'time' => '2016-03-23T14:14:45+00:00',
'timezone' => 'UTC',
'fixedNowTime' => false
}
The datetime is correct, but the timezone of course not.
Now if I do something like this:
debug($post->created > new \Cake\I18n\Time());
the result will obviously be TRUE and not FALSE (as it should be). I conclude that this happens because, in comparison phase, it obviously uses the same timezone.
Where am I doing wrong? Thanks.
EDIT
My bootstrap.php
date_default_timezone_set('UTC');
Instead, my php.ini (I think it's not relevant):
date.timezone = Europe/Rome
So I have to think that the value of $post->created is correct.
But now... why new \Cake\I18n\Time() uses the correct timezone (which is not set) and why the post is saved with the correct timezone?
I would kinda doubt that new \Cake\I18n\Time() will use the timezone set in your INI after date_default_timezone_set() has been used, as the latter should win over the former. Maybe there's a version specific behavior/bug where this doesn't work as expected, not sure, you'll have to debug your environment to figure what's going on there.
That being said, when data is being read, the ORM casts it to PHP datatypes. The date/time type classes responsible for this are using cloned date/time class instances instead of creating new ones, and that base instance is created when the type instance is first built and/or when the mutability is being set, which usually happens at bootstrapping time when Type::build() is invoked.
If you'd then for example change the timezone at a later point, new \Cake\I18n\Time based instances would use the newly set timezone, but the date/time type would still use the instance that was created with the original timezone at bootstrapping time.
tl;dr
Set the proper timezone via date_default_timezone_set() in your bootstrap, and if you need to change the timezone at a later point, then you'll have to make sure that a new base type instance for cloning is being set, which could for example be done by setting the mutability again, like
Type::build('time')->useImmutable();
This feels kinda workaroundish though, you may want to open a ticket over at GitHub and report this behavior.

Fix serialized data broken due to editing MySQL database in a text editor?

Background: I downloaded a *.sql backup of my WordPress site's database, and replaced all instances of the old database table prefix with a new one (e.g. from the default wp_ to something like asdfghjkl_).
I've just learnt that WordPress uses serialized PHP strings in the database, and what I did will have messed with the integrity of the serialized string lengths.
The thing is, I deleted the backup file just before I learnt about this (as my website was still functioning fine), and installed a number of plugins since. So, there's no way I can revert back, and I therefore would like to know two things:
How can I fix this, if at all possible?
What kind of problems could this cause?
(This article states that, a WordPress blog for instance, could lose its settings and widgets. But this doesn't seem to have happened to me as all the settings for my blog are still intact. But I have no clue as to what could be broken on the inside, or what issues it'd pose in the future. Hence this question.)
Visit this page: http://unserialize.onlinephpfunctions.com/
On that page you should see this sample serialized string: a:1:{s:4:"Test";s:17:"unserialize here!";}. Take a piece of it-- s:4:"Test";. That means "string", 4 characters, then the actual string. I am pretty sure that what you did caused the numeric character count to be out of sync with the string. Play with the tool on the site mentioned above and you will see that you get an error if you change "Test" to "Tes", for example.
What you need to do is get those character counts to match your new string. If you haven't corrupted any of the other encoding-- removed a colon or something-- that should fix the problem.
I came to this same problem after trying to change the domain from localhost to the real URL. After some searching I found the answer in Wordpress documentation:
https://codex.wordpress.org/Moving_WordPress
I will quote what is written there:
To avoid that serialization issue, you have three options:
Use the Better Search Replace or Velvet Blues Update URLs plugins if you can > access your Dashboard.
Use WP-CLI's search-replace if your hosting provider (or you) have installed WP-CLI.
Run a search and replace query manually on your database. Note: Only perform a search and replace on the wp_posts table.
I ended up using WP-CLI which is able to replace things in the database without breaking serialization: http://wp-cli.org/commands/search-replace/
I know this is an old question, but better late than never, I suppose. I ran into this problem recently, after inheriting a database that had had a find/replace executed on serialized data. After many hours of researching, I discovered that this was because the string counts were off. Unfortunately, there was so much data with lots of escaping and newlines and I didn't know how to count in some cases and I had so much data that I needed something automated.
Along the way, I stumbled across this question and Benubird's post helped put me on the right path. His example code did not work in production use on complex data, containing numerous special characters and HTML, with very deep levels of nesting, and it did not properly handle certain escaped characters and encoding. So I modified it a bit and spent countless hours working through additional bugs to get my version to "fix" the serialized data.
// do some DB query here
while($res = db_fetch($qry)){
$str = $res->data;
$sCount=1; // don't try to count manually, which can be inaccurate; let serialize do its thing
$newstring = unserialize($str);
if(!$newstring) {
preg_match_all('/s:([0-9]+):"(.*?)"(?=;)/su',$str,$m);
# preg_match_all("/s:([0-9]+):(\"[^\"\\\\]*(?:\\\\.[^\"\\\\]*)*\")(?=;)/u",$str,$m); // alternate: almost works but leave quotes in $m[2] output
# print_r($m); exit;
foreach($m[1] as $k => $len) {
/*** Possibly specific to my case: Spyropress Builder in WordPress ***/
$m_clean = str_replace('\"','"',$m[2][$k]); // convert escaped double quotes so that HTML will render properly
// if newline is present, it will output directly in the HTML
// nl2br won't work here (must find literally; not with double quotes!)
$m_clean = str_replace('\n', '<br />', $m_clean);
$m_clean = nl2br($m_clean); // but we DO need to convert actual newlines also
/*********************************************************************/
if($sCount){
$m_new = $m[0][$k].';'; // we must account for the missing semi-colon not captured in regex!
// NOTE: If we don't flush the buffers, things like <img src="http://whatever" can be replaced with <img src="//whatever" and break the serialize count!!!
ob_end_flush(); // not sure why this is necessary but cost me 5 hours!!
$m_ser = serialize($m_clean);
if($m_new != $m_ser) {
print "Replacing: $m_new\n";
print "With: $m_ser\n";
$str = str_replace($m_new, $m_ser, $str);
}
}
else{
$m_len = (strlen($m[2][$k]) - substr_count($m[2][$k],'\n'));
if($len != $m_len) {
$newstr='s:'.$m_len.':"'.$m[2][$k].'"';
echo "Replacing: {$m[0][$k]}\n";
echo "With: $newstr\n\n";
$str = str_replace($m_new, $newstr, $str);
}
}
}
print_r($str); // this is your FIXED serialized data!! Yay!
}
}
A little geeky explanation on my changes:
I found that trying to count with Benubird's code as a base was too inaccurate for large datasets, so I ended up just using serialize to be sure the count was accurate.
I avoided the try/catch because, in my case, the try would succeed but just returned an empty string. So, I check for empty data instead.
I tried numerous regex's but only a mod on Benubird's would accurately handle all cases. Specifically, I had to modify the part that checked for the ";" because it would match on CSS like "width:100%; height:25px;" and broke the output. So, I used a positive lookahead to only match when the ";" was outside of the set of double quotes.
My case had lots of newlines, HTML, and escaped double quotes, so I had to add a block to clean that up.
There were a couple of weird situations where data would be replaced incorrectly by the regex and then the serialize would count it incorrectly as well. I found NOTHING on any sites to help with this and finally thought it might be related to caching or something like that and tried flushing the output buffer (ob_end_flush()), which worked, thank goodness!
Hope this helps someone... Took me almost 20 hours including the research and dealing with weird issues! :)
This script (https://interconnectit.com/products/search-and-replace-for-wordpress-databases/) can help to update an sql database with proper URLs everywhere, without encountering serialized data issues, because it will update the "characters count" that could throw your URLs out of sync whenever serialized data occurs.
The steps would be:
if you already have imported a messed up database (widgets not
working, theme options not there, etc), just drop that database
using PhpMyAdmin. That is, remove everything on it. Then export and
have at hand an un-edited dump of the old database.
Now you have to import the (un-edited) old database into the
newly created one. You can do this via an import, or copying over
the db from PhpMyAdmin. Notice that so far, we haven't done any
search and replace yet; we just have an old database content and
structure into a new database with its own user and password. Your site will be probably unaccessible at this point.
Make sure you have your WordPress files freshly uploaded to the
proper folder on the server, and edit your wp-config.php to make it
connect with the new database.
Upload the script into a "secret" folder - just for security
reasons - at the same level than wp-admin, wp-content, and wp-includes. Do not forget to remove it all once the search and
replace have taken place, because you risk to offer your DB details
open to the whole internet.
Now point your browser to the secret folder, and use the script's fine
interface. It is very self-explanatory. Once used, we proceed to
completely remove it from the server.
This should have your database properly updated, without any serialized data issues around: the new URL will be set everywhere, and serialized data characters counts will be accordingly updated.
Widgets will be passed over, and theme settings as well - two of the typical places that use serialized data in WordPress.
Done and tested solution!
If the error is due to the length of the strings being incorrect (something I have seen frequently), then you should be able to adapt this script to fix it:
foreach($strings as $key => $str)
{
try {
unserialize($str);
} catch(exception $e) {
preg_match_all('#s:([0-9]+):"([^;]+)"#',$str,$m);
foreach($m[1] as $k => $len) {
if($len != strlen($m[2][$k])) {
$newstr='s:'.strlen($m[2][$k]).':"'.$m[2][$k].'"';
echo "len mismatch: {$m[0][$k]}\n";
echo "should be: $newstr\n\n";
$strings[$key] = str_replace($m[0][$k], $newstr, $str);
}
}
}
}
I personally don't like working in PHP, or placing my DB credentials in an public file. I created a ruby script to fix serializations that you can run locally:
https://github.com/wsizoo/wordpress-fix-serialization
Context Edit:
I approached fixing serialization by first identifying serialization via regex, and then recalculating the byte size of the contained data string.
$content_to_fix.gsub!(/s:([0-9]+):\"((.|\n)*?)\";/) {"s:#{$2.bytesize}:\"#{$2}\";"}
I then update the specified data via an escaped sql update query.
escaped_fix_content = client.escape($fixed_content)
query = client.query("UPDATE #{$table} SET #{$column} = '#{escaped_fix_content}' WHERE #{$column_identifier} LIKE '#{$column_identifier_value}'")

CMS links on frontend not converting ie href=[sitetree_link_id=xx]

An issue has been noticed on one of our old sites running 2.4 where when the user creates a link in the CMS content, selecting an existing page to link to, the link is not being converted to the actual URL on the front end and all links are coming through in the format of <a href="[sitetree_link_id=12]">
What would be causing this and how do I fix it?
The tag looks like it's being set incorrectly. It should be [sitetree_link id=12], not [sitetree_link_id=12].
We later added support to the parser for [sitetree_link,id=12] so that links didn't need to contain spaces, but I can't recall if that's in 2.4 or only 3.0+.
Can you confirm that your WYSIWYG insertion is putting in that errant _? If so, you might want to checkout the handleaction_insert function in tiny_mce_imporvements.js to confirm that it has a line like so:
case 'internal':
href = '[sitetree_link id=' + this.elements.internal.value + ']';
If the inserted links don't actually have the errant _ but they aren't being parsed, then try checking your sapphire/_config.php file for this:
ShortcodeParser::get('default')->register('sitetree_link', array('SiteTree', 'link_shortcode_handler'));
If your site makes changes to the ShortcodeParser at all you might have inadvertently turned off sitetree_link support.
If all of that looks in order, perhaps the ShortcodeParser isn't being called for some reason. In HTMLText::forTemplate(), put a debug statement (I like die("I got here!");) to confirm that HTMLText::forTemplate() is actually getting called. If it's not, you might need to manually call it in some pre-processing of your Content variable. Instead of this:
$content = $this->Content;
Do this:
$content = $this->obj('Content')->forTemplate();
I hope that one of those answers help. Either way, it would be great if you could post back, so we could isolate what caused this. It might help us make the API easier to use in SilverStripe 3.1.

change user_profile_form form fields order

When a user login , the user will be redirect to a user profile page, which has a My account field set.
the field set has 2 fields, "Username: ", "Email address:". those 2 fields are generated by drupal.
those 2 field contained in a form which has a id ("user_profile_form") . I want to change the order of those 2 fields.
I have tried to intercept 'user_profile_form' , inside hook_form_alter.
code as follow:
$form['account']['name']['#weight'] = 1;
but that did not success, drupal did not even rendering the 'name' field, so no username: showed on browser.
What you did is absolutely correct, and probably did work. You can change the weight of the fields with the method described above.
The username field is not always rendered. The reason is that a persmission is required: change own username. If that perm is not set, you wont be allowed to alter you username and the field wont be shown.
Info on debugging.
Your info alone is not quite enough to debug. From what you describe, you are doing the right thing, but other modules could be making things a bit tricky for you. The devel module is quite good when it comes to debugging, ti defines two functions I use a lot when debugging:
dpm() pretty prints the variable to the message area using krumo.
dd() Prints / saves a variable to a log file. Useful when you can't view messages on the screen.
I would suggest that you look at the $form variable before and after you alter it.
Things that could make it go wrong:
Did you remember to pass the $form variable by reference using the & notation?
Is another module altering your form after you?
Are you checking for the correct form id, so you alter the correct form?
These are some pointers, before you bring more info, all I can do is guess to what your problem exactly can be. I did something like this a few days ago so I know what you describe shouldn't be a problem.

Resources