Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Author info showing up incorrectly (small "s" instead of role). #505

Closed
morganestes opened this issue May 6, 2014 · 4 comments
Closed
Assignees
Labels

Comments

@morganestes
Copy link

I'm running 1.4.4 (just updated from 1.4.3 a few minutes ago) and see the big "WP" image in my Authors column with the author name as N/A. I also notice that many of my records show a small "s" under the Author name, where I expect to see their assigned role.

Looking through the stream_meta.meta_value records shows me that in every one of the "s" cases, the serialized data is cut off by the 200 varchar limit on that column. It doesn't matter what the actual role is, they all show up with <small>s</small> when the page is rendered.

stream-authors

Here's a redacted version of the data for the image, taking out identifying names and emails:

s:214:"a:5:{s:10:"user_email";s:21:"dsmith@example.com";s:12:"display_name";s:35:"David S. - ";s:10:"user_login";s:21:"dsmith@example.com";s:15:"user_role_label";s:7:"Sup
s:201:"a:5:{s:10:"user_email";s:27:"barryp@example.com";s:12:"display_name";s:7:"Barry P";s:10:"user_login";s:27:"barryp@example.com";s:15:"user_role_label";s:10:"Subscriber";s:5:"ag
@westonruter
Copy link
Contributor

I think this is the same issue as #477. The author_meta is not getting deserialized, and so since:

$author_meta === 's:214:"a:5:{s:10:"user_...'

Then attempting to get the author_role key of this string will cast the string to an integer, and so:

$author_meta['author_role'] === \
$author_meta[(int)'author_role'] === \
$author_meta[0] === 's'

So it is returning the initial character 's' in the serialized string.

@morganestes
Copy link
Author

I wondered if they might be related, but didn't want to hijack another issue just in case.

This explains the "s", but should I be concerned about the serialized string getting cut off?

@westonruter
Copy link
Contributor

@morganestes thanks!

So perhaps the quick fix is to maybe_unserialize() all the things. But I'm perplexed as to why deserialization fails on select installs, however. It's not either that the serialized data is malformed, because then false would be returned. Unless, perhaps, the is_serialized() check is itself returning false, in which case the raw string would be returned by maybe_unserialize() and so adding more maybe_unserialize() wouldn't help at all.

@shadyvb
Copy link
Contributor

shadyvb commented May 7, 2014

This will probably be fixed by work done in #515, related to #477 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants