teraßyte

Anyone affected must re-install and re-uninstall the app to fix it for now then. 🤷‍♂️ This kind of fix should really be retroactive to fix sites where the issue already happened, though.

And in case your hosting has no idea how to proceed, and you don't want to move to Cloud, you can hire a 3rd party Provider to do the upgrade for you. 😋

That error is usually thrown if a utf8mb4 character is in the text and your database is not utf8mb4. For example, posting an emoji while the database is utf8/utf8mb3. Is your database using utf8mb4? Maybe something in the YouTube embed has a utf8mb4 Unicode character that triggers the check. 🤔

The column max_threads_error is not a default one. It was added by a modification you installed at some point. You'll need to contact the modification's developer for support.

No, there is no option in the ACP. But you could export the data from phpMyAdmin and choose the CSV/Excel format as output format.

As I said, it was already there on version 4.3.5. It was not added by the upgrade to 4.7.17. Why it was there, to begin with, I'm not sure. 🤷‍♂️

To add some more details, the RebuildPosts task is throwing errors when parsing posts with this mention HTML content: <p> <a contenteditable="false" data-ipshover="" data-ipshover-target="<___base_url___>/index.php?/profile/XXXX-NAME/&amp;do=hovercard" data-mentionid="XXXX" href="<___base_url___>/index.php?/profile/XXXX-NAME/" rel="">@NAME</a> testing a mention post. </p> Removing the A element for the mention hovercard makes the rebuild task proceed with no errors: <p> @NAME testing a mention post. </p> The Rebuild Posts task was already present and throwing errors while on version 4.3.5. I was hoping it was a bug fixed at some point, but even after upgrading to 4.7.17, the error is still there. That's when I investigated the issue and suggested the client post a bug report here.

A will still see a message similar to "You are ignoring posts from this user. Click here to read it" while B will not know he's on the ignore list at all. That said, even if the member is on the ignore list, A should still be able to see B's profile, search for them in the search page, etc. The only option would be to login as them from ACP and go to their ignored users page.

Oh, whoops, I meant to fill in the title with more details yesterday, but it ended up as only "[BUG 4.7.17]". I've updated it. 😋

Yeah, I figured it wouldn't change for v4 at this point. I'm good as long as it's easier to implement it in v5. 👍

Sending unapproved notifications for moderators without the required causes an undefined array key error: Whoops\Exception\ErrorException thrown with message "Undefined array key "can_view_hidden_MODPERMKEY_MYITEMTITLE"" Stacktrace: #9 Whoops\Exception\ErrorException in \system\Content\Content.php:2635 #8 Whoops\Run:handleError in \system\Content\Content.php:2635 #7 IPS\_Content:sendUnapprovedNotification in \system\Content\Item.php:526 #6 IPS\Content\_Item:createFromForm in \system\Content\Item.php:150 #5 IPS\Content\_Item:create in \applications\MYAPP\sources\MYITEM\MYITEM.php:728 #4 IPS\MYAPP\_MYITEM:create in \applications\MYAPP\modules\front\MYMODULE\index.php:93 #3 IPS\MYAPP\modules\front\MYMODULE\_index:new in \system\Dispatcher\Controller.php:107 #2 IPS\Dispatcher\_Controller:execute in \applications\MYAPP\modules\front\MYMODULE\index.php:39 #1 IPS\MYAPP\modules\front\MYMODULE\_index:execute in \system\Dispatcher\Dispatcher.php:153 #0 IPS\_Dispatcher:run in \init.php:940 The issue is in the \IPS\Content:sendUnapprovedNotification() function when it checks the individual item permissions (lines 2616-2641): try { $container = ( $this instanceof \IPS\Content\Comment ) ? $this->item()->container() : $this->container(); $containerClass = \get_class( $container ); $title = static::$title; if ( isset( $containerClass::$modPerm ) and ( $perms[ $containerClass::$modPerm ] === -1 or ( \is_array( $perms[ $containerClass::$modPerm ] ) and \in_array( $container->_id, $perms[ $containerClass::$modPerm ] ) ) ) and $perms["{$modPermKey}{$title}"] ) { $$varKey = TRUE; } } catch ( \BadMethodCallException $e ) { } The IF check uses $perms["{$modPermKey}{$title}"] directly without first doing an isset() check (like it does for $containerClass::$modPerm ). This happened after I added the content item class to my development board and old moderators set up before it are checked and don't have the field/value set.

There's also the option of hiring a 3rd party Provider if you don't want to do it alone: https://invisioncommunity.com/third-party/providers-directory/ With the marketplace closure, I've often helped with this kind of situation. This is a common problem for a lot of site owners. I recently helped upgrade a site with dozens of modifications. I searched for the updated version of everything on the developers' sites. Some were unavailable and I updated them to be compatible with 4.7 myself.

Ok, utf8mb3 is the new alias for utf8 in recent MySQL versions. You have to convert your database to utf8mb4 with the tool in the ACP before upgrading to the latest version. There should be a link to the tool on the ACP > Support page. Click the link and start the conversion from there. Alternatively, there is also a tool you can run from SSH if your database is big (GBs of data).

That's the server collation, not the tables collation. Open the database used by the forum and check the Collation column for all tables on that page.

There shouldn't be any table with that name. 🤔 Is your database using utf8mb4 or a different charset? The utf8mb4 database check is about the only function I can remember that creates that kind of _new suffix.

So, it seems that \IPS\Content\Item::processCommentForm() does not save any values/changes you make to it unless you call save() yourself. That's another difference compared to how the Content Item itself is handled. 🤷‍♂️

I'm adding some custom fields to a comment form in an application, however, adding them is a nightmare, unlike the normal form for the item itself. I had to alter the commentTemplate form template to place the fields in the correct position above the editor. Without the template edit, the fields were added at the bottom inline with the submit button, and the whole look was messed up. There is no easy way to only overload the comment template. I had to copy both commentContainer and comment to use my custom comment template. The \IPS\Content\Controller::_edit() class that loads the edit code/form doesn't use \IPS\Content\Item::commentFormElements() to load the fields, so I had to overload the whole function and add my own field code in there since there is no usable hook point/extension that can be used. The same also applies to \IPS\Content\Item::processCommentForm() since it's not called when editing a comment. Overall the whole process of adding fields to a comment form is a mess. And I assume the same applies to the review form. I expected it to work as it does for items with formElements() and processForm().

I have an application with 2 separate Content Item classes setup. The first one is okay with the normal permissions, but for the second one, I had to add a ContentModeratorPermissions extension to implement some custom permissions. What happens is that the custom permissions are also being shown for the first Content Item class which doesn't need them. The extension needs a way to check the content item class being passed to check if it should return or not the custom permissions.

It's possible to upgrade even if you can't login into the ACP, however, you need to: Manually upload all the files for the latest version. Switch the PHP version to 8.1. Go to /admin/upgrade and login with a known working ACP account. Once the upgrade is complete, you should be able to login again. If not, IPS support (or whoever you hire to do the upgrade for you) will be able to help at that point. Randy's suggestion is probably the best solution given the whole back and forth on this topic. 🤷‍♂️

Based on the error you posted, some files are missing from your server. Or they are there, but with the wrong permissions, and the server can't read/access them. Re-upload all the files from the ZIP file in your client area again and double-check the permissions. From the error, you are at least missing this file => \applications\core\extensions\core\AdminNotifications\PiiDataRequest.php And if it's there, with the correct contents, then the permissions are wrong.

Yeah, based on what you said, the upgrade can be tricky. Especially if you don't upgrade often. 🙃 If you send me a PM with more details (number of posts, DB size, modifications installed, etc.) I can take a look tomorrow if it's not urgent. 👍 I'm replying from my phone right now so I can't exactly do much from it.

Right. I was thinking about that one but wrote about the global one instead. Ignore me. 😅 In any case, if they don't want to allow members to lock/unlock their content, the only solution remains a custom modification. 😋

The only way would be with a custom modification. There is no way to do what you're asking otherwise. You could give members the moderator permission to lock/unlock content, but then they'd be able to lock/unlock anything not just their content.

Based on the error in your screenshot, it seems your conf_global.php file contains an HTTP URL instead of HTTPS, but your server redirects to HTTPS automatically and breaks the login form. Try following this guide before using recovery mode:

Have you already tried clearing the system cache in ACP > Support? If clearing the cache didn't work, have you translated language strings in ACP? Those FontAwesome icons are actually loaded from language strings. If you edited them, the translation broke the correct name.