teraßyte

For Application.php you can use: /** * Cleanup after saving * * @param bool $skipMember Skip clearing member cache clearing * @return void * @note This is abstracted so it can be called externally, i.e. by the support tool */ public static function postToggleEnable( $skipMember=FALSE ) { # Parent call parent:postToggleEnable( $skipMember ); # Your code here # [...] } Or you can also extend set_enabled(): /** * [Node] Set whether or not this node is enabled * * @param bool|int $enabled Whether to set it enabled or disabled * @return void */ protected function set__enabled( $enabled ) { # Parent call parent:set__enabled( $enabled ); # Your code here # [...] } They actually use set_enabled() to switch the application's tasks (which is what you want to do with the login handler): /* Update other app specific task statuses */ \IPS\Db::i()->update( 'core_tasks', array( 'enabled' => (int) $this->enabled ), array( 'app=?', $this->directory ) );

It's in the Integrations area in ACP. Look at the last part of this guide:

Don't use the upgrade script in ACP. Try going manually to /admin/upgrade instead.

Yes. That setting is not restricted to a specific forum, blog, gallery album, etc. It applies to everything the user posts.

There is no default option like that in Invision Community. You need a modification for it: https://www.invisioneer.org/files/file/36-dp42-topics-per-time/

While reviewing some code in the forums application I found a couple of places that check the wrong class name for topics if the group is allowed to hide its own topics. These are the 2 files where IPS\forums\Topics needs to be replaced with IPS\forums\Topic: Line 649 in \applications\forums\modules\front\forums\forums.php $canHide = ( \IPS\Member::loggedIn()->group['g_hide_own_posts'] == '1' or \in_array( 'IPS\forums\Topics', explode( ',', \IPS\Member::loggedIn()->group['g_hide_own_posts'] ) ) ); Line 530 in \applications\forums\sources\Topic\Topic.php $canHide = ( $item ) ? $item->canHide() : ( \IPS\Member::loggedIn()->group['g_hide_own_posts'] == '1' or \in_array( 'IPS\forums\Topics', explode( ',', \IPS\Member::loggedIn()->group['g_hide_own_posts'] ) ) ); I searched all the files just in case, but those are the only ones I found.

There is no option for that currently. You need to edit the template core > front > global > logo and replace (twice) the link: {setting="base_url"} with the one you want to use.

There is a tool in ACP to rebuild the achievements right away (see the button in the Other Settings screenshot): Before rebuilding, you can change the rules so that they add only 1 point for each content they make. By default, users get 10 points for a new item they post and 5 points for each comment/reply.

It's the joined column in the core_members table. The value must be a UNIX timestamp: https://www.unixtimestamp.com/ Example timestamp for the current time: 1700338973

Yeah. With 10k accounts, options #1 and #2 aren't really feasible. 😅 The only real option would be #3. A quick script to import a CSV file that contains only the account email and their joined date. It could quickly go through the data to update the date column in the members' table using the email. It should be easy enough for your developer in case you want to go ahead with it.

It's the name of IPS's hosting service: Community in the Cloud.

Not really. The setting may speed up things slightly based on the server configuration, but I found it causes problems more often than not. Personally, I suggest leaving it disabling.

Yes, it skips the account. The code doesn't account for updating existing ones. Your only options are: Delete the imported members and re-import them with the proper field selected for the join date. If the accounts are only a few, manually update the unix timestamps directly in the database. (Always make a backup before any manual edits.) If you have a lot of accounts, create a script to automatically update the joined unix timestamp. Give up on updating the joined date. 😋

Try disabling completely the template disk caching setting for now. Does that fix the issue?

From which version are you upgrading? Also, which PHP version is the server using? I've never seen this error before. I've seen the session one plenty of times, but never together with the other about the return type not being compatible.

This topic has been showing up as unread for the past ~10 days in the Unread Content stream. Can you do something about it @Matt? The new blog entry you just posted disappeared properly. 😅

IPS always provides only the latest version for download. Unless you have the older version already downloaded on your computer (which doesn't seem to be the case since you just took over the forum), the only version available right now is 4.7.14 which requires PHP 8. Is your problem that the server doesn't have PHP 8 available yet? Or just that you're unsure of how to upgrade the forum to the latest version and change the PHP version at the same time? If it's the former, I would change hosting since PHP 8 has been available for a long while now. If it's the latter, there are ways to upgrade.

Instead of the number of followers, it might just be the SMTP server being slow in its starting reply. Switch temporarily to PHP mail and try again to post something. Does the delay disappear?

I think that notifications might be delaying the submission process. What Email method are you using to send out notifications? PHP mail, SMTP, Sendgrid?

Does the topic you're replying to have a lot of followers? Or does it happen also for topics with few or zero followers?

@DawPi It's the extension file in the core app: \applications\core\extensions\core\Sitemap\Content.php

Only 1 task was changed in the 4.7.14 upgrade: https://invisioncommunity.com/release-notes/4714-r126/ The task was changed to run every hour instead of every 15 minutes like before, and the code to generate sitemaps was changed, too.

The missing <li> elements issue is something I reported a few days ago:

PHP 8.2 is not supported, and the upgrade script from 3.1 was never really tested using PHP 8. Even the 3.4 version was barely tested with it. Downgrade PHP to version 8.0 and try again. You'll still get a few errors most likely, but far less than using an unsupported PHP 8.2 version at least.

You can find the SVG files inside this XML file in your ZIP: \applications\core\data\achievements\ranks.xml In the same folder, you can also find the Badges in badges.xml. Both files have the images encoded with base_64.