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.
4651
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on March 1st, 2012, 10:21 AM »
Question, are we talking about hashing the key all the time, or just the cases where it contains potentially awkward characters? If the latter, would it not be better to detect that actually in cache_*_data, and hash it there, rather than finding all the places where it's called with funny characters and hash before sending?
4652
Archived fixes / SMF bug 4913 (convert fopen/fwrite to file_put_contents)
« on March 1st, 2012, 10:18 AM »
I'm not 100% sure why this is being suggested, but it is certainly shorter and cleaner, though I can't see it being any faster or more efficient in the long run. I'm also not sure if there aren't permissions related issues to deal with.
Note that we wouldn't convert all the cases (only where it's atomic, such that we do fopen/fwrite/fclose in quick succession), because that's faster than doing file_put_contents with appending.
Posted: February 29th, 2012, 02:27 PM
Note that we wouldn't convert all the cases (only where it's atomic, such that we do fopen/fwrite/fclose in quick succession), because that's faster than doing file_put_contents with appending.
4653
Other software / Re: Finally, they've made an announcement
« on March 1st, 2012, 10:15 AM »
I would note, after going through some of the bugs yesterday to post here as things to be fixed, I'm disappointed. More than one of the bugs has a solution posted that is completely workable - but apparently no-one could be bothered to try it/commit it, often within a period of months :(
4654
Archived fixes / SMF bug 4828 (editing an icon can produce errors if admin security triggers)
« on March 1st, 2012, 10:06 AM »
Because the form isn't validating properly, only relying on the session data being in $_POST to identify that it's supposed to receive content, it gets confused if the form immediately before happens to be the validate-password triggers from admin security (which also sends the session data in $_POST the same way)
Suggested solution is good (to name the submit and check for that instead)
Fixed in Wedge r1411.
Suggested solution is good (to name the submit and check for that instead)
Posted: February 29th, 2012, 02:46 PM
Fixed in Wedge r1411.
4655
Archived fixes / SMF bug 4868 (0 not supported as value in anti spam Q&A)
« on March 1st, 2012, 10:06 AM »
Confirmed in Wedge, needs to be fixed.
Fixed in Wedge r1411.
Posted: February 29th, 2012, 01:09 PM
Fixed in Wedge r1411.
4656
Features / Re: New revs
« on March 1st, 2012, 10:06 AM »
(4 modified, 2KB)
Revision: 1411
Author: arantor
Date: 01 March 2012 09:05:49
Message:
! SMF bug 4868 (anti spam Q&A would not accept 0 as a valid answer) (Subs-Editor.php)
! SMF bug 4828 (editing an icon would fail if admin security was tripped) (ManageSmileys.php, ManageSmileys.template.php)
! Removing duplicate options for PMs from security pages, they fit much better in the PMs area anyway, and now they won't show up twice in searches. Also tweaked min values for a few settings. (ManageSettings.php)
----
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/ManageSmileys.php
Modified : /trunk/Sources/Subs-Editor.php
Modified : /trunk/Themes/default/ManageSmileys.template.php
Revision: 1411
Author: arantor
Date: 01 March 2012 09:05:49
Message:
! SMF bug 4868 (anti spam Q&A would not accept 0 as a valid answer) (Subs-Editor.php)
! SMF bug 4828 (editing an icon would fail if admin security was tripped) (ManageSmileys.php, ManageSmileys.template.php)
! Removing duplicate options for PMs from security pages, they fit much better in the PMs area anyway, and now they won't show up twice in searches. Also tweaked min values for a few settings. (ManageSettings.php)
----
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/ManageSmileys.php
Modified : /trunk/Sources/Subs-Editor.php
Modified : /trunk/Themes/default/ManageSmileys.template.php
4657
Bug reports / Re: SMF bug 2706 (no preview on newsletter)
« on March 1st, 2012, 09:57 AM »
Interestingly, it doesn't appear to do any error checking either... you're entirely able to send a blank-content newsletter. >_<
4658
Archived fixes / Re: SMF bug 4870 (incorrectly capitalised month names)
« on March 1st, 2012, 09:55 AM »
That's the thing, it's actually broken. Here's our code.
Code: [Select]
Now, SMF's code is slightly different because I tweaked how setlocale was run but the basis is the same: if we could setlocale, locale is *probably correct* (certainly the example on the setlocale page in PHP actually validates this... it uses Dutch specifically so that the formatting will be shown) and yet it's discarded.
If we don't trust the locale DB, we shouldn't use it and just use the later branch where we have the strings ourselves, and if we do trust the locale DB, we should leave it the hell alone and not mess about with ucwords on it.
if ($user_info['setlocale'])
{
foreach (array('%a', '%A', '%b', '%B') as $token)
if (strpos($str, $token) !== false)
$str = str_replace($token, !empty($txt['lang_capitalize_dates']) ? westr::ucwords(strftime($token, $time)) : strftime($token, $time), $str);
}
else
{
// Do-it-yourself time localization. Fun.
foreach (array('%a' => 'days_short', '%A' => 'days', '%b' => 'months_short', '%B' => 'months') as $token => $text_label)
if (strpos($str, $token) !== false)
$str = str_replace($token, $txt[$text_label][(int) strftime($token === '%a' || $token === '%A' ? '%w' : '%m', $time)], $str);
}Now, SMF's code is slightly different because I tweaked how setlocale was run but the basis is the same: if we could setlocale, locale is *probably correct* (certainly the example on the setlocale page in PHP actually validates this... it uses Dutch specifically so that the formatting will be shown) and yet it's discarded.
If we don't trust the locale DB, we shouldn't use it and just use the later branch where we have the strings ourselves, and if we do trust the locale DB, we should leave it the hell alone and not mess about with ucwords on it.
4659
Archived fixes / Re: SMF bug 4870 (incorrectly capitalised month names)
« on March 1st, 2012, 09:20 AM »
The bug report points to Dutch. In all other languages, the months are written January/February/whatever, but in Dutch, the correct spelling is entirely lowercase.
Yet, timeformat() pushes them through ucwords() unless a $txt variable is set, which implies it's a known workaround, but if we already have $txt strings for the months, we would have them just be correct without any need to mess with ucwords in the first place.
Yet, timeformat() pushes them through ucwords() unless a $txt variable is set, which implies it's a known workaround, but if we already have $txt strings for the months, we would have them just be correct without any need to mess with ucwords in the first place.
4660
Archived fixes / SMF bug 4865 (headers incorrect in manage-permissions simple mode)
« on March 1st, 2012, 01:27 AM »
While it's possible this will be pulled, in the meantime until the fate of permissions is decided, it probably should be fixed.
OK, I know why this is happening in SMF and why I apparently couldn't reproduce it myself. It's hidden permissions.
The first 'gap' where it skips a windowbg, should be approve_posts permission - but it's disabled by default. And the row is inverted regardless of whether anything was displayed or whether an input type="hidden" was inserted in its place. Just need to quietly move the flipping of state.
Fixed in Wedge r1410.
Posted: February 29th, 2012, 02:55 PM
OK, I know why this is happening in SMF and why I apparently couldn't reproduce it myself. It's hidden permissions.
The first 'gap' where it skips a windowbg, should be approve_posts permission - but it's disabled by default. And the row is inverted regardless of whether anything was displayed or whether an input type="hidden" was inserted in its place. Just need to quietly move the flipping of state.
Posted: March 1st, 2012, 12:31 AM
Fixed in Wedge r1410.
4661
Features / Re: New revs
« on March 1st, 2012, 01:27 AM »
(8 modified, 5KB)
Revision: 1410
Author: arantor
Date: 01 March 2012 00:27:01
Message:
! SMF bug 4865: hidden items in the permissions area would cause incorrect formatting. (ManagePermissions.template.php)
! Tweak pretty URLs, drafts and merge posts UI to fix a couple of layout bugs and make all three searchable through the admin search feature consistently. (Admin.php, ManagePosts.php, ManageSettings.php, SplitTopics.php, Admin.template.php, Admin language file)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManagePosts.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/SplitTopics.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Revision: 1410
Author: arantor
Date: 01 March 2012 00:27:01
Message:
! SMF bug 4865: hidden items in the permissions area would cause incorrect formatting. (ManagePermissions.template.php)
! Tweak pretty URLs, drafts and merge posts UI to fix a couple of layout bugs and make all three searchable through the admin search feature consistently. (Admin.php, ManagePosts.php, ManageSettings.php, SplitTopics.php, Admin.template.php, Admin language file)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManagePosts.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/SplitTopics.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
4662
Bug reports / Re: SMF bug 4834 (no way to disable PM body being sent in notifications)
« on March 1st, 2012, 01:23 AM »
So you don't ever leave it on by default but turn it off yourself? (This is what I'm wondering, because it would simplify the code to remove it for that too.)
4663
Bug reports / Re: SMF bug 4834 (no way to disable PM body being sent in notifications)
« on March 1st, 2012, 12:48 AM »
In that case, let's flip it back the other way. Do we need the ability for users to set a preference on posts, as they can currently do?
Does it add value to have that option? Do users take it?
Does it add value to have that option? Do users take it?
4664
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on March 1st, 2012, 12:38 AM »
Two things occur to me about this.
Firstly we can of course patch cache_get_data and cache_put_data to do something with / (and \ potentially), but that won't prevent any issues if other illegal characters get inserted... I never checked what happened to something like " in a filename (which won't be legal on all filesystems) though I have a funny feeling it would be translated to its entity form (like I've seen with the shy entity)
Secondly, would it not be better to do some kind of hash on the key so that we don't inject actual names anyway?
Firstly we can of course patch cache_get_data and cache_put_data to do something with / (and \ potentially), but that won't prevent any issues if other illegal characters get inserted... I never checked what happened to something like " in a filename (which won't be legal on all filesystems) though I have a funny feeling it would be translated to its entity form (like I've seen with the shy entity)
Secondly, would it not be better to do some kind of hash on the key so that we don't inject actual names anyway?
4665
Bug reports / Re: SMF bug 4834 (no way to disable PM body being sent in notifications)
« on February 29th, 2012, 11:37 PM »
OK, question of the day.
SMF's post notifications has a user on/off for the body text - plus a master override. PMs on the other hand, have neither. You get it every time.
Now, adding a master override is easy, adding a user preference not quite so much. Do we want to allow the user preference on this or not? (It is actually a schema change if we do, but not a huge one, just an extra tinyint in the members table)
SMF's post notifications has a user on/off for the body text - plus a master override. PMs on the other hand, have neither. You get it every time.
Now, adding a master override is easy, adding a user preference not quite so much. Do we want to allow the user preference on this or not? (It is actually a schema change if we do, but not a huge one, just an extra tinyint in the members table)