rllmukforum

Thanks. An update is in the pipeline and we'll test this again afterwards.

We have two different options for subscribers to our site: Supporters, and Donors. Both cost the same amount per year. They are set up as subscription plans within the commerce section of the ACP. In fact, there are a few different price points for the same thing, but that's not particularly relevant. The effect of these is that users are moved into the Subscriber or the Donor user group for the year, and then removed afterwards. A couple of people have reported that they used to be supporters, but they let their membership expire. After this they decided to join as a Donor instead but when they clicked on the subscription button they were immediately given full access without having to pay - see the report that one user posted below: The logs on his account match this but it looks like something very odd is happening: So his membership expired on 5 February. On 8 February he tried to buy the Donor subscription package but for some reason, it changed his status to having a Supporters subscription and then a Donors subscription, all without requiring him to pay (and his renewal invoice for the Supporters subscription is still pending: After he reported this someone else, whose Supporters subscription expired back in October last year, tried and found the same thing. This looks like a bug in the way that subscriptions are implemented. Or am I overlooking something?

Apologies for the delay, client area updated with SFTP access credentials.

I'm not sure how quickly I can arrange access, I need to undo/subvert some of the access controls we have in place. At the very least, it would be great to stop the stuck post delete tasks set going by the account deletion process, just to allow notifications to be parsed. I'm less worried about fulfilling the user's request to delete the account than I am having the board operate correctly meanwhile. Do you have a sense of what would be done on your end with admin panel/FTP access? For instance, I could provide here the rows in core_queue pertaining to the stuck deletion tasks if it would provide insight.

If this is needed for debugging this particular issue, I can work on getting access. We don't have a general FTP service up, and our SSH is key-only auth.

Sorry about that, staff accounts require 2FA. I have temporarily disabled for the provided account.

Thanks Jim, have updated the access information with the account details generated by the admin panel.

It's definitely still ongoing, core_queue now has 1,265 rows. Would appreciate someone taking a look. To whom should I supply the admin login credentials?

Rather than fiddle with data for this user, is it safe to simply remove the relevant rows from core_queue? Basically, stop the account delete process for that user and allow the (now considerable) backlog of notification and other tasks to process? If need be, I'll delete this user's posts via the API, but we do need the queue task to be able to function.

Nope, all good there. There are 78 rows and all reference the core app. The top two referencing the delete posts/messages of that user.

The Pages app issue linked above is now resolved, unfortunately the Background Processes are still stuck. Specifically, queue locks every time I unlock it and try to run it manually. Error as above.

That did it, removing the cms folder moved it from being listed as locked under Applications down to a new section where it was shown as needing to be upgraded. The X alongside that entry allowed me to remove it, and now there is no trace of the Pages app. Thanks!

I was about to give Adriano's suggestion a whirl when I saw your post and realized there is, in fact, a cms folder within /applications. I assume that's the actual folder name of the Pages application? If so, I'll delete that after backing it up.

There is already no pages folder within /applications. Appreciate the suggestion, though.

Creating a separate thread in case it's unrelated to this: Someone requested that their account be deleted, and so an admin set that going. As this was being processed in the background, it seems to have got stuck (~23% of 9k posts). This has caused the queue task to be locked every time it tries to run, once a minute. A LOT of other tasks are getting backed up because of this (mostly notifications, so far) and it's getting worse over time. Here is the System Log error when I try to set the background tasks running manually: Error: Call to a member function container() on null (0) #0 /usr/share/nginx/html/applications/forums/sources/Topic/Post.php(374): IPS\Content\_Comment->delete() #1 /usr/share/nginx/html/applications/core/extensions/core/Queue/MemberContent.php(126): IPS\forums\Topic\_Post->delete() #2 /usr/share/nginx/html/system/Task/Task.php(47): IPS\core\extensions\core\Queue\_MemberContent->run() #3 /usr/share/nginx/html/applications/core/modules/admin/system/background.php(87): IPS\_Task::runQueue() #4 /usr/share/nginx/html/system/Helpers/MultipleRedirect/MultipleRedirect.php(93): IPS\core\modules\admin\system\_background->IPS\core\modules\admin\system\{closure}() #5 /usr/share/nginx/html/applications/core/modules/admin/system/background.php(138): IPS\Helpers\_MultipleRedirect->__construct() #6 /usr/share/nginx/html/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\system\_background->process() #7 /usr/share/nginx/html/applications/core/modules/admin/system/background.php(42): IPS\Dispatcher\_Controller->execute() #8 /usr/share/nginx/html/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\system\_background->execute() #9 /usr/share/nginx/html/admin/index.php(13): IPS\_Dispatcher->run() #10 {main} I disabled marketplace addons (we have two) to no avail. When the admin kicked off the delete process, we were a couple of months behind on updates. I've since updated to latest (in an attempt to solve the issue in the linked thread above) but that didn't help. edit - it seems the delete posts job was kicked off 3 separate times, looking at the stalled background processes at the bottom of the dashboard. Evidently, the admin tried to run it twice as he wasn't sure it was actually running. Unsure if this is the cause of the issue. Ideally, I'd like to: - remove the delete posts job so the queue task and process all these pending jobs - determine why we can't purge this user's posts