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 🙂
 
Probably just a sign of me running out of witty(?) ideas ;)

We're about half way through the HYS series for XF 2.1 now but still plenty more to show :)

13 NOV 18 is my prediction for a release of note in the 2.1 range.

Its properly teasing all these HYS ..
 
I'm loving these updates. The guest page cache and session is really cool: Better Site Speed.
Moderation queue and spam cleaning will save us time.
Same for auto-blocking jobs. No more waiting for hours long rebuilds.
 
Please consider if this can be enhanced some more. It would save a lot of work for us.
Most of what you mentioned wouldn't be down to us to implement, really.

If you have an add-on that auto-moderates content based on reactions, then really it should be that which is inserting/displaying the relevant information. For some things it would be the absence of data which indicates why it ended up there (e.g. right now if a user is moderated because that's what your settings are then they wouldn't have any spam logs displayed.
 
That's not what it does. The rebuild jobs are still what we call "manual" jobs and they still work in the same way as now.

Put simply an auto-blocking job is just a UI that can be displayed to the user who triggered the job (most likely) so they know a long running process is happening and be redirected when it is finished.
 
I've faked something like the blocking job for XF1 (basically kept polling to see if a deferred job has been marked as completed into a secondary table), nice to see explicit support for it in XF2.

@Chris D does this mean there is an xf_job_result like table around so the polling front-end can be reliably informed that a job they where asking for has finished?
 
By default, pages are cached for 5 minutes to balance speed against recency, though this can be changed.
Excellent and much needed feature.

Would this be configurable down to the second or just minute? We'd like to be able to keep things cached for roughly 30 seconds or so. Our active threads can move very fast.
 
@Chris D does this mean there is an xf_job_result like table around so the polling front-end can be reliably informed that a job they where asking for has finished?
No. The system isn't necessarily perfect (potential race condition). It mostly allows job.php to run a specific job and report some info back from it. There are theoretical cases where the job can be picked up elsewhere (as is roughly necessary to ensure the auto case). If the job isn't runnable for whatever reason, we will consider the job done (otherwise that could lead to an infinite loop). You can detect whether the job in question has finished by its presence in the job table (as running jobs are still present, though with a future date).

This is mostly designed around processes that might take a little while (like a whole bunch of spam cleans) and thus need job support but should ideally give the user some feedback if possible. In the case of the approval queue, an immediate redirect back after job queuing may still show the content that you just took an action on. (Thus, it tends to be more targeted at moderator actions.)

If you want a more generic system, then you'd need to develop something specific for your use case.

Oh I thought this was when that work is put on a non admin user, like for Crons.
Not for crons, but this is something that gets displayed on the front end, though it's for specific situations you opt into it. It's use case is fairly specific and likely to be targeted mostly at privileged users.

The message displayed is based on what your job reports.
 
Would this be configurable down to the second or just minute? We'd like to be able to keep things cached for roughly 30 seconds or so. Our active threads can move very fast.
Yes, you can set the lifetime in the config file, though obviously a shorter lifetime will reduce the efficacy.
 
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:

View attachment 186076
WoW!
I heavily use this thing via BD Widget addons.
Mostly for serving custom ads.

Is it possible to have it also for advertisement slots?
 
It seems a bit superfluous for advertising slots as the advertising content supports XF template syntax any way.
 
Top Bottom