Wedge

+1 John ;)

So, if I put a index.ie7,replace,ie6.css file into the folder, that would assume I want the parent folder's index.ie6,ie7.css and index.ie7,ie6.css files to be removed...? But not, say, index.ie6.css or index.ie6,ie7,ie8.css?

The img problem was due to Aeva, once again...
I added img to the exception list.
I'm guessing this will require a rewrite, still. I don't like the idea of this happening all too often....

I'm actually wondering whether I couldn't simply move all embedding code to parse_bbc(). Eh, why not... Footnotes are already there, after all. Why not the rest. Unless of course I forgot about a good reason to have it outside.

Re: performance, I made more tests, and I still can't get a full page to use more than 10% of the overall resources... (With a full page of regular posts + a few more complex ones.)
I really don't know what's hapenning. Maybe it's not in parse_bbc() itself...?!

I did a few tests earlier and the only offenders were the Aeva and media tags actually...

Shall I keep the strlen db cache then btw?

I guess so. But then again -- I suppose we can live with it...?!
I mean, do you know of many users who manually type their tags, and when they do, they're not geeks and thus don't follow the common use of lowercase for tags...?Yep... (Didn't think of that, really.)

(I had the tab open from this morning, then had to go do shopping and stuff)

I only know vaguely about the way it works or is supposed to work, it's not something I spent long looking at :(I did some tests... That piece of code is never called much, in the end. Or maybe that's because there are only 56 tags and only a handful of them are spread over the same repeated starting letter (T, mostly, as I mentioned, or L, etc.)... I actually did the internal database conversion on my local install, added the numbers through a query (update bbcode set len=length(tag), was easy enough...), and tested: most of the time the strlen() version is faster, ahah... Well, it mostly means that it's not where the code is slowed down.

Heck, actually I made some benchmarking over the entire parse_bbc() code, and I nearly always get very high performance (e.g. a few milliseconds per post, even with multiple tags in them)...
I don't really know what's slowing it down, then.
Maybe it's a waste of time...

So, some time ago I changed quote tags to use whitespace trimming, so that I could precisely style the space between quotes and surrounding text.

Turned out that it didn't work very well.
The first problem was with margins. I used margin collapsing to allow for an opener quote not to take any useless space at the top of a post, but if you quoted that, it would add the extra space inside the new quote. I fixed it this morning by adding an extra div directly above the blockquote tag. I fought long and hard against that (even trying for pseudo-elements to fill in the gap...), until I realized I'd provisioned for an empty <footer> tag in the markup. So I simply removed the footer tag (which can very well be 'emulated' through pseudo-elements, like .bbc_quote:after, well, maybe not, but it can always be re-inserted by a plugin through a SQL query), and replaced them with the div tags. 'div' is shorter than 'footer', and it's acceptable. (Heck, I'm even considering turning <div class="bbc_quote"> into <section class="bbc_quote"> because of the header, but whatever...)

So, problem solved.
Now, there's an extra problem. The trimming code.
Let's say you have some text, then a few empty lines, then a quote, then a few empty lines, then some text.
Wedge (and SMF, I guess) will only remove the TRAILING empty lines. Any empty lines BEFORE the quote tag are left as is.
I was wondering why, and it turned out that... Well, it seems that these are never even looked against...?!
So, quotes are set to trim 'outside', to me that means "before and after the tag"...
But it seems that the two 'outside' trimming code blocks are both about 'anything coming after the tag'.
And if anything -- the regexps both start with '^' and have no closer '$', which doesn mean "look for whitespace at the beginning of the string...", when we should have at some point a test against whitespace soming before the tag, i.e. a test against substr($message, 0, $pos) (with $pos representing the start of a tag, and a regexp ending with $), instead of substr($message, $pos), with $pos representing the end of the tag and the regexp starting with ^, like it is now...

Do you think it's an oversight? In SMF, 'outside' is only used on 'td' and 'li'. I can understand that one would want to only test for whitespace once because if anything, there's little chance of having any text between two td or li tags, so if you test for trailing whitespace, you don't need to test for leading whitespace on the next tag because it's likely to have been removed already... Yet, it isn't working that way in my opinion.

Maybe I should add support for a new trimming codeword that would cover both directions... I don't know.

Anyone here knows about everything I've been talking about...?

Testing.

Details

[media id=1]

So, what if your friends never go online more than once a month...? They'll never see more than 10% of your notifications?
I'd tend to say, "people should be able to subscribe to a custom web/xml feed that takes whatever data they want from whatever account they want...", and that shouldn't be linked to a specific wall. (It'd just be, somehow... "choose what kind of data you want to see in your aggregated wall.")

It still doesn't solve the issues of where we store this data, whether we use the thoughts table, and where we store the comments :^^;:Hmm yes, I see what you mean. Although I do get FB notifications for stupid things like new posts in a group I'm on... (Okay, to be fair, FB allows me to disable these on a group by group basis.)It is a social network, whether you want it or not... It's up to admins to determine how 'social' they want to be, I'd say.