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 - Arantor
4651
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
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.
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
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)
Posted: February 29th, 2012, 02:46 PM

Fixed in Wedge r1411.
4655
Confirmed in Wedge, needs to be fixed.
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
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
That's the thing, it's actually broken. Here's our code.

Code: [Select]
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
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.
4660
While it's possible this will be pulled, in the meantime until the fate of permissions is decided, it probably should be fixed.
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
4662
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
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?
4664
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?
4665
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)