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
5431
The Pub / Re: Bloc Madness
« on April 19th, 2012, 04:19 PM »
Don't even bother with him, Pete... Bloc just amounts to a troll by now. :(
5432
Features / New suffixes for skin files...
« on April 18th, 2012, 11:41 PM »
So, as I suggested elsewhere, I (locally) added support for a few new suffixes.

I'm asking for feedback about the concept. Is it worth including in Wedge?

- index.admin.css: only gets added to the CSS file if viewer is an admin.
- index.mod.css: only gets added if viewer is a local moderator.
- index.custom.css: this one already existed, so it doesn't change anything... but I also added:
- index.local.css: (maybe 'index.custom-local.css'?) only gets added if the file is located precisely in the folder of the current skin, i.e. ignore it if showing an inherited skin.

The last one I felt was needed because one my want to customize a few graphics in a specific skin, and yet still be able to inherit it without having to reset the changes caused by the index.custom.css in yet another index.custom.css file...

What do you think?
5433
Plugins / Re: Light URL Plugin Maybe?
« on April 18th, 2012, 08:07 PM »
Didnt know that. Okay, not core then ;)
5434
Off-topic / Re: Post count fever
« on April 18th, 2012, 07:46 PM »
Quote from Nao on November 1st, 2011, 10:10 AM
Well I didn't want to spoil the thing but it looks like I'll be getting the trophy by a thin margin and then you'll reach 10k before I hit 8k ;)
In the end, we both hit the 10k mark on the same day, same hour :)

Congrats to the both of us!
5435
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 18th, 2012, 07:44 PM »
Quote from Arantor on April 18th, 2012, 07:41 PM
That's not strictly true. There are configurations of Apache that do not allow cascading. And not all servers run Apache (I'm looking at moving to nginx, for example)
Why the hell do programmers like to fuck with us every once in a while? :(
Quote
Yeah, I know. Part of that is the pure I/O and part of that is the parsing stage.
That's where php bytecode cache (or whatever it's called) probably helps the most...
5436
Plugins / Re: Light URL Plugin Maybe?
« on April 18th, 2012, 07:42 PM »
...Because it can then be used directly in tweets, things like that...?
Granted, it's of little use, but it's not of NO use at all. :)
5437
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 18th, 2012, 07:40 PM »
Quote from Arantor on April 18th, 2012, 07:23 PM
There are problems with doing that, namely that for every folder, you'd have to make sure that index.php/.htaccess were also added to each folder.
Sure. Of course people would first have to be able to find the folder... ;)
And if htaccess works -- it's only needed in the parent folder anyway.
Quote
Is % a valid filename character? ;)
If it isn't, I'll eat you! :ph34r:
Quote
Interesting. I guess it's hard to really optimise something like that properly.
include() can be (relatively) slow. Heck, simply loading SMF/Wedge's basic files (load, subs...) easily takes a few tenths of a second!
5438
Archived fixes / Re: Topic Cache Triggers IDM
« on April 18th, 2012, 07:37 PM »
Yep. It's all about whether MIME types are correctly set... Don't worry.
5439
Archived fixes / Re: SMorg
« on April 18th, 2012, 07:34 PM »
Instead of doing that (again -- I don't know why it works in SMF and not here?), I've changed onposting to be stricter (i.e. refuse anything that starts with [url]). Can you test it in the Test board? :)
5440
Plugins / Re: Plugins I refuse to do
« on April 18th, 2012, 06:00 PM »
Quote from Arantor on April 13th, 2012, 03:54 PM
Or negative numbers... what's 5 - 8 again? :lol:
That's why I mentioned that ;)
I don't read AAF, but I have a tab opened on your list of recent posts, so I can try and follow what you're replying to ;)
Quote
It's not such a silly idea, except for the fact that so-called MATHCHA problems are generally easy for machines to solve (thanks to Google Calculator)
Didn't know it even had a name, eheh...
They'd have to know we have a math question at that point though...
Quote
Actually if we were doing that, I'd rather do a plugin that generated it automatically, rather than a core feature.
The whole point of having it core, is precisely that you can then make sure that you're protected from 99% of spam right at install time.
5441
Archived fixes / Re: Buggy Feed links
« on April 18th, 2012, 05:58 PM »
Quote from Arantor on April 16th, 2012, 07:56 PM
You can't set it with ini_set. It's a PERDIR setting, not an ALL setting. You can only set it via .htaccess if your host allows you to do so (since it's a PHP setup thing, if you do it by ini_set, it's already too late as $_GET will by then already have been processed)
As I pointed out in my thought -- I got confused. Twas a bad day for me I guess... (Not that it's much better now.)
Obviously you can't set the separator *after* you started the PHP page, because you already have the query string in the $_SERVER variable, ah ah :)
I was a little too proud regarding that piece of code. Because I'd modified it for Noisen, I 'thought' I knew it by heart. I'd actually forgotten all about it...
Quote
No, no, no it doesn't. Read what the code does. It detects whether arg_separator is ; or not, if it is, it sanitises $_GET based on it, if it's not, it re-parses the query string.
We should always sanitize $_GET anyway. Just assume that ; is always used to separate stuff. Which is the case, anyway...
Occasionally though, SMF uses '&', as in the SID injector, and I don't know what it's there for. I'm assuming this is to 'emulate' enable_trans_sid being set to 1. Because I guess some servers won't allow you to use ini_set, if it's at 1, then it automatically injects & at the end of the SID and then you end up with two different URL styles to deal with -- ?PHPSESSID=...; and ?PHPSESSID=...& -- so they chose to inject & and deal with it later (which I don't believe they do...)
I for one couldn't care less about that, but I suppose we should deal with it overall?
Quote
I did the same thing you did, a $context setting to have it never inject SID into URLs. But since you've committed it, I didn't bother (and I wasn't that happy with it, I felt there should have been something more elaborate)
I hope you liked the name I chose for the setting :lol:
Although I'm never one to refuse SID! But only if it's C64-related ;)
Quote
For the same reason IP addresses are unreliable as sin anyway, things like NAT routing, where an IP address does not relate to a unique computer any more nor to a unique user.
The same could be said of a session ID. If I have my forum running on 3 different browsers, should Wedge say I have 3 users online...? For debugging purpose it's fine. What about Googlebot? Sometimes you get many requests from the same IP IIRC. Because they're all using different sessions, Wedge considers them as multiple bots. I for one would rather see it recognized as a single 'user'.
Quote
Quote
Which was due to my currently doing a rtrim() on the final URL and deleting any extra characters like ";"...
Previously, it was first removing & at the end and then removing ; or whatever.
Except that I saw cases where the trailing ; was present and cases where it wasn't - in the same page.
It should always be there in homepage links (index.php). And never elsewhere.
5442
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 18th, 2012, 05:44 PM »
Quote from Arantor on April 17th, 2012, 08:35 PM
It's not quite like that, no. The problem with cache keys is that they're all in the one folder - everything goes into $cachedir, and everything would notionally get the same md5() process applied, so you're not just considering collisions across the namespace of a single album's files, but collisions across everything that the md5() is applied to, which is potentially every media item (since we only need apply the md5 if there isn't a / in the supplied cache key)
We could also 'simply' create subfolders in /cache/ named after the cache hash... And store files in them (without the starting hash, of course.)
At least it wouldn't break/kill the cache (at least too soon) if files can't be removed.
Quote
That said, md5 might be 128 bits, but it's not 128-bit wide in collision cases. It was proved a few years ago that for collision purposes, the keyspace isn't 2^128 but more like 2^40 due to weaknesses in the way it's generated.
I see.
Quote
Actually, there aren't that many characters truly valid in a URI, the vast majority of them have... extra meanings, and are normally just %-encoded instead.
I guess we could also use urlencode() or something... :lol:
Quote
Quote
Oh, Pete -- how about we calculate that md5 hash only ONCE per page...? It seems stupid not to do it. We could simply store it in $context['cache_hash'] or something... If empty, just fill it in...
Works for me. :)
That's a pointless micro-optimization, in the end. It's obvious that PHP caches that value.
I saved the hash into $settings['cache_hash'] (I know it's not a good idea to use that global, but I don't want to pull $context into itself within the cache functions... Bad karma?), and did some benchmarking. (1000 calls to retrieve 'settings', which is the bigger cache file...)

SVN version with md5, filemtime and base64: 0.45s in average (Which is probably already much faster than in SMF...)
My version with cache hash and bin2hex: 0.44s in average

I'm not kidding you...
I also tried removing the @ in front of the include call, to no effect.
Removing the include entirely gave me results between 0.01s and 0.03s, very unstable, so it's hard to determine which is faster. So I guess I'll still commit this, but not in an enthusiastic way :P
5443
Plugins / Re: Light URL Plugin Maybe?
« on April 18th, 2012, 05:16 PM »
Quote from Arantor on April 17th, 2012, 08:41 PM
For putting this in core, I'm not sure why this is useful as compared to having Pretty URLs in core, but maybe that's just me
Hmm... Maybe because it's not very hard to implement, mostly... Although I haven't even added it to my to-do-list...
Quote
If you're creating short hashes that include t or b as references to topics and boards, that's fine - but how does that work for plugins?
They could just take another letter of the alphabet... :P
Or even several letters... (This would ensure their hashes are tested against in priority.)
Quote
What hoops do plugins have to go through in order to work? Plugins will naturally just fall in with pretty URLs (e.g. domain.com/do/pluginaction) without any work, and if they want to use pretty URLs, they can declare extra filters, but even that is going to be more effort than it's usually worth, so they won't bother.
I don't think they will, either.
Quote
If you not expect them to have to work with yet another URL routing scheme (optionally or otherwise), it's just more hassle for plugin authors, especially when people will ask them how to make it work.
Except that they don't have to use that scheme at all...
5444
Archived fixes / Re: SMorg
« on April 18th, 2012, 05:09 PM »
Title fixed locally. And here. I think.

The url bug... Well, it's probably a case of "I don't want to fix it before I understand why it works in SMF and not in Wedge..." :P
5445
Archived fixes / Re: Time offset (auto detect)
« on April 18th, 2012, 05:03 PM »
I really can't for the life of me accept this timezone system as it is right now.

I was looking at php.net and everything, and was at a loss. What should I do?

Then I considered several solutions and would like to suggest it.
Just get the whole list of timezones, split them into continents, and offer a select box with continent categories and city names for each (sorted by name).

I'd really rather rely on Wedge asking me to say where my timezone is (Europe > Paris), rather than having to select a timezone based on whatever cities we decided to include in the list...
Heck, we could even simply ask them for their country (okay let me just type 'F' here in the dropdown list... That's it, France...), and then automatically load a list of available timezones for the country (timezone_identifiers_list(DateTimeZone::PER_COUNTRY, $country)). If there's only one, use that, otherwise show a new select box with a timezone list... (requires PHP 5.3, though. But by the time it's released, maybe we could expect it to be installed...)