XF 2.1 Approval queue improvements, Admin options UI tweaks, Guest page caching and more!

Welcome to the fifth in our "Have you seen...?" series for XF 2.1. In case you've not yet seen the previous entries, (why not?!) you can check them out here.

As ever, to ensure you're kept up to date, we strongly recommend giving that "Watch forum" link a tap and make sure you enable email notifications if you haven't done so already 🙂
 
Click to expand...
Redesigned approval queue

The approval queue can be a fairly daunting place. It contains a lot of information all laid out in a long column with the relevant actions being at the bottom. We've redesigned how this information is displayed in XF 2.1 and overall still kept the important information. For developers, the template code to create an approval queue item is simpler too.

This is what the approval queue looks like now:

localhost_21x_index.php_approval-queue_ (2).webp


There is now a greater focus on the content itself that needs to be reviewed, with the actions being listed over on the right.

To make navigating through the queue easier, we've now added a new filter bar.

localhost_21x_index.php_approval-queue_&content_type=user&order=content_date&direction=desc.webp


As well as being able to filter the list by content type, it is also possible to sort the queue in descending order so that you can view the most recently created entries first, if you wish.
 
Spam cleaning action from the approval queue

One common reason for content ending up in the approval queue in the first place is through spam detection. It's always been possible to spam clean from the queue but the process was to click the username/avatar, click the cog icon menu, click "Spam" before finally having to confirm the options.

We've streamlined this process in XF 2.1 by making "Spam clean" an explicit action you can take directly from the queue. If the user who created the content could be a spammer (based on how long they've been registered, how many posts etc.) then the "Spam clean" action will appear.

We do not ask you to confirm any options, we simply use whatever defaults you have set and just clean the user and all of their content.
 
New blocking auto jobs

XenForo has two types of jobs that we run inside our "job" system. The first is a fully background job, which runs things like cron entries which happen totally silently in the background. The second is a "manual job" and as an admin you might run these by performing a specific action (like many of our rebuild tools) where we display a confirmation of the steps being run, progress, and requires the person who triggered it to have their current browser tab open until it is finished.

XF 2.1 brings a new type of known as an "auto blocking" job. This kind of job is very similar to manual jobs in that it displays a modal window to give you information about what is being run, but it is also similar to a fully background job in that whether or not you see its progress (maybe if you close the tab, or similar) it will still run to completion. If you wait for it to finish, you will be then redirected to an appropriate page.

This might seem like a fairly technical and subtle difference, but it's worth noting because we're first making use of this type of job when processing the approval queue.

A spam clean action has the potential to run for a significant amount of time so we're now processing the entire queue using one of these blocking jobs:

xf21approvalqueueblockingjob.webp


Once complete, you will be redirected back to (a now empty) approval queue.
 
Admin options UI tweaks

We already ship a huge number of options with XF and the list of option groups only gets more crowded as you install more and more add-ons. It certainly sometimes feels like you "can't see the wood for the trees" so we've now given developers the ability to associate Font Awesome icons to their option groups just to give a little bit of visual separation between an otherwise long wall of text.

localhost_21x_admin.php_options_ (1).webp



Quick access to option groups in the Admin CP

In addition to this nice visual tweak, we felt that sometimes option groups were something that needed to be accessed fairly frequently across different tasks in the Admin CP.

localhost_21x_admin.php_users_search&last_user_id=6.webp


There was some speculation about what the "cog" icon next to search might have been for. And although it isn't exciting as some of you might have been hoping for, it is definitely useful. Clicking it will show you all option groups:

localhost_21x_admin.php_users_search&last_user_id=6 (1).webp
 
Widget display conditions

If you have ever had to display a widget, but only conditionally based on user group or some other criteria, then you'll know that this isn't exactly straightforward. The current approach actually requires you to create the desired widget without assigning it to a position, and then create a HTML widget to add your conditions manually and call the widget you want.

One of the things many people have told us they like from our Navigation feature is the ability to use template syntax-like conditions so it made a lot of sense to bring that feature to widgets too.

If you have a widget that you only want to display to a specific user group then it's as simple as adding something like this to the new "Display conditions" field:

localhost_21x_admin.php_widgets_members-online.6_edit (1).webp
 
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.
 
Guest page caching

With the previous changes in mind, we can still do more to reduce the overhead from this significant portion of your visiting users. Most of these guests have something in common - they're all viewing exactly the same content. They all have the same permissions and there is no user specific UI elements, but we still go through the full motions of fetching all of the data and rendering it for each and every user on each and every page they visit.

This is slightly wasteful on server resources so it makes a lot of sense to cache the page output and return the cached output for these users. Therefore, full page result caching can be enabled for guests. This takes into account the selected language and style, if you have multiple, and handles things like ensuring the correct CSRF (security) token is applied.

Guest page caching is enabled via the config.php file and uses a distinct cache "context" to avoid issues that may occur if you put page cache data into the same bucket as sessions. By default, most pages will be cached, though this can be opted-out as necessary in PHP code. However, advanced users can control what routes are cached via prefix or a regular expression. By default, pages are cached for 5 minutes to balance speed against recency, though this can be changed. (Very advanced users will have access to configure some of the page cache options programmatically.)

When serving a guest page, by default, we will record the correct "session activity" record to maintain your online user counts as before, though for users after more speed, this can be disabled. With this disabled, depending on your exact configuration, no database connection may be necessary to serve a cached page.

In basic tests, pages have been served from the cache in less than 0.01 seconds. Your mileage may vary, of course, but these kinds of savings will represent a significant improvement in handling guest requests on a busy server.
 
BassMan said:
Yes! Is there any possibility to edit the post content from approval queue?
Click to expand...
No, this was a conscious decision in XF2 and very likely won't be coming back, ever. It added unnecessary complexity to the system when the controls to do any sort of edits are just basically a click away by going to the content. It was also unnecessarily constrained. e.g. it pretty much only allowed you to edit the title and the body of the content, but that doesn't really always apply.
 
Chris D said:
Admin options UI tweaks

We already ship a huge number of options with XF and the list of option groups only gets more crowded as you install more and more add-ons. It certainly sometimes feels like you "can't see the wood for the trees" so we've now given developers the ability to associate Font Awesome icons to their option groups just to give a little bit of visual separation between an otherwise long wall of text.

View attachment 186073
Click to expand...
How do you enable this in the ACP for 2.0.10?

D'oh! Sorry... this is for the forthcoming 2.1 version. :whistle:
 
Great work, unless I've already missed it, is there any option to do bulk actions for the approval queue? I have almost 16000 entries in mine and it's unfeasible to go through each one - doing bulk actions would save a lot of time and I can clear that queue out much better.
 
Back
Top Bottom