Wedge

Eventually, I'll stick my finger out of my arse, and I'll write a module to automatically update files from github as long as you're using an alpha or beta install.

Then again, it'll probably come *after* I write the code to automatically update files on non-alpha versions. (Which, in this case, will only retrieve official releases.)

[Commit revision aad30be]
Author: Nao (Signed-off)
Date: Fri, 04 Apr 2014 22:46:12 +0200
Stats: 1 file changed; +2 (insertions), -4 (deletions)

• Fixing infamous bug in importer script where From paths were marked as invalid even though they shouldn't be. (import.php)
• Note 1: this was due to XML settings not being loaded at the time the HTML headers were printed. I fixed it by transparently redirecting. The problem only happened if you had only one *_to_wedge.xml file in your root folder, and could be fixed by simply refreshing the page.
• Note 2: I'm totally manipulating the commit date for this (which is really made on April 6)... Don't want to go back to playing with github's "longest streak" (committing every day when you don't always have something to commit is annoying), and I'm artifically stopping it at 100 days. Should give me about 265 days of tranquility, at which point GH may have allowed users to hide that annoying stat.

---

[Commit revision 1f3c70f]
Author: Nao (Signed-off)
Date: Sat, 05 Apr 2014 12:50:41 +0200
Stats: 1 file changed; +5 (insertions), -5 (deletions)

• Should probably account for backslashes in paths. (import.php)
• Details. (import.php)

Could you post the contents of that message? Not the HTML. Just the bbcode version. Thanks!

Done this way on media items and regular attachments.

Knowing whether a remote link is an image would require server work. For instance, many people will just post a link to the remote page with the image and ads. If you're embedding the image directly into a post, then maybe you don't want it to be clickable. Or maybe you're embedding the thumbnail, in which case the clickable link might lead to the page with ads.

In other words, this doesn't seem like a reliable (and thus plausible) solution.

Yes I've thought about it before.

This could be done through a plugin, though... Eg add a 'zoom', zoomedia or lightbox bbcode that will automatically act as a URL bbcode, but load the target in zoomedia.

It's always been the case...!
They were all orange. The only thing I changed is the notification buttons. They used to be either orange or gray, now they're either orange or white.Hmm... Dunno. Why not just use "Unread Replies", then...? Regular users never participate in MANY topics, and as such, they won't be overwhelmed by the information in that area...

Update is online here...

Can you spell "boring"?!

I don't know what you'll think. I'm not happy with it, personally. I do like the effect on the main menu, though. Also maybe on the notification popups. The rest... Not so much. Not enough visible on topic pages, not enough on unread counters either.

Please share opinions.
Or, even better, screenshots of how you think it could be improved!

Note: I've reached the 100-day milestone on github's "longest streak", and as I promised myself I wouldn't go beyond that (I only kept committing everyday because I didn't want to end my longest streak on an unlucky number, but above 100 means I'd have to do that every six months, err, don't bother), I probably won't commit anything tomorrow. Or, if I do, I'll try to rewrite history so that it shows as from the day before... :P
Well, I gave up yesterday, so you're my only hope at this point. :lol:

Honestly, I'd be happy with just a quick query that finds at least one unread post in every board, and stops after that. But I don't think it'll work in making the query faster.

Right now, here's what the query does:
- Gather all id_msg
- Gather all read positions (log_topics...)
- For each msg, determine if its topic is in the read topics list. If yes, if current msg is > msg of the read topics list, then consider we have unread posts in that topic. Mark as unread.
- If not, then try to find the same in log_mark_read.
- If not, then it means we never marked the topic as read, so it's unread. Mark as unread.
- Then, we just group by board.

One of the things that could be done to improve everything, is to store the last id_msg that was sent at the time of our registration. This would serve as a 'threshold', i.e. any posts sent BEFORE my registration should be marked as read.

I don't remember what log_mark_read does. I think it marks a board as read, meaning it makes our work much easier.
However, wasn't that what log_boards was supposed to do..? Hmm... I don't really remember. I'm tired. Bed time!
Well, that's what it's doing right now... If it has a number, then it's unread.
It's more precise than the old system. But it's also much slower.

And whether I store read status or number of unread posts, it's the same: it's very slow. I tried to cache that data, it makes it very fast of course, but it requires a load of work that I'm unwilling to put in for now. (Emptying the whole cache everytime a new post is sent somewhere or any of many other actions is performed, seems like unnecessary crap.)

[Commit revision 06b0b02]
Author: Nao
Date: Sat, 05 Apr 2014 16:36:29 +0200
Stats: 1 file changed; +11 (insertions), -6 (deletions)

• The response prefix was being cached for only a finite amount of time, when there's really no need to recalculate it except when changing language settings (in which case the cache is invalidated anyway.) (Subs.php)

[Commit revision ba2d42e]
Author: Nao
Date: Fri, 04 Apr 2014 22:54:26 +0200
Stats: 1 file changed; +2 (insertions), -2 (deletions)

• IE 10 and IE 11 perfectly support CSS gradients, so they don't need the filter hack. Only IE9 does. (Subs-Cache.php)