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
4576
Features / Re: Board access
« on March 4th, 2012, 03:17 AM »
Argh, I just remembered there's another interface for group->board access - the edit-membergroup screen. I suspect I'm basically going to reimplement the same code, except instead of using group names, it'll be board names, but it's too late and I'm feeling too ill to tackle this properly tonight.
4577
That's part of the problem, separately, that it uses the count of items there as the id of the next item to insert (as opposed to tracking what the next item would really be), which is how they get messed up in the first place.

It sort of is auto-inc and sort of isn't... >_<
4578
Archived fixes / SMF bug 4442 (submit buttons with name="submit")
« on March 4th, 2012, 03:13 AM »
Generally there shouldn't be a need for it, and the resultant bandwidth can be saved (though a cursory glance suggests it's in the admin panel only) but when going through them, need to make sure that $_POST['submit'] isn't checked later to determine whether a specific button was pressed or not.
Posted: February 29th, 2012, 01:12 PM

Fixed in r1425.
4579
Features / Re: New revs
« on March 4th, 2012, 03:12 AM »
(17 modified, 2KB)

Revision: 1425
Author: arantor
Date: 04 March 2012 02:12:26
Message:
! SMF bug 4442 (name="submit" used in forms which can break onsubmit functionality) A lot of these can actually be pruned, a few left require *something*, so those use name="save" instead. Nothing seems to be broken as a result of this change. (all files)
! Unclosed form tag. (ManageMedia.template.php)
----
Modified : /trunk/SSI.php
Modified : /trunk/Sources/ManageMembergroups.php
Modified : /trunk/Sources/Packages.php
Modified : /trunk/Sources/Report.php
Modified : /trunk/Sources/Themes.php
Modified : /trunk/Themes/default/ManageAttachments.template.php
Modified : /trunk/Themes/default/ManageMedia.template.php
Modified : /trunk/Themes/default/ManageMembergroups.template.php
Modified : /trunk/Themes/default/Memberlist.template.php
Modified : /trunk/Themes/default/ModerationCenter.template.php
Modified : /trunk/Themes/default/Packages.template.php
Modified : /trunk/Themes/default/PersonalMessage.template.php
Modified : /trunk/Themes/default/Search.template.php
Modified : /trunk/Themes/default/SendTopic.template.php
Modified : /trunk/Themes/default/Themes.template.php
Modified : /trunk/Themes/default/index.template.php
Modified : /trunk/other/tools/repair_settings.php
4580
Interesting this one, you can see it on sm.org where the bugtracker child board is - there isn't proper padding between cells in the table.
Posted: February 29th, 2012, 02:39 PM

Or you could see it, apparently it has been fixed on sm.org at some point.
Posted: February 29th, 2012, 11:38 PM

I think this has been fixed in Wedge indirectly, as I can't seem to reproduce it through anything I can do (all boards seem properly spaced to me)
4581
All the 'cancel' link on an AJAX notification does is hide the 'Loading...' notification.

While we could theoretically just change the text to say 'close', I'd rather we either removed it entirely or we actually made it cancel. That shouldn't be too problematic, since we should be able to call .abort() on the object being used to handle the XHR itself (AIUI, jQuery > 1.5 exposes all methods from the XHR)

All we'd actually need to do is have it so that when we show the notification, we pass something to it by which we can call the abort... assuming we do that. If we don't, it gets a bit trickier to handle. Mind you... if we have two concurrent AJAX requests for whatever reason and both trigger 'Loading', it's impossible to know which would actually be cancelled.

Hmmm. Maybe it should just be renamed (or simply remove the hide button since having it really doesn't achieve anything useful)
Posted: March 1st, 2012, 02:50 PM

Bumpity. Inclined to simply remove the hide button, by the way, unless anyone has any burning issues with wanting to actually attempt to cancel the AJAX request?
4582
Archived fixes / Re: Fixed SMF bugs
« on March 4th, 2012, 02:13 AM »
Quote
Did you try?

Technically, these errors should be shown in a template-free template. Just a text message...
This works properly in r1424 now, it would only work before in the event of pretty URLs being enabled. And since I never enable that... :whistle:
4583
Features / Re: New revs
« on March 4th, 2012, 02:12 AM »
(1 file, 1KB)

Revision: 1424
Author: arantor
Date: 04 March 2012 01:12:06
Message:
! The full request URI was only being evaluated for 'is it a 404 image' in the event that pretty URLs was enabled, failing that it would never evaluate the URI properly, so the 404-handler never kicked to log missing images. This is early enough in the process that it occurs before the log write occurs, which is awesome. Also, no need to update the online log with a 404 error. (QueryString.php)
----
Modified : /trunk/Sources/QueryString.php
4585
Yup. If you have a poll with 3 options, they use ids 0 through 2. Even if you remove something, the next id will be 3.
4586
But if you keep re-editing a poll, I guess you could exceed 255, which is how the original bug happened.
4587
Well... it depends how you define 'dynamic' entries. More than one button is already variable depending on state, e.g. the login and register buttons.

As far as the admin menu goes, simple expansions that only add their own page and nothing more, they're already sort of cached and don't need to load any files, they're in $settings.

I have thought about doing something similar for the main menu too, so that simple menu buttons (nothing that is *too* dynamic) from plugins can be handled much the same, leading to files not being loaded just to make a tiny change to the array.

For more complex cases, caching is probably useless anyway and will convolute things more than it'll help.
4588
Quote
but it's not clear what exactly is cached and isn't.
Nope. But I'm not convinced the main menu is worth caching and even if it is, it still has to be reworked because right now the media count will be wrong.
Quote
I suppose it'd be good to time the time taken by the admin menu from build time to display time. Just to see how much of a percentage of performance it takes on the page.
I'm not that bothered by the ACP performance as I am something that's run nearly every page...
4589
Archived fixes / Re: Fixed SMF bugs
« on March 3rd, 2012, 12:59 PM »
Quote
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name
It's not even as simple as that potentially. Remember that you get regional codes too, en_GB vs en_US for example.
Quote
And going through the complete list of index.*.php files, opening them and scanning for lang_dictionary or lang_locale... Not great either!
You only need to do it once at the start of installation remember.
4590
Main menu only. The admin menu is not cached anyway.

The idea is that the main menu is 'so busy' that it should be cached on level 2+ but I fail to understand the logic of why.