XF 2.2 2.2 and $visitor->user_id

Lawrence

Well-known member
This is not a question, but more of an informative post. As developers, have you noticed an increase in queries for any of your add-ons since updating to XF 2.2? If you haven't checked, you should. I'm currently working on updating my contacts add-on, and by a fluke noticed that a guest caused a query that should only happen for a logged in member. The reason is that guests can now post before registering, and so are assigned a user_id (a very big one, but one nonetheless).

if ($visitor->user_id) may return true for a guest depending on where this check is done (forum view in my case) and may cause unnecessary queries. My solution was to do a if ($visitor->username), and that removed the query that should not have happened for a guest.

That's all, :). Happy and safe coding to all.
 
Do you have a more concrete code example that causes an unexpected query?

Regardless of the ability to post before registering, a guest should never have a user ID.
 
The reason is that guests can now post before registering, and so are assigned a user_id (a very big one, but one nonetheless).
To clarify, this doesn't apply to guests. It applies to checks using the pre-reg action user, which is for the write-before-registering stuff. It's actually to specifically bypass checks that are for registered users only, on the basis that the action being taken is something that happens after the user is registered (and thus the registered constraint is correct).

I'm guessing you might be extending a check like canCreateThread, which is something that gets called in the context of the pre-reg user (canCreateThreadPreReg).
 
Do you have a more concrete code example that causes an unexpected query?

Regardless of the ability to post before registering, a guest should never have a user ID.

I'm extending canCreateThread, see the SS for the user_id for the guest user:
 

Attachments

  • extra_query.webp
    extra_query.webp
    95.8 KB · Views: 26
Anyways, this is something that we should have been notified of, why? Because when I check my add-ons for compatibility issues for 2.2, I check TM's for failures or extra apply counts, run my add-ons to be sure no errors and they work as designed. Never have I thought of checking for additional queries that should not be there but are after an upgrade, so now any add-on I have that extends canCreateThread must be re-checked. Other devs should check their add-ons as well. A query is a horrible thing to waste.

Maybe it's just me, and all the other developers picked up on it a while ago.
 
Top Bottom