XF 2.2 Assorted improvements

misc_3.png
We're fast approaching the time where we're able to unleash XenForo 2.2 on this very forum but, before we do, we wanted to tell you about a few slightly more miscellaneous features that we've been keeping under our hat.

Advanced options switch

The eagle-eyed amongst you may have already spotted some hints about this in some of our earlier screenshots. 🤫

XenForo has an ever-increasing number of options and then by the time you put add-on options in the mix, the options pages may start to feel somewhat daunting and unwieldy at times, especially for new admins to the platform. After all, there are nearly 200 options in XenForo alone.

We (and add-on developers) are now able to mark options or entire option groups as "advanced".

misc_1.png

What this intends to do is simply hide some of the options we deem to be more "advanced" so as to simplify the option lists while also making it very easy to unhide if the need presents itself.

To do this you can toggle "Advanced mode" for your admin account. The easiest way to do this is from within the option list itself when options are hidden. Clicking "Show them" will reveal the advanced options and enable "Advanced mode" permanently for your admin account.

misc_2.png

An alternative and perhaps slightly more pre-emptive way to enable Advanced mode is from the "cogs" menu in the admin control panel header. You just need to toggle the checkbox in the menu footer:

misc_3.png

Other places you can toggle it are from the list of option groups and while editing an administrator account.
 
ES, MG, RM are still to come it's not clear if there will be a pause but likely since they are still working on those features. Also not clear if core is done. Tomorrow will be the tell-tale. Post or pause. ;)
 
Hmm, I am not completely sold on the alert changes - in fact I think they might be confusing as users find it very hard to understand the nuanced difference between "viewed an alert" and "read the content".

We've recently migrated a froum from WoltLab to XenForo 2 and it took a lot of support to explain users "why alerts don't work on XenForo":
  • On WoltLab, opening the alert menu does "nothing" (it just does display the alerts) - on XenForo it marks the alerts read (XF 2.1) or viewed (XF 2.2)
  • On WoltLab, reading the content not only marks the alert read but also deletes it

We've had endless complaints from users about 1) "not getting alerted/missing alerts" (from users who opened the menu and did not read the content for every alert) and "alerts not getting marked read" (from users who read the content but were confused the alerts are still being displayed in the menu).
We've installed @Xon's Alert Improvements which did help group 1) a lot, but group 2) still does complain.

I'm therefore pretty sure that this change will yet again cause a lot of confusion and require a lot of time to support.

Ideally, I think the system should be flexible enough to allow users to work like they wout like it to be.
Obviously changing from one software that does one thing, to another that does something else is going to require some adjustment.

The same, if not worse, adjustment would be needed going the other direction. If you're used to how the XenForo alerts work, going to something like WoltLab would equally seem confusing.

I don't necessarily think their approach is better or clearer it's just what those users were used to. So we can't really help with that.

The changes are somewhat subtle for users who don't care about the details of what constitutes viewed versus read alerts and I don't envisage they'll notice much difference if they're coming from XF 2.1 to XF 2.2.

For power users, the nuance makes the alerts list more useful as there's a greater distinction between alerts that may indicate you need to take action such as view a post to see why you've been mentioned, or go and read a watched thread that's just been replied to versus those that are more informational like someone reacted to a message.

Anyway, try it on for yourself when we upgrade to 2.2 here then make some practical suggestions if you think there are improvements we could make.
 
By default we will continue to trigger jobs based on site activity, but if needed you can switch to a server-based trigger. This involves periodically executing a new CLI command xf:run-jobs.

Note: You will be responsible for putting in place some sort of config for crontab, cron.d, system.d or other task running process to ensure the command is run as expected.
:love: (y) :cool:

Great for heavy RSS feed import users on light traffic based forums :D
 
I don't necessarily think their approach is better or clearer it's just what those users were used to. So we can't really help with that.
Uhm, actually you could - by providing options for end users to make the system behave like they want it to be :)

Anyway, try it on for yourself when we upgrade to 2.2 here then make some practical suggestions if you think there are improvements we could make.
I am not that biased towards either approach, both are fine to me so there isn't much for me to try at all .
So basically I've already made the necessary suggestion:
Provide end users with options to setup alerts for them like they want them to be behave.

Re Job run trigger
If this is configured to be run by a system cronjob, will the public JS for job handling still be delivered to users (especially guests)?
 
providing options for end users to make the system behave like they want it to be :)
An option isn't always the answer, and we especially don't feel it is a necessity here. Certainly you may feel free to open a formal suggestion and we'll be guided by feedback resulting from that.
 
Yes, reCAPTCHA does the same if whatever score they place on you isn't enough to conclusively prove you're not a bot.

It's likely to happen more with hCaptcha on the basis that Google already know too much about you by the time you initiate one of their CAPTCHAs...
 
Yes, reCAPTCHA does the same if whatever score they place on you isn't enough to conclusively prove you're not a bot.

It's likely to happen more with hCaptcha on the basis that Google already know too much about you by the time you initiate one of their CAPTCHAs...
I'm completing it but I get this every time..
Oops! We ran into some problems.
You did not complete the CAPTCHA verification properly. Please try again.
 
This is something which is fixed in RC2 I believe, see:
 

Improved alerts behaviour

Some of you might remember a time before alerts were a thing. Alerts and notifications are everywhere in 2020 but over 10 years ago they were almost entirely unheard of, especially in forum software.

That's right, kids, there was once a time where you'd need to regularly traverse the entirety of the forum tree to find out if someone had replied to you yet, or not. That sometimes involved having to remember where you posted and physically go there.

giphy.gif

Now they're entirely common-place and whether it's forum software, mobile apps or any number of websites, the concept of alerts is now almost universal.

It's fair to say that you can receive a lot of different alerts and they all have slightly different contexts too. Some are more informational, such as notifying you of a moderator action, or a reaction someone has left on your post. Others may require your attention, such as someone replying to your post or mentioning your username.

Occasionally you might even need to refer back to a specific alert at a later date.

In XenForo 2.2 we've made some changes.


View attachment 228536

On the surface, it looks like little has changed, but quite a lot has.

First and foremost we now have a distinction between alerts you have viewed (in the menu, or in the full alerts list) versus the alerts you have read (meaning you have read the content to which the alert pertains).

The alerts menu now represents the number of alerts you have not yet viewed. Opening the alerts menu marks all of the alerts viewed.

You're able to toggle the read status of each alert individually or simply mark all alerts read if desired.

On an alert-by-alert basis the code that is triggering the alert to be sent can indicate whether an alert should be marked read automatically or not. As we noted previously, some alerts are purely informational so, as now, they can be marked as read automatically while others will stay in their read state until either you visit the content or you explicitly mark it as read:

You can also mark an alert unread by clicking on the read toggle indicator (the circle). An alert that is explicitly marked as unread will remain unread until you mark it read or visit the content, even if it was previously set to be marked read automatically, thus helping you indicate that an alert may still require some attention or action further down the line.

I can't help noticing that even when alerts are marked as read, they still stay in the dropdown list. It's just getting longer and longer. How can we get it to clear 'read' items automatically like it used to?
 
Top Bottom