Fixed Batch update users broken in 2.2.12

[FTL]

For what it's worth, the bulk update worked for me when I deleted Rejected users, ie spammers (no errors) so this is the first I hear of this issue. I know to wait for a fix now though.

 

[⭐ Alex ⭐]

The custom title is not the issue - the actual issue is deeper in the code. Others mentioned commenting out the IF but doing that caused errors. I added the code I did so the script would not fail.

A better solution that seems to work is making a backup of your original, then replace it with an earlier version - I tried 2.2.11 and it worked fine without any code changes except for changing the STATE of the users - I wanted to change the STATE to "bounced email" and that only did the change on about 80 of the 1500 I needed it to.

K a M a L described the issue as $customTitle is never an empty string but instead it gets assigned null which causes the if statement to be faulty as it attempts to filter out empty string as the disallowed value when it should be filtering out null as well which is also equivelant to an empty string in terms of lack of meaningful data.

Therefore combining a null and empty string check should do the trick in this spot.

 

[pattycake2]

Now that I was able to batch update my secondary group ids, i'm content now waiting for the official release and fix

 

[ActorMike]

I need to batch-update our users to lock dormant accounts. Hopefully, there will be a fix soon as this is a security issue!

Spammers posting through existing accounts with no need to login?

And, worse, with no need of stealing such account. The fact is that since a week ago or so I am getting some spam messages posted by users with little or no activity, but registered years ago. All IP's are located next, and the message is tipically a link to a Telegram channel related to...

xenforo.com

 

[ActorMike]

For what it's worth, the bulk update worked for me when I deleted Rejected users, ie spammers (no errors) so this is the first I hear of this issue. I know to wait for a fix now though.

This did not work for me for batch updating a security lock.

 

[clackey]

This did not work for me for batch updating a security lock.

Same for me. Tried on several of my forums using v2.2.12 and no luck. The one time I needed to batch update to stop the spammers from accessing old accounts, can't do it.

 

[Chris D]

For now the recommended workaround is as follows.

Edit src/XF/Job/UserAction.php.

Find:

$customTitle = $this->getActionValue('custom_title');
if ($customTitle !== '')
{
   $user->custom_title = $customTitle;
}

Replace with:

if ($customTitle = $this->getActionValue('custom_title'))
{
   $user->custom_title = $customTitle;
}

This will flag files with unexpected contents which you can ignore for this file until the next release.

 

[gotski]

Batch update users also stopped working for me when I try to batch delete users from one secondary group and add to another, before update it used to work fine.

 

[htsumer]

Waiting for an update to fix this problem

 

[ActorMike]

Waiting for an update to fix this problem

I did what @Chris D suggested and it worked for me- https://xenforo.com/community/threads/batch-update-users-broken-in-2-2-12.211063/post-1610382

 

[htsumer]

I did what @Chris D suggested and it worked for me- https://xenforo.com/community/threads/batch-update-users-broken-in-2-2-12.211063/post-1610382

That topic is a solution to another problem. My problem is in bulk updates

Batch update users broken in 2.2.12

Since 2.2.12 .. batch update users feature is broken due to this weird change at XF\Job\UserAction $customTitle = $this->getActionValue('custom_title'); if ($customTitle !== '') { $user->custom_title = $customTitle; } where $customTitle will never be...

xenforo.com

 

[htsumer]

I did what @Chris D suggested and it worked for me- https://xenforo.com/community/threads/batch-update-users-broken-in-2-2-12.211063/post-1610382

You were right. Fixed

 

[Missbhaving]

For now the recommended workaround is as follows.

Edit src/XF/Job/UserAction.php.

Find:

$customTitle = $this->getActionValue('custom_title');
if ($customTitle !== '')
{
   $user->custom_title = $customTitle;
}

Replace with:

if ($customTitle = $this->getActionValue('custom_title'))
{
   $user->custom_title = $customTitle;
}

This will flag files with unexpected contents which you can ignore for this file until the next release.

This would be lovely if I knew what I was doing, and I don't.

This is also causing an issue with our payment add on which adds users to a secondary group upon purchase.

Will this be a fixed anytime soon for the not so technically minded as I won't mind renewing my licence if it is.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.13).

Change log:

Properly set custom titles when batch updating users

There may be a delay before changes are rolled out to the XenForo Community.

 

[hello2029]

For now the recommended workaround is as follows.

Edit src/XF/Job/UserAction.php.

Find:

$customTitle = $this->getActionValue('custom_title');
if ($customTitle !== '')
{
   $user->custom_title = $customTitle;
}

Replace with:

if ($customTitle = $this->getActionValue('custom_title'))
{
   $user->custom_title = $customTitle;
}

This will flag files with unexpected contents which you can ignore for this file until the next release.

After making the above changes, everything seemed to work fine. However, I received a message. Can you guide me on how to deal with this situation?

 

[Paul B]

You have manually edited the file so naturally that message will show.

Just ignore it.

 

[htsumer]

After making the above changes, everything seemed to work fine. However, I received a message. Can you guide me on how to deal with this situation?

This will flag files with unexpected contents which you can ignore for this file until the next release.

 

[sdchan]

I upgraded to the latest release of XF. However, batch updating users (in particular, adding a secondary user group to users) takes something like 3 seconds per user. I have 20k users, so updating everyone could take about 17 hours - is this correct?

 

[Paul B]

This is a resolved bug report.

Post in the support forum if you need assistance with something.