Wedge

rev 1548 (Too many things to finish before I can commit them...)
(5 files, 3kb)

+ Added a custom time format string, "%@", which you may use to add something after the day number, e.g. "31st", "3rd", etc, and using it by default in English and French. Used a custom array in $txt, translators should set $txt['day_suffix'] to array('n' => '%d') if they have no specific suffixes to add for their language. (Load.php, Subs.php, index.language.php)

! Fixed board ordering in category pages. (Subs-BoardIndex.php)

Silly idea. Add a default question called {equation}. this will make Wedge generate on the fly a very simple random equation for users to solve.

Of course that'll also keep out those who never heard of the minus sign... :lol:

I have a feeling that either no one reads the 'SMF bug' topics, or no one cares about the option :P

How so?

Btw I was mistaken.. I inverted my benchmark results. The svn version is actually a bit faster. Need to dig into this.

I see what you mean.
Maybe we could simply change the way menus (or contextual tabs) are rendered...
(I'd rather change tabs. Not that they're ugly, but they can probably made to look more like our button strips..?)

I'm trying not to look into SlammedDime's mod really. Perhaps out of pride -- because I had issues with the guy before. Also because I don't feel like reinventing something that works (albeit is a bit complicated...). I didn't write PrettyURLs either. I just know it well enough to fix its bugs as fast as needed.

Anyway, err... Apart from that, I don't really know where to start here. Just wanted to mention that with my 'simpler' regex, at least I get to easily change ANY url in the page and that works for JavaScript too... Just look at action menus, usually they wouldn't use transformed URLs ;) (The only thing to remember is to allow for %a-z or something in any string where you're expecting digits, since usually you'll get myvariable=%var% in JS and you want to replace these without breaking them... (It's different for topic IDs though. Can't really replace these :P)

So... I think it's working again?

But right now, it's fairly... Slower, I should say. I'm not exactly sure why -- the regex should be faster (if anything it's simpler...), and I also optimized the underlying PHP, but still, it's up to twice slower than before to do the replacements.

I'm kinda hoping I could make it a bit faster by doing the overall page replacement only once:

- retrieve all content in the page like this: '\btopic=(\d+)|\bboard=(\d+)' (perhaps also \bcategory=(\d+)??)
- thus we have a list of topic and board IDs ($matches[1] has topics, $matches[2] has boards), including stuff that isn't ACTUALLY topic IDs to transform, but we get it as quick as we can. Now we simply do our search & replace regex...
- during the replacement, if we ever find 'topic=' or 'board=' in the match, and we don't have a list of topic/board names, fill the topic/board name cache(s).
- possibly call a new hook at this point...
- test for action=profile, replace with profile. (Has custom URL scheme)
- test for action=, replace with action. (Has custom URL scheme)

Should cater for everything...?! Except for the URL cache. (Which I've always contemplated dropping anyway... If performance is THAT important to you, maybe you shouldn't consider doing pretty URLs in the first place...?! Because that cache table ALWAYS gets huge after a while...)

What do you think?

Currently, this is pretty much how it is done...:
- run the search regex
- loop through all links and find uncached URLs
- call topic handling, loop through all links to find topics and transform them
- call action handling, loop through all links to find actions and transform them
- etc...
- run the replace regex with a callback that will look for the rebuilt URL in the temporary memory cache, and will do the replacement on all links.

I have a feeling that it *could* be made faster, see...!
Do you share my feeling or not?

Funny... I just did a benchmark of my two regexes. And indeed the 'faster' one (in theory) is 4 times faster than the older one.
So the slowing down thingy must be somewhere else...