Wedge

Even when not at the edge..?
Great... Means they're gonna break a lot of web apps... ::)

Oh well, I suppose I could change it to a right-to-left swipe. If it doesn't also take over this..???!!!

Yes, but you may not 'notice' the new posts, though... In general, you'd want to be informed that there have been more posts.
Also, don't forget that if you have 15 posts on a page, and you post a quick reply, you'll get the post on the same page, so if you're copying the URL of the page to show a friend, they may not see the post you were pointing to, because it's really on the next page, etc...

Short summary about infinite scrolling: I thought I had the 'perfect' UX for this, and implemented it. I was quite happy with it. Then I did some further research, and noticed that another forum software (Discourse) bragged about having infinite scrolling, but it seems like it only does it for topic lists, not for topic pages, so they took the easy way out, I'd say... Unfortunately, from my countless experiences, and observation of other non-forum implementations, I can only say one thing: infinite scrolling is only possible if you have one of these two implementations: either an app setup using a customized JS framework like Backbone.js (which would force a forum system to rewrite its JS entirely), or a setup where you know *beforehand* what the contents of the post will be, and you can control it... Because if you can control it, then you can easily get away with incremental rewrites of your JS to apply to the new posts, and you're good. It is doable for Wedge, *even* for video embeds, but this is where the limitation is: we have no way to know what plugins will do to posts, and while it's unrealistic to expect many plugins to apply JS to a post (and if they do, the author might be aware of things to do to update for the infinite scroll's new posts), and thus it might break at any point, which is not good... :-/

So, two possible solutions, I'd say...

- Rewrite the current JS more thoroughly, to 'ensure' everything will work fine, and expect plugin authors to be aware of this.
- Give up on Ajax loading of new posts, and instead turn my infinite scroller into a generic helper function. This is my fallback idea, and it makes sense: detect 'Previous' and 'Next' links, and if the mouse wheel shows intent to go to Prev/Next, automatically follow these links, which would be applicable to *any* page with a pageindex, such as the topic lists, topic pages, member lists, etc...

I don't really see myself do *both*, but it's also doable, I guess...
To begin with -- what do you think of this fallback solution, is it any good to you..?I tried iframes as content holders... And I gave up. It sucks, in so many ways. Then I tried iframes as temporary content holders, until I can move their contents to the main page, and destroy the iframe. Problem is: while the events get copied properly, the event's targets stay in the iframe. e.g., if you click 'Delete' on a post, the confirm box shows up in the iframe, not in the main page...
That was a real bummer, for me...

Still, I'm counting on your insights, maybe you're less lost than I am, eh.. ;)

Ajax quick reply is easy. I can write it if you want.
Problem is the same when it comes to adding plugin data though... other than that, it's just the same as doing infinite scrolling with one post.

One major issue is if someone else posted in the meantime. But then you can always do a hard redirect to the post page then...

What if we rename views to something else like reach or popularity, then we can get away with counting only members..? Also, maybe count only one visit per member?

I can't believe I've spent so much time on this feature...
Even though I haven't posted here in two weeks, I regularly tweaked my code, to try and get it to run without issues.

While loading a 'regular' page works fine, if the page has any video embeds, all hell breaks loose.
And, I just can't be happy with that...

I've done countless rewrites, and I always come back to the same thing... "Give up, Nao. Give the fuck up, and do it another way."
The "other" way being, call me a chicken, simply loading the previous/next page when using the wheel, rather than ajaxively loading it and adding it to the page. Basically, simply tie the "mouse wheel movement past the end of the page" action to the "go to next page" link.

Well, at least, it would work flawlessly... :-/
Or should I just be super-happy with an infinite scroller that will work on 'basic' code, but not on anything complex added by plugins in posts...?
That is the question, I'm afraid.

This consideration might have been important years ago, but nowadays web hosting is generally done on powerful CPUs with lots of RAM etc, and an extra SQL query (or not) is usually not so important... Just look at the Wedge codebase, literally for every page it runs dozens of preg calls, many queries, does thousands of tests, and yet you're aware that our software is extremely fast, because most of the work is done over the network and the client, more than the server, so is it that big a deal, anyway..?

In any case, I'd at least like to keep the topic views enabled for members, and drop guests altogether, I wouldn't mind that too much really, but that's really the best I can do right now, I reckon...

I'm more suspicious of adding an 's' than removing it, actually... ;)
"It's a move", "it's a like", etc...

Another thing with topic views, is that without them, you lose an entry in the stats page, which is not always the same as topic replies, although we could rework this to only request topics that aren't in both stat columns, etc... :^^;:

Nope, WP has never supported this. They expect you to rely exclusively on external statistics tools. It wasn't pleasant.