teraßyte

When editing a forum in ACP: v4 => Display Settings TAB (but it appears only if Show Rules? is set to Show rules) v5 => It's been moved to a new Rules TAB

It seems they're having issues with missing JS language strings after the last update. Even marking posts as read, quoting selected text, and other functions, etc. are missing text. There's also a bug report about it.

The API does have the code to send out the notification: $post = $commentClass::create( $item, $postContents, TRUE, NULL, NULL, \IPS\Member::load( (int) \IPS\Request::i()->from ), \IPS\DateTime::create() ); $item->first_msg_id = $post->id; $item->save(); /* Authorize sender and recipients */ $item->authorize( array_map( function( $member ) { return (int) $member; }, array_merge( array( \IPS\Request::i()->from ), \IPS\Request::i()->to ) ) ); /* Send notifications */ $post->sendNotifications(); return new \IPS\Api\Response( 201, $item->id ); If the notification is not going out, the default option for PMs must be set to disabled in your ACP. New users use the default values setup in ACP:

It seems all javascript-related language strings are missing on the site (mark all as read, search, quote selected text, etc).

Either your hosting has a really low value for MAX_JOIN_SIZE or your reputation table is extremely big. It seems shared hostings (?) use this a lot to limit long queries, but it's the first time I have ever seen this error. Leaving SQL_BIG_SELECTS aside, if your hosting is unwilling to raise the MAX_JOIN_SIZE value, your only real option is to change hosting. 🤷‍♂️

Have you already tried clearing the caches from ACP > Support?

Ops, I see the problem. I was looking at the 5.0.0 files which don't have that folder yet. 🤦‍♂️ The code is indeed there, but the permissions are missing as visible in the opentype's screenshot above. I had the same situation right after the upgrade when I edited a field permissions.

The new 14.1 beta removes the check for valid themes (commit reverted?) but leaves the set_build_version column in the database. Should I report it as a bug? Or will the check be restored (and fixed) in the next beta? 🙄 The column remains in the database for those who upgrade from a version previous to beta 14 (upgrade step) but is not present in new installations.

@Marc I just upgraded a test site to 4.7.20 and this is what's happening: Existing custom fields are visible/usable to all, but the new 4.7.20 version adds a permission check. The upgrade code does NOT add permission rows for the existing fields to enable the add/edit permission for all groups. You have to edit the field in ACP to update the permissions. With the permissions updated the fields show again in the add/edit form. There is no upgrade code to insert the permissions for the existing fields anywhere. The upgrade should add permissions rows for everyone to add/edit the fields to keep it compatible with the pre-upgrade setup. Post upgrade only the view permission is enabled for all groups. 👀

No, it doesn't. Looks like I need to remember to refresh each tab before I reply now. For example, I wouldn't have replied to the topic I linked above since the user clarified in newer replies that it was actually HTML/JS rather than PHP. I don't remember this feature removal being discussed anywhere. It's a rather 'annoying' change. 😒

Oh, okay. I thought the fix was that we had to select a custom wrapper, and you'd pre-select one for pages without one when upgrading from v4. I misunderstood then. Waiting for happy news. 🤞

Could you clarify? Integrated how/where? If I know what you're trying to do, I can offer suggestions, but I'm confused about what you're trying to accomplish exactly. If it's not a problem, maybe you can post the PHP code of one of your blocks.

This is a guide on how to create a simple application for v4: https://invisioncommunity.com/developers/docs/development/applications/creating-a-simple-hello-world-application-r184/ Applications for v5 are slightly different compared to v4 (no more underscores for class names and hooks were removed), but what you can read there is 95% of what you need to know.

Unfortunately, that's correct. Using an empty custom wrapper is not an option because the code checks specifically that the template contains at least the $html and $title variables. Without them, the wrapper is not even listed as a choice. 🤷‍♂️ I've been using pages without a wrapper for other custom things (like update checks for my apps), but the ads.txt page is something that IPS actively suggests to clients on the Cloud. I wonder what's their solution for that. Let me tag @Matt and @Esther E. to see what solution they have for it. 👀 Official guide for ads.txt:

That's... kind of a problem. As mentioned above, only PHP 8.0 and 8.1 are supported by version 4.7. Rather, I'm surprised you didn't notice issues before using 4.7.19 with PHP 8.3. 👀

@kalin PHP 8.3.16 is definitely a problem. Try downgrading to PHP 8.1 and see if the upgrade works. PHP 8.2+ is only supported by the new 5.0.0 version currently in beta.

I thought of making a modification for custom PHP blocks to keep my current pages working, but IPS also removed support for pages without wrappers (the page editor wouldn't work). Given that, I'll have to make my own custom application anyway to output the content I need. If there are enough requests I can consider making it, though. 🤔

Unfortunately, IPS provides only the latest version for download. You must have a copy of the 4.7.19 ZIP file somewhere (or retrieve a copy of the files from a backup). Still, it's strange that the upgrade page redirects you to the admin login page instead. I've never seen it happen before. 🤔 Just to clarify, what PHP version are you using? I don't see it mentioned in the topic, but I know using PHP 8.2.0+ can cause strange issues.

Really wish you could fix the notifications bug before the final release. It's a pretty annoying one. 🙄

Go manually to domain.com/admin/upgrade. You should get a login screen there.

I've already reported it as a bug a few times, but the checker script was never updated. It only checks for PHP 8.0+, it never throws an error for PHP 8.2+, which is what causes issues. 🤷‍♂️

I completely missed the PHP version in the title when I replied before: Version 4.7 does NOT support PHP 8.2.0+. You can only use PHP 8.0 or 8.1. Try also downgrading the PHP version.

That looks like some files didn't upload properly. 🤔 To avoid issues like this I usually upload a ZIP/TAR file with all files at once and then decompress it from cPanel's file manager directly on the server. Uploading files 1-by-1 sometimes has problems with certain files not being uploaded correctly. Using the single compressed file + decompress helps avoid that.

The mt_is_deleted column also seems unused. 🤔