XenForo 2.1 and beyond

sanction9 · Oct 22, 2018

Destroy Repeat said:
On a side note (since I can't post on the official forums): I would like the option to either: Turn off video uploads, or tinker with permissions as usual, to allow or disallow users to upload videos. I can see abuse happening to xenForo 2.1 owners.

You'll be able to disable them. Chris D has already said "...you can effectively disable video uploads by removing the allowed extensions."

That would have been a serious F-up on their part if there was no way to do that, on top of having no privileges (which is bad enough).

CarlosX360 · Oct 22, 2018

sanction9 said:
You'll be able to disable them. Chris D has already said "...you can effectively disable video uploads by removing the allowed extensions."

That would have been a serious F-up on their part if there was no way to do that, on top of having no privileges (which is bad enough).

Thanks for the info!

Boothby · Oct 23, 2018

Chris D How is the current support of older versions policy, what version is going EOL when 2.1 reaches stable?

zappaDPJ · Oct 23, 2018

Boothby said:
Chris D How is the current support of older versions policy, what version is going EOL when 2.1 reaches stable?

There does seem to be concern and a little conjecture that XenForo 1.5.22 may become EOL much sooner than some of us expected. Any information to clarify its ongoing status would be very helpful.

Steve · Oct 23, 2018

zappaDPJ said:
There does seem to be concern and a little conjecture that XenForo 1.5.22 may become EOL much sooner than some of us expected. Any information to clarify its ongoing status would be very helpful.

I think Chris posted in the last couple days stating there is nothing set in stone yet. I’ll see if I can find that.

Steve · Oct 23, 2018

zappaDPJ said:
There does seem to be concern and a little conjecture that XenForo 1.5.22 may become EOL much sooner than some of us expected. Any information to clarify its ongoing status would be very helpful.

https://xenforo.com/community/threads/continue-to-using-1-5-risque.144143/post-1231417

https://xenforo.com/community/threads/reactions-👍😍🤣😲🙁😡.154898/post-1290039

dethfire · Oct 23, 2018

zappaDPJ said:
There does seem to be concern and a little conjecture that XenForo 1.5.22 may become EOL much sooner than some of us expected. Any information to clarify its ongoing status would be very helpful.

Why concern? 1.5 right now is very stable. I think they should focus 100% on XF2.1 and beyond unless there is a big security bug.

CarlosX360 · Oct 23, 2018

Boothby said:
Chris D How is the current support of older versions policy, what version is going EOL when 2.1 reaches stable?

Worth noting, the pattern of EOL begins when the developers are knee-deep in development of a new version, such as 2.0... You should expect them to slowly, but surely stop support for the older version (e.g. 1.x), it has always been this way since the beginning.

So, if you're not already on 2.0, get going.

xenForo released this HYS thread... Awesome features, but I had one question, and am still scratching my head...

Reduced session usage for guests

We already provide a caching layer which, if configured, allows you to offload sessions out of the database. In the case of guests, which most likely accounts for the majority of your online users at any given time, session reads and writes (regardless of where they're stored) presents a fairly significant overhead. To reduce this overhead, we've implemented some changes in XF 2.1 which reduces the need to interact with sessions for guests.

First and foremost, we will no longer write a session at all if the session has no data. For that to work, we need to make sure we're not unnecessarily storing data in the session in the first place.

One such area which we decided to take out of the session is the indicator we use to know whether or not any given guest user was referred to the site via a search engine. Rather than storing this in the session data, we now store this in a cookie.

Also stored in the session was a record of the result of the last time we checked that user to see if their IP address had been banned or discouraged. As this is generally very quick to calculate, we've decided to not cache this at all going forward which most likely has an overall net benefit in that we no longer need to read/write this.

Ultimately, with these tweaks in place, most guests will rarely need a session record at all which mostly eliminates a database/cache write on many pages.

What does all this mean, especially bolded? Does that mean users can come back to the site and re-view the site? I'm not talking about "review," I'm talking about viewing the site again, and/or re-registering, etc.

Chris D · Oct 23, 2018

Boothby said:
Chris D How is the current support of older versions policy, what version is going EOL when 2.1 reaches stable?

zappaDPJ said:
There does seem to be concern and a little conjecture that XenForo 1.5.22 may become EOL much sooner than some of us expected. Any information to clarify its ongoing status would be very helpful.

When we’ve settled on a specific timeline, we’ll publicise that.

Incidentally, what exactly are people’s expectations with regards to us making 1.5 EOL?

Hopefully it ties into what we’re currently thinking

dethfire · Oct 23, 2018

Chris D said:
Incidentally, what exactly are people’s expectations with regards to us making 1.5 EOL?

My opinion is, I'm expecting 2.1 to be so good, it would be strange for someone to stick to 1.5 in the first place and I am someone with a ton of custom work.

Chris D · Oct 23, 2018

Destroy Repeat said:
What does all this mean, especially bolded? Does that mean users can come back to the site and re-view the site? I'm not talking about "review," I'm talking about viewing the site again, and/or re-registering, etc.

It just simply means we no longer cache the result of the banned/discouraged IP check in the session. We still check if the user has a banned/discouraged IP, but we don't cache the result of that check as there's theoretically more overhead with that than just fresh checking the IPs on every request.

CarlosX360 · Oct 23, 2018

Chris D said:
It just simply means we no longer cache the result of the banned/discouraged IP check in the session. We still check if the user has a banned/discouraged IP, but we don't cache the result of that check as there's theoretically more overhead with that than just fresh checking the IPs on every request.

So, it's theoretically a background task...? And not user-facing...? If I have them IP Banned/Discouraged, they'll still see the message "IP Banned"?

Chris D · Oct 23, 2018

The IP ban check process before was (first page view):

We'd do a fresh check per-user to see if their IP was banned.
The result of that check is cached in the user's session.
If the check tells us the IP is banned, they are told they are banned.

Subsequent checks (subsequent page views):

Get the result of the original check from the user's session
See step 3 above.

The only thing that has changed is the process is now this, on every page view:

We'd do a fresh check per-user to see if their IP was banned.
If the check tells us the IP is banned, they are told they are banned.

CarlosX360 · Oct 23, 2018

Chris D said:
The IP ban check process before was (first page view):

We'd do a fresh check per-user to see if their IP was banned.

The result of that check is cached in the user's session.

If the check tells us the IP is banned, they are told they are banned.

Subsequent checks (subsequent page views):

Get the result of the original check from the user's session

See step 3 above.

The only thing that has changed is the process is now this, on every page view:

We'd do a fresh check per-user to see if their IP was banned.

If the check tells us the IP is banned, they are told they are banned.

Oh, okay. So, basically a background check. I got it now.

Chris D · Oct 23, 2018

It's not really a background check. The check just happens on every page, whereas before we'd use the cached result of the previous check.

CarlosX360 · Oct 23, 2018

Chris D said:
It's not really a background check. The check just happens on every page, whereas before we'd use the cached result of the previous check.

I know. I just assumed that the "check" acts like those plugins where the first time user can see a thread, but subsequent views are blocked. So, from my view, when I read it - I was thinking "does that mean the session is gone as soon as the IP Banned user sees it again...?" I'm not a techie guy, but I probably just misread it.

But what it sounds like, is that xenForo is running a check in the background asking if the member is IP Banned (just an example, I know the post means to talk about everything else), so that's how I said "background check." You don't know if the check is going on, but it is. So, relax.

zappaDPJ · Oct 23, 2018

Chris D said:
Incidentally, what exactly are people’s expectations with regards to us making 1.5 EOL?

I would expect it to be already feature locked but I'd like to see bug fixes and ticketed support continue for at least six months after 2.1 final. From then on I'd like to see security patches issued for a couple of years assuming there's still the user base to justify it.

Chris D said:
Hopefully it ties into what we’re currently thinking

The ball is now in your court on that one

doubt · Oct 23, 2018

Chris D said:
We'd do a fresh check per-user to see if their IP was banned.

If the check tells us the IP is banned, they are told they are banned.

Why is it necessary to check visitors' IPs?
With a proxy they can see all pages which are visible for guest.
Check the IPs only when they want to login to see permitted pages for members..

CarlosX360 · Oct 23, 2018

doubt said:
Why is it necessary to check visitors' IPs?
With a proxy they can see all pages which are visible for guest.
Check the IPs only when they want to login to see permitted pages for members..

For matching purposes. Proxies can be banned, too. However, how many times that user uses the proxy isn't relevant. Because you can technically ban a range, with a wildcard, e.g. * [like so: 00.*] However, there may be legitmate users in that range, sooo... make sure that the range is a repeat proxy server.

Chris D · Oct 23, 2018

zappaDPJ said:
I would expect it to be already feature locked but I'd like to see bug fixes and ticketed support continue for at least six months after 2.1 final. From then on I'd like to see security patches issued for a couple of years assuming there's still the user base to justify it.

The ball is now in your court on that one

I don't think security fixes would necessarily be for that long. Just plucking some random numbers out of my head, it might be something like 12 months, though of course it would be totally discretional and depending on their severity.

If it's anything like the security issues we've had before which have been generally incredibly few, obscure and fairly minor, I wouldn't expect to see that kind of thing being fixed beyond 12 months (or whatever it ends up being).

Clearly, if the installed user base was still significant (unlikely) and it was a particularly nasty issue (also unlikely), then we would likely stretch that.

XenForo 2.1 and beyond

Adherent

Fan

Enthusiast

Moderator

Fanatic

Fanatic

Habitué

Fan

XenForo Developer

Habitué

XenForo Developer

Fan

XenForo Developer

Fan

XenForo Developer

Fan

Moderator

Tazmanian

Fan

XenForo Developer