Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
7381
Features / Re: New revs
« on October 17th, 2011, 04:36 PM »
rev 1115
(2 files, 6kb)
* Improved year trimming code in timeformat() to account for more possible time formats. (Subs.php)
- Removed another $txt['time_am/pm'] reference. (Subs.php)
- Removed another OpenID reference. (upgrade.sql)
(2 files, 6kb)
* Improved year trimming code in timeformat() to account for more possible time formats. (Subs.php)
- Removed another $txt['time_am/pm'] reference. (Subs.php)
- Removed another OpenID reference. (upgrade.sql)
7382
Off-topic / Re: The larger topic on your forum...
« on October 17th, 2011, 02:45 PM »
Here: 1115 posts for the New Revs topic... (One per commit :P)
Noisen: 3 topics over 1000 posts, but not by much.
Cynarhum (my very old, first forum, back when I only posted and did no dev work...): 3 topics over 5000, 10 topics at 3000 or more, and the largest has close to 8000 posts. I have 32k posts myself on that board.
I'd be interesting to have, instead, an average number of posts per topic... For instance, sm.org would have a low average, with regards to their 3M posts but their largest topic only has something like 15k posts... ;)
Noisen: 3 topics over 1000 posts, but not by much.
Cynarhum (my very old, first forum, back when I only posted and did no dev work...): 3 topics over 5000, 10 topics at 3000 or more, and the largest has close to 8000 posts. I have 32k posts myself on that board.
I'd be interesting to have, instead, an average number of posts per topic... For instance, sm.org would have a low average, with regards to their 3M posts but their largest topic only has something like 15k posts... ;)
7383
Features / Re: New revs - Public comments
« on October 17th, 2011, 12:22 PM »
I believe there are a few items remaining from the OpenID code... Not a lot really. Just a few lines.
Just search for 'authenticate' (single word) and 'auth_method'. Because the authentication method is only 'password' now, the variable is useless.
As always, I would remove it myself but it may serve as a future hook point to plug OpenID and Facebook into the system so I'm leaving up to you to decide whether to remove these or not, Pete.
On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
(I've already transformed all three set types.)
Code: [Select]
Then we just need to add a hook passing $select_columns and $select_tables as parameters and voilà, we have an often modified area that becomes very easy to hook into.
(Obviously, the code is adapted to fit the array format.)
Right after the set building, I added this hook:
call_hook('load_member_data', array($set, &$select_columns, &$select_tables, &$users, &$is_name));
The performance difference is barely noticeable even with benchmarking -- about 5 to 10% slower on a code block that takes less than a millisecond to execute, MySQL call included... So it would make sense to make it easier to modify.
I've added the hook to the ManagePlugins array as well.
Just wanna know if everything's in order... If you don't like it, please tell me so that I revert these changes before my next commit ;)
Oh, I'm also considering adding a 'process_member_data' hook AFTER the query, but my main problem is that I don't know WHERE exactly to put it... Right after the query? Right before the final 'return'? Somewhere in between...? Suggestions welcome!
One other thing I'm looking into is loadMemberContext()... It's really heavy.
Moreover, it crams pretty much everything it can into the various arrays, but it's not always used.
For instance, Memberlist calls it for every single name in the list, but it only shows a subset of the data.
Okay, I can live with that... I can live with the multiple calls to censorText and other preg_replaces.
But I have a hard time with the signature parsing.
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!
And while we're at it -- I think it'd make sense to also have a param saying whether we want the member link to use group colors. They're not used in many areas and I'm not sure why. Actually, it could even make sense to always use the group colors. They're loaded at this point... Even in the topic pages it would make sense to show group colors (although I'm not sure about that.)
More things to get rid of...
- $txt['profile_of'] is used in things like $memberContext as a title. I'd rather have it say just 'View profile' than 'View profile of...' followed by a name that is *already* in the link... Totally silly. Plus, we already have $txt['profile_of_username'] which is correctly handled by a more logical sprintf.
Opinions?
- $txt['time_am'] and $txt['time_pm']... They were removed in rev 1071, but they're actually still being used in timeformat()...! They were used twice in the function, and only one occurrence got removed. It doesn't generate an error because it's only being called when $non_twelve_hour is set to true, i.e. the server doesn't support the '%p' parameter in time formatting. I'd suggest simply replacing them with 'am' and 'pm'... (Note, though: %p will usually use AM and PM, in uppercase. I don't know which is the better one. I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])
Code: [Select]
PS, sorry for the huge post Pete... :^^;:
I'll take a break now.
Just search for 'authenticate' (single word) and 'auth_method'. Because the authentication method is only 'password' now, the variable is useless.
As always, I would remove it myself but it may serve as a future hook point to plug OpenID and Facebook into the system so I'm leaving up to you to decide whether to remove these or not, Pete.
On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
(I've already transformed all three set types.)
if ($set == 'normal')
{
$select_columns = array(
'IFNULL(lo.log_time, 0) AS is_online', 'IFNULL(a.id_attach, 0) AS id_attach', 'a.filename', 'a.attachment_type',
'mem.signature', 'mem.personal_text', 'mem.location', 'mem.gender', 'mem.avatar', 'mem.id_member', 'mem.member_name',
'mem.real_name', 'mem.email_address', 'mem.hide_email', 'mem.date_registered', 'mem.website_title', 'mem.website_url',
'mem.birthdate', 'mem.member_ip', 'mem.member_ip2', 'mem.posts', 'mem.last_login', 'mem.id_post_group', 'mem.lngfile',
'mem.id_group', 'mem.time_offset', 'mem.show_online', 'mem.media_items', 'mem.media_comments', 'mem.buddy_list', 'mem.warning',
'mg.online_color AS member_group_color', 'IFNULL(mg.group_name, {string:blank}) AS member_group',
'pg.online_color AS post_group_color', 'IFNULL(pg.group_name, {string:blank}) AS post_group', 'mem.is_activated',
'CASE WHEN mem.id_group = 0 OR mg.stars = {string:blank} THEN pg.stars ELSE mg.stars END AS stars'
);
if (!empty($modSettings['titlesEnable']))
$select_columns[] = 'mem.usertitle';
$select_tables = array(
'LEFT JOIN {db_prefix}log_online AS lo ON (lo.id_member = mem.id_member)',
'LEFT JOIN {db_prefix}attachments AS a ON (a.id_member = mem.id_member)',
'LEFT JOIN {db_prefix}membergroups AS pg ON (pg.id_group = mem.id_post_group)',
'LEFT JOIN {db_prefix}membergroups AS mg ON (mg.id_group = mem.id_group)'
);
}Then we just need to add a hook passing $select_columns and $select_tables as parameters and voilà, we have an often modified area that becomes very easy to hook into.
(Obviously, the code is adapted to fit the array format.)
Right after the set building, I added this hook:
call_hook('load_member_data', array($set, &$select_columns, &$select_tables, &$users, &$is_name));
The performance difference is barely noticeable even with benchmarking -- about 5 to 10% slower on a code block that takes less than a millisecond to execute, MySQL call included... So it would make sense to make it easier to modify.
I've added the hook to the ManagePlugins array as well.
Just wanna know if everything's in order... If you don't like it, please tell me so that I revert these changes before my next commit ;)
Posted: October 17th, 2011, 11:32 AM
Oh, I'm also considering adding a 'process_member_data' hook AFTER the query, but my main problem is that I don't know WHERE exactly to put it... Right after the query? Right before the final 'return'? Somewhere in between...? Suggestions welcome!
Posted: October 17th, 2011, 11:40 AM
One other thing I'm looking into is loadMemberContext()... It's really heavy.
Moreover, it crams pretty much everything it can into the various arrays, but it's not always used.
For instance, Memberlist calls it for every single name in the list, but it only shows a subset of the data.
Okay, I can live with that... I can live with the multiple calls to censorText and other preg_replaces.
But I have a hard time with the signature parsing.
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!
And while we're at it -- I think it'd make sense to also have a param saying whether we want the member link to use group colors. They're not used in many areas and I'm not sure why. Actually, it could even make sense to always use the group colors. They're loaded at this point... Even in the topic pages it would make sense to show group colors (although I'm not sure about that.)
Posted: October 17th, 2011, 11:56 AM
More things to get rid of...
- $txt['profile_of'] is used in things like $memberContext as a title. I'd rather have it say just 'View profile' than 'View profile of...' followed by a name that is *already* in the link... Totally silly. Plus, we already have $txt['profile_of_username'] which is correctly handled by a more logical sprintf.
Opinions?
- $txt['time_am'] and $txt['time_pm']... They were removed in rev 1071, but they're actually still being used in timeformat()...! They were used twice in the function, and only one occurrence got removed. It doesn't generate an error because it's only being called when $non_twelve_hour is set to true, i.e. the server doesn't support the '%p' parameter in time formatting. I'd suggest simply replacing them with 'am' and 'pm'... (Note, though: %p will usually use AM and PM, in uppercase. I don't know which is the better one. I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
Posted: October 17th, 2011, 12:15 PM
I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])
if ($then['year'] == $now['year'])
{
if (!isset($year_shortcut[$format]))
{
if (strpos($format, ', %Y'))
$y = ', %Y';
elseif (strpos($format, ' %Y'))
$y = ' %Y';
elseif (strpos($format, '-%Y'))
$y = '-%Y';
elseif (strpos($format, '%Y-'))
$y = '%Y-';
$year_shortcut[$format] = isset($y) ? $y : '%Y';
}
$show_today = str_replace($year_shortcut[$format], '', $format);
}Posted: October 17th, 2011, 12:21 PM
PS, sorry for the huge post Pete... :^^;:
I'll take a break now.
7384
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 07:51 AM »
Am I needed here?
7385
Features / Re: New revs - Public comments
« on October 17th, 2011, 07:47 AM »
I had a busy weekend. I'll look into it today.
7386
The Pub / [Archive] Re: Logo Madness
« on October 17th, 2011, 12:11 AM »
I guess I like the green because it reminds me of a leaf. I sort of reused my 'leaf/petal' idea from earlier, but with more realistic colors :P
Oh... A good question would be -- look at my signature. Doesn't the green version look cooler..?
Oh... A good question would be -- look at my signature. Doesn't the green version look cooler..?
7388
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 11:09 PM »The green doesn't do it for me, sorry.
I really like the petal-ish logos, btw -- especially the first one. At the same time, their shape also makes them not quite 'wedgy', unfortunately.
7389
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 08:40 PM »
I tried for a darker green in simply-pete.png but... Meh.
My fave is the sidebar one. Followed by simply-red/green. I'm not sure about the rest.
Drop shadow goes without saying in large mode. I'm just removing it for the favicon because it doesn't render well.
My fave is the sidebar one. Followed by simply-red/green. I'm not sure about the rest.
Drop shadow goes without saying in large mode. I'm just removing it for the favicon because it doesn't render well.
7390
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 07:52 PM »
Added a few more variations then, with different color tints, with drop shadow and without, etc...
Just pick your favo(u)rites and the ones you dislike!
Just pick your favo(u)rites and the ones you dislike!
7391
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 07:21 PM »
Thanks!
I'd have liked to know of pete's opinion on these logos. Matters a lot to me...
I'd have liked to know of pete's opinion on these logos. Matters a lot to me...
7392
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 04:21 PM »
As you can see, I loved it so much -- I simply got rid of the header section background and put everything into the sidebar... It's a bold move but one I'm very happy with.
Seriously, I think I have 'my' logo. Now I'm just left with convincing everyone else that it's theirs too... :niark:
Seriously, I think I have 'my' logo. Now I'm just left with convincing everyone else that it's theirs too... :niark:
7393
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 02:52 PM »
Added variations of the 'flat' logo. Just because I had them under the hand...
I should try and make a tiny logo of the original color variant, but in flat mode.
Any feedback?
I'm tempted to use this as the new default :P
I should try and make a tiny logo of the original color variant, but in flat mode.
Posted: October 16th, 2011, 12:49 PM
Any feedback?
I'm tempted to use this as the new default :P
7394
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 10:47 AM »
Tried to go 'super simple'.
Even tried color variations...
Well, I love it. Simple is good.
Even tried color variations...
Well, I love it. Simple is good.
7395
Features / Re: New revs - Public comments
« on October 16th, 2011, 10:38 AM »
Lol... Yes, you do care about this bug ;)
Sorry, I committed my own stack of things before I read your post :(
I'll leave it up to Pete to fix it, I have to go. Late breakfast! I love Sunday mornings.
PS: I also removed openid_uri from the members table. I'm telling you guys because it may not be something people would want to remove in the first place, at least at import time...
Sorry, I committed my own stack of things before I read your post :(
I'll leave it up to Pete to fix it, I have to go. Late breakfast! I love Sunday mornings.
PS: I also removed openid_uri from the members table. I'm telling you guys because it may not be something people would want to remove in the first place, at least at import time...