[henrybb]

Hi guys.

I give up with the plugin hosting approval. Apparently I’m not enough of a celebrity around these parts to be hosted. Not that I give a shit, I’d just prefer that other guys don’t have to reinvent the wheel.

Besides, what the hell are they reviewing? All they have is the name of the project.

So I threw together a page about it, and threw in a zip archive of the plugin. It’s straight from my own installation, so let me know if there are any dependency issues (there shouldn’t be).

This plugin has accounting for where the user is in reading each topic. So it’s not for everyone. If you have a huuge board with alot of threads and users, you’re probably going to dislike it. However, it fits my needs, it isn’t too slow for my forum, and I’ll deal with the fallout when that happens.

So without any ado, or grace periods for the sake of elitism, here’s the damn plugin: http://henry.odg.cc/bb_unread_topics/

[fel64]

Jeez, you’ve totally got the wrong end of the stick here. The approval takes forever because he’s busy and working on other stuff, not because we’re in a giant elitist conspiracy that won’t host your plugins unless you’ve been on the cover of Hello!

[henrybb]

Well I’m allowed atleast one misconception aren’t I?

WordPress has the same weird approval stage. But what I don’t get is that I wasn’t given a chance to upload either the plugin or the readme, I just input the name of the plugin and the whole process hinges on that one name.

Started wondering if I was at all comfortable with “Unread Topics” as a name

Anyway, did you look at the plugin fel?

[fel64]

Err, no. I read your description here. I thought about that approach before but I like the time-based implementation, especially as my hosting is a bit creaky (and edit: having come to the finish of this post, I realise that it’s actually not that bad at all! Maybe it is a good idea, especially as it’s a lot more convenient). It’s good that you’ve done it though, and cool that you’re sharing it (in the face of adversity ). I hope you don’t mind; here’s some suggested changes that could speed things up a lot.

For installing the table, you may want to use bb_dbDelta() (should work exactly as wp’s implementation: https://codex.wordpress.org/Creating_Tables_with_Plugins ).

There are also a lot of queries made that you could probably avoid. For example, in the topic listing the current topic will be in the global $topic, and you can get its last_post_id by this:

$last_post_in_topic = $topic->topic_last_post;

You can do the same for the number of posts.

Every column in the table will be available as a member variable (don’t know how familiar you are with PHP? Member variables are just like above, $member->!!!member_variable!!!) – that’s true for users, posts, topics and forums alike. (Meta entries are too, if there’s an entry topic_colour in the topicmeta table you can call it by $topic->topic_colour.)

Right now you’re making at least three additional queries per topic:

if ( utplugin_is_topic_unread($topic, $user) || utplugin_is_topic_new($topic, $user) )

utplugin_is_topic_unread() makes three queries. If it’s not unread, it’ll check if it’s new, too, which is another two. For the default 30 topics, that’s 90 – 150 additional database queries per single view of a page. Since db queries are usually the bottlenecks in website speed that could be a problem. (_ck_ would probably blow an artery.)

By using the already-queried stuff from global $topic you can cut that down to one or two topics per query. Also, in utplugin_is_topic_new() you’re using exactly the same value again, but making a new query for it, if I see that right. You could either move the check to utplugin_is_topic_unread() (which would return true for unread and for new) or make that a global itself.

That would make it at most one query per topic.

Finally, IIRC data for all topics on the page is being called in a single query. If you can find the right filter or hook, you may find that you can get all the relevant topic_ids at once, at the start, then do a _single_ query on your table that gets data for all of them, make that a static (so it’s preserved every time the function is called) and use that data every time. Then the overhead generated by your plugin wouldn’t even be so bad.

[henrybb]

Cool!

Yeah, I haven’t really done much in PHP. And I basically hacked this plugin up in two evening sessions.

Thanks for the suggestions, I’ll have a look at the code again. )

Actually the number of posts stuff was an idea that didn’t pan out.

The two functions for new/unread were actually that there initially was just the unread stuff, then I added the “new” check so it would bold new topics. I need a different one for the topic_link filter, cause I don’t want to change the link for brand new topics.

[henrybb]

Hey.

I asked my friend Steinn to have a look at the code with a fresh pair of eyes, cause he’s more of a php coder than me. He simplified the thing quite a bit as per your ideas.

I then changed it to use the bb_dbDelta() function following the instructions from that link you gave me. So now I have version 0.4.

I hope someone can test it for me.

http://henry.odg.cc/bb_unread_topics/

[Sam Bauers]

You should consider just tracking what the last time was each user viewed a topic. That will reduce the number of entries in your table to a maximum of one entry for each user on each topic, rather than one entry for each user on each post.

As for the delay in getting plugin “approval”, you aren’t alone. I’ve waited a while at times and had to poke for it to get done, approval is less about the question of “is your code good enough” and more about weeding out spam/bozos etc. Also, from what I understand mdawaffe is pretty much the only developer doing significant work on bbPress at Automattic and he has other responsibilities there as well (including maintaining the WordPress plugin browser).

The community here is growing, but small, and the few people who are regular contributors to this forum are really quite helpful, enthusiastic and generally pretty knowledgeable. I hope you feel more welcome as you get to know us and become more involved.

[henrybb]

SamBauers: Hmm ?

The current implementation has one row per user per topic as it is. Instead of using something like time, I use the topic_last_post_id from the topics table. Then I have a table which essentially is user_id | topic_id | post_read. Which contains the very last post in a topic the user has read.

The implementation is far from perfect, the code that updates the table is getting run each time a post is rendered. Which means 29 useless sql updates per page.

I just need to get some time to look at the code to find another way. But as it is, it works.

I suppose I’ll be more involved, as there are some features I need to make for myself. I see no reason not to share the work.

[henrybb]

Damn!

There’s no filter for get_thread()!

Is there any design decision behind not allowing people to hook into that?

As I said, for a full page of posts (30), I’m updating my readlog 30 times, when all I really need to do is get things upstream at the get_topic() and just take the last dimension of the array and make that the last read post in that given topic for the user.

It’d save 29 SQL updates per pageload in busy topics.

So until there’s a hook there, or an epiphany for another spot I could hook into, Unread Topics 0.4 stands as the best I can do solution for indicating what the user has read so far.

[fel64]

There is one thing you can do – there’s a generic query filter that executes every time bbdb makes a query. You could use a regex to get the thread numbers from that. (If you don’t know regexes that well I could write it.)

Probably no design decision behind that, just an oversight. Go to trac, log in using your details here and create a new ticket requesting this (marking it as an enhancement not bug). Mdawaffle (^^) is busy with wp or something at the moment but when he sees it he’ll probably either implement or discuss at least.

[henrybb]

That solution seems a bit hackish to me and prone to incompatibility if anything changes in the code, such as a new condition gets added to the query.

[neyoung]

henrybb, thanks for the great plugin!

Is there a way that the the word “Sticky” could also be bolded when sticky topic has an unread post? Currently only the title of the topic is bolded. Other places that a similar thing happens is when you have the support forum plugin and _ck_’s polls plugin. Those two plugins prepend [poll] and [resolved] or [unresolved] to topic titles. I’d like the entire line to be made bold. If you or anyone else knows how to do this I’d appreciate the help.

[neyoung]

ok, I figured out that “Sticky” is not part of the topic title. But the poll and support forum plugins hook the topic_title function. To make the [Poll], [Resolved], [Unresolved] parts of the topic_title to show up as bold I modified one line in your plugin on line number 14 of bb_unread_topics.php . I changed

add_filter('topic_title', 'utplugin_show_unread');

to

add_filter('topic_title', 'utplugin_show_unread', 100);

By adding the 100 at the end of add_filter the utplugin_show_unread function will execute after the other functions that book topic_title. While there may be functions that use a number higher than 100, I doubt it, so you should be safe.

[henrybb]

Hey neyoung! Cool to know you use the plugin

I don’t use stickies or those poll or bugtracking plugins so I didn’t know. Thanks for the info, I’ll include your stuff in the next release.

[henrybb]

Well! The plugin has been added to the plugin db:

https://bbpress.org/plugins/topic/69