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
5521
Off-topic / Re: Random idea: non-generic default avatars
« on April 11th, 2012, 11:09 PM »
I dunno, once you used Bebas you won't switch to anything else anyway :P
5522
Off-topic / Re: Random idea: non-generic default avatars
« on April 11th, 2012, 03:54 PM »
I never suggested to ship with a dingbats font really! There are better uses for extra kilobytes in the package anyway... ;)
5523
Bug reports / Re: Pretty URL remarks
« on April 11th, 2012, 02:59 PM »
So... After doing some tests... I'm pretty much getting the same performance across all method. They're very variable, the server seems to be unstable in that respect. I was at first a bit surprised but not that much... When trying to match against a resource URL (image etc), Wedge will either stop at 'index.php' (if it's enabled), or at the [?;&#] if index.php is disabled. In both cases it should really be the same performance...
I'm not sure why but it seems that the 'original' solution (the svn one) removes the index.php automatically in the 'wedge.org/index.php' links, even though the regex doesn't seem to match them... Not that it's important.
I'm not sure why but it seems that the 'original' solution (the svn one) removes the index.php automatically in the 'wedge.org/index.php' links, even though the regex doesn't seem to match them... Not that it's important.
5524
Bug reports / Re: Pretty URL remarks
« on April 11th, 2012, 12:59 PM »
Well, it's very simple...
...Once I figure out how to explain it simply :P
...Once I figure out how to explain it simply :P
5525
Off-topic / Re: Random idea: non-generic default avatars
« on April 11th, 2012, 08:17 AM »
Except that all OSes have a dingbats font somewhere... :) There's probably even a font stack ready for use for that use case. Or just turn to utf entities. Which will use the dingbats as needed. Maybe.
Or take a random avatar from the ones available, apply a color tinting and add the username :)
Or take a random avatar from the ones available, apply a color tinting and add the username :)
5526
Bug reports / Re: Pretty URL remarks
« on April 10th, 2012, 11:19 PM »
An alternative would be to do it like the svn currently does, only we add [?#] directly after $preg_replace. This is the first thing I did but it will still preventively match all urls until the question mark is not found.
5527
Bug reports / Re: Pretty URL remarks
« on April 10th, 2012, 11:16 PM »
Does anyone else has something to add? Pretty please? I'm not sure what's best here.
5528
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 10th, 2012, 11:14 PM »
Not sure base64 is that necessary if we do that.
Oh, and best way to benchmark is prolly to generate a random string on every loop. I'm sure php would optimize it otherwise.
Oh, and best way to benchmark is prolly to generate a random string on every loop. I'm sure php would optimize it otherwise.
5529
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 10th, 2012, 10:30 PM »
Yup.
It's still lightning fast though.
Trying adding a strpos before, too! It's pretty much a free call. Really.
It's still lightning fast though.
Trying adding a strpos before, too! It's pretty much a free call. Really.
5530
Other software / Re: Customisation site rewrrite
« on April 10th, 2012, 08:58 PM »
We woul love to say we are optimistic. But it just isn't realistic to expect them to reinvent the wheel in leas than three years and without multiple team changes. smCore needs someone who'll do most o the work over the years and ensure it isn't bloated even before release.
Pete and I work full time on Wedge. We know how hard it is to stay focused for so long.
Pete and I work full time on Wedge. We know how hard it is to stay focused for so long.
5531
Bug reports / Re: Pretty URL remarks
« on April 10th, 2012, 03:41 PM »
Actually thought of doing it that way first, but then I figured, "argh, it's gonna get dirty"... ;)
But certainly it would be... Interesting to actually *remove* $scripturl entirely from the global list!
There are still 2000+ occurrences of it in the code, and we'd have to make sure ob_sessrewrite is always called... (e.g. Xml and SSI... But it's pretty much the same issue as with PURLs to begin with!)
Also, if someone decides to add a link to the forum and adds index.php manually (or just gets it through an old Google link etc), then these might not get replaced in the final code...
But certainly it would be... Interesting to actually *remove* $scripturl entirely from the global list!
There are still 2000+ occurrences of it in the code, and we'd have to make sure ob_sessrewrite is always called... (e.g. Xml and SSI... But it's pretty much the same issue as with PURLs to begin with!)
Posted: April 10th, 2012, 03:40 PM
Also, if someone decides to add a link to the forum and adds index.php manually (or just gets it through an old Google link etc), then these might not get replaced in the final code...
5532
Bug reports / Pretty URL remarks
« on April 10th, 2012, 03:28 PM »
So... Support for pretty URLs is pretty solid, but I still had an issue with Wedge trying to re-parse URLs that were already parsed, and sometimes breaking them as a result.
This turned out to be due to the way I implemented my 'index.php' removal code (which, BTW, is an optional feature). Because $scripturl immediately ignores the filename, the pretty URL regex thus searches for any boardurl and will transform them.
I fixed it by instead doing the transform *after* pretty URLs are handled. (Currently it's done within the PURL code block but I'm not sure this should be associated with them -- one might want to just get rid of index.php without systematically transforming URLs...)
This adds a new problem. Because it's now done through a basic str_replace, I have no way to 'control' how index.php is removed from the page -- could be within a non-linked URL, for instance. Or whatever.
My belief is that if you want to remove index.php from your URL, you will want to remove it from ANY place on the page, even if it's not intended as being transformed. Making it a no-brainer to apply the technique I just devised.
I'd like some opinions on this.
This turned out to be due to the way I implemented my 'index.php' removal code (which, BTW, is an optional feature). Because $scripturl immediately ignores the filename, the pretty URL regex thus searches for any boardurl and will transform them.
I fixed it by instead doing the transform *after* pretty URLs are handled. (Currently it's done within the PURL code block but I'm not sure this should be associated with them -- one might want to just get rid of index.php without systematically transforming URLs...)
This adds a new problem. Because it's now done through a basic str_replace, I have no way to 'control' how index.php is removed from the page -- could be within a non-linked URL, for instance. Or whatever.
My belief is that if you want to remove index.php from your URL, you will want to remove it from ANY place on the page, even if it's not intended as being transformed. Making it a no-brainer to apply the technique I just devised.
I'd like some opinions on this.
5533
Other software / Re: Customisation site rewrrite
« on April 10th, 2012, 02:35 PM »
Interesting that I never noticed...
5534
Other software / Re: Customisation site rewrrite
« on April 10th, 2012, 01:26 PM »
http://smcore.org/forum/index.php?topic=238.msg2139#msg2139
They even admit it...
Hey when did they make their forum public?
They even admit it...
Hey when did they make their forum public?
5535
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 10th, 2012, 12:44 PM »
Windows 95+ accept + signs, it's only DOS (8.3) that won't take them... And I don't know of TOO MANY servers that run on Windows NT 3.1 ;)
Ah, still love my War Game references :P
Ah, still love my War Game references :P