BertT

Hello. The navigation on the forum does not work; when you try to go from page 5 to the first, it is impossible to make the transition!
 

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

It seems you were excessively helpful. You deserved it twice. 😂

Is it that hard with an available update to put conditions:
- Please disable 3rd party addons
- Please disable ads
etc., all of which you marked as an issues for update , and done
After a version update, enable all of the above at your own risk.

Member request PII data: Then I see this in the admin notification on ACP

Then when I click on checkmark. 

as you see it says approve...
then you get this 

Asking you if you want to delete the account suppose to be PII data request NOT deletion
Is this a bug or intended to be this way?

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.

Yes, please! I second that (hence my feedback here and here). Ideally the permissions should be group-based (at the same place where anonymous logins can be allowed/disallowed).

This is something I just cannot understand. All the bugs aside these two features introduce a whole new workflow of having to deal with requests, approvals and rejections. Who thought it's a good idea to release this without an option to opt-out? Not every community needs this and not everybody is ready. Communities that aren't ready to handle this are basically forced to stay on an older version and miss out on all other improvements. Both of those features should be configurable.
I looked into disabling it via code hooks and things get even worse. While hooking \IPS\Member::canUseAccountDeletion does the trick for account deletion (proper backend checks + removes it from UI), same route just doesn't work for PII.
\IPS\Member\PrivacyAction::canRequestPiiData/canDownloadPiiData can be hooked but UI elements will stay because of settingsPrivacy template. Buttons will be gone but whole div, header and description will stay.
For account deletion whole div is wrapped properly:
{{if \IPS\Member::loggedIn()->canUseAccountDeletion() }} ... {{endif}} Why same thing wasn't done for PII? This would do the trick:
{{if \IPS\Member\PrivacyAction::canRequestPiiData() }} ... {{endif}} Now it's impossible to remove this without excessive trickery. Theme hooks won't really do the job as there is no way to select that specific div as it doesn't have a unique identifier (it's a generic div.ipsPadding). Documentation states that "you can use any of the selectors supported by jQuery" and that's simply wrong, actually not even a tiny fraction of selectors used by jQuery are supported. Only the most basic CSS selectors can be used and those don't allow to select e.g. parent elements.
I didn't expect that a monthly update will turn into such a headache that a simple ACP option could easily fix.
tl;dr Please make those features optional.

Free plugin awaiting approval.

Unnecessary quotation marks in the cookie link 😐

Agree, please add options to enable or disable these features...
Ted.

Agree. 
In lieu of this functionality previously we developed a completely different workflow that is working well, the users have accepted it - we have no intention changing that. 
Please make the new delete requests function optional or configurable for specific groups only. 
Thank you.

Please add group-based options to enable/disable pii data requests and account deletion requests so that these frontend options do not neccessarily show up for every user.

Re-uploading the core files will only prompt you to update the applications you haven't already updated (in this case commerce)
It won't have any impact on the forums application, which has already been updated.
You could download the entire suite from the ACP and then upload upload the commerce/nexus application in the applications folder of that download, but I might suggest doing a full upload anyways just to make sure everything did get uploaded correctly when you did the initial upgrade.
IPS shouldn't let you upgrade if any of the files for a specific application weren't uploaded properly (so this means the forums, core software and other applications you updated should be fine), but it can't hurt to be extra sure.

No, I can’t. 😃
In your screenshot, bottom right, you have the code error.

We are aware there are quite a lot of errors that show in the logs at present, and the next version will tone these down. The only ones you need to be aware of at present are ones that show up after upgrade (saying that items will be disabled)

Admin (™ Admin)
2 minutes ago
The URL of page the error occurred on was https://www.mysite.com/forum/admin/?app=core&module=support&controller=support&do=getBlock&block=hookscanner&csrfKey=d41b38598e5cc18ca6421a7949768353
The class \SVG\SVGBezierApproximatorTest extends \PHPUnit\Framework\TestCase, but the parent class couldn't be loaded. backtrace
#0 /home/media/public_html/forum/system/Application/Scanner.php(1438): IPS\_Log::log('The class \\SVG\\...', 'app_scanner') #1 /home/media/public_html/forum/system/Application/Scanner.php(456): IPS\Application\_Scanner::log('The class \\SVG\\...') #2 /home/media/public_html/forum/system/Application/Scanner.php(786): IPS\Application\_Scanner::scanExtendedClasses(false, true, 500, 5000, Array) #3 /home/media/public_html/forum/applications/core/modules/admin/support/support.php(519): IPS\Application\_Scanner::scanCustomizationIssues(false, true, 500, Array) #4 /home/media/public_html/forum/applications/core/modules/admin/support/support.php(228): IPS\core\modules\admin\support\_support->_showBlockHookscanner() #5 /home/media/public_html/forum/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\support\_support->getBlock() #6 /home/media/public_html/forum/applications/core/modules/admin/support/support.php(48): IPS\Dispatcher\_Controller->execute() #7 /home/media/public_html/forum/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\support\_support->execute() #8 /home/media/public_html/forum/admin/index.php(13): IPS\_Dispatcher->run() #9 {main}

When you delete a previous version on IP.Downloads file it throws a template error on the download button. You can also reproduce this by changing the changelog ID to one that doesn't exist and it'll produce the same error. Was able to reproduce it on the IPS website as well.

I've re-opened this topic. Please read the message above the topic, thanks.

I don't know what else we can do. We've given our marketplace authors about a year to prepare. We started releasing betas in May, and we posted the above in August; yet a lot of our marketplace authors seem unaware.

However, we do not want to cause our clients a headache, so we're working on a way forward that doesn't leave you without apps and plugins you need.

Please hold while we work on a plan.
We are hearing you all loud and clear and are working on a solution. I'll update you when we release a patch.

What I see here, that clients are outraged by the company's lack of transparency in relation to aggressive blocking of their apps/plugins, they should have had a warning before proceeding with the update, that's what everyone is commenting on.
Many users are dependent on third-party apps to make their community what it is today, and that has become a big issue now.
Honestly, after all these reports, I'm zero excited to update my community now, I'll wait for all this puera to subside.
Good luck to the team in having to deal with this whole complaint, something that could have been avoided.

I confirmed the patch works. All good...

As mentioned above, this is a bug with PHP itself. They have patched what they believe to have been an issue, and broken things in the language. We are working to work around this issue.