teraßyte

2 hours ago, bearback said:

to be honest i am getting fedup with jumping through hoops with Facebook and may well disable it.

That's what I did more than a year ago already. 😋

You have the old license most likely, but it's possible to upgrade to a Classic License from your client area.

Check this topic for more info: 

3 hours ago, David N. said:

It would also send the signal to the person who posted the topic that I have taken note of their question and intend to answer it later.

I don't think normal members will be able to see that someone is assigned to the topic. I might be wrong, though. 🙄

Here's a link to the guide:

If you disable the guest group from accessing the site, nobody, not even search engines, will see the content.

If you also want to control who registers and can see the content, enable the admin validation for new accounts. Or you can disable new registrations, and manually add the accounts for the club if they're only a few. Or only allow certain email domains to register if your club has a specific domain for all members.

I had the same issue recently. I received errors that Gmail rejected my emails because they did not pass DKIM/SPF.

Switching from the PHP mail method to SMTP increased my score on https://www.mail-tester.com/ and the emails started being delivered again.

The data is in the core_follow table. They need to filter by:

1. follow_app=core
2. follow_area=member
3. follow_rel_id=XXX (where XXX is the member ID)

32 minutes ago, Kimmo said:

Now the main question seems to be, that if, for some reason, we are not able to go to the old admin panel via browser, is it still possible to update our old forum?

It should be possible, but without checking directly, it's hard to say:

1. For example, your host might have automatically upgraded to a newer PHP version (8.0+), and your current Invision Community version is not compatible with it if it's old enough. In this case, downgrading the PHP version on the server, or upgrading to the latest version will get the site working again.
2. Instead, if the database is broken (missing tables/data or corrupt tables), you'd need a working backup to get it working again. In this case, an upgrade won't solve anything.

Are you getting a specific error when trying to login into the ACP? It could be anything without more info. 🤷‍♂️

@Clover13 To reproduce the bug, the database must have the Store revisions option enabled. Most likely the test was made on a database with it disabled.

I initially thought too the error was coming from saving the record to the database, only after re-checking your last screenshot I noticed it was a revision instead. 😅

You upload the new files to the server in the same location as the old ones and then run the upgrade script from /admin/upgrade/ in your browser.

In case the site is big, the upgrade script might ask you to run some manual MySQL queries from SSH.

For more info look at the Manual Upgrade section of this guide:

However, check first if your server has all the requirements to run the latest version:

Quick note: the check script will give you the green light also for PHP 8.2+, but only PHP 8.0 and 8.1 are supported. 😋

If you're unsure of how to proceed yourself or just want someone to help, it's possible to hire a 3rd party provider to do the upgrade for you: https://invisioncommunity.com/third-party/providers-directory/

I'm also on that list if you want to send me a PM.

EDIT: @Marc Stridgen beat me to it. 😛

Looking again at the screenshot, the error is being thrown when a revision for the record is added to the database, not when the record itself is added. If you're adding a new record, it shouldn't store a revision. A revision should be saved only when you edit a record.

The problem is in /applications/cms/api/records.php in the _createOrUpdate() function (lines 424-443):

			/* Store a revision before we change any values */
			if ( $item::database()->revisions )
			{
				$revision = new \IPS\cms\Records\Revisions;
				$revision->database_id = $item::$customDatabaseId;
				$revision->record_id   = $item->_id;
				$revision->data        = $item->fieldValues( TRUE );
				
				if ( $this->member )
				{
					$memberId = $this->member->member_id;
				}
				else
				{
					$memberId = $item->author()->member_id;
				}
				
				$revision->member_id = $memberId;
				$revision->save();
			}

The IF check should also check if you're editing a record because when adding a new one there is no record ID available yet (thus the column NULL error):

if ( $type == 'edit' AND $item::database()->revisions )

As per the title, the implementation of the extension's EditorLocations::attachmentLookup() method is inconsistent when you don't allow attachments. No matter how I implement it, or which exception I throw, it won't work for all locations.

1) \applications\core\extensions\core\EditorMedia\Attachment.php (lines 140-156):

• The code checks if the method exists before calling it.
• The code checks for 2 exceptions being thrown:
  • \LogicException
  • \BadMethodCallException

					if( method_exists( static::$loadedExtensions[$map['location_key']], 'attachmentLookup'))
					{
						try {
							$url = static::$loadedExtensions[$map['location_key']]->attachmentLookup($map['id1'], $map['id2'], $map['id3']);

							/* Test url() method to prevent BadMethodCallException from the template below - an attachment may be
								located within a Node class that doesn't support urls, such as CMS Blocks. */

							if ($url instanceof \IPS\Content or $url instanceof \IPS\Node\Model){
								$url->url();
							}

							static::$locations[$attachId][] = $url;
						} catch (\LogicException $e) {
						} catch (\BadMethodCallException $e) {
						}
					}

2) \applications\core\modules\admin\overview\files.php (lines 209-219):

• The code checks if the method exists before calling it.
• The code checks for a single exception being thrown:
  • \LogicException

			if ( isset( $loadedExtensions[ $map['location_key'] ] ) AND method_exists( $loadedExtensions[ $map['location_key'] ], 'attachmentLookup' ) )
			{
				try
				{
					if ( $url = $loadedExtensions[ $map['location_key'] ]->attachmentLookup( $map['id1'], $map['id2'], $map['id3'] ) )
					{
						$locations[] = $url;
					}
				}
				catch ( \LogicException $e ) { }
			}

3) \applications\core\modules\front\system\attachments.php (lines 87-100):

• The code doesn't check if the method exists before calling it.
• The code checks for a single exception being thrown:
  • \OutOfRangeException

		/* Check Permission */
		$exploded = explode( '_', $attachment['location_key'] );
		try
		{
			$extensions = \IPS\Application::load( $exploded[0] )->extensions( 'core', 'EditorLocations' );
			if ( isset( $extensions[ $exploded[1] ] ) )
			{
				$attachmentItem = $extensions[ $exploded[1] ]->attachmentLookup( $attachment[ 'id1' ], $attachment[ 'id2' ], $attachment[ 'id3' ] );
			}
		}
		catch ( \OutOfRangeException $e )
		{
			\IPS\Output::i()->json( array( 'error' => 'no_permission' ) );
		}

4) \system\Content\Statistics.php (lines 398-408):

• The code doesn't check if the method exists before calling it.
• The code checks for a single exception being thrown:
  • \LogicException
  • \BadMethodCallException

				if ( isset( static::$loadedExtensions[ $map['location_key'] ] ) )
				{
					try
					{
						$url = static::$loadedExtensions[ $map['location_key'] ]->attachmentLookup( $map['id1'], $map['id2'], $map['id3'] );

						$return[ $k ]['commentUrl'] = (string) $url->url();
					}
					catch ( \LogicException $e ) { }
					catch ( \BadMethodCallException $e ){ }
				}

===

To make a summary of the implementations:

1. All OK.
2. It should check for the \BadMethodCallException exception.
3. It should check if the method exists before calling it, and both \LogicException and \BadMethodCallException exceptions aren't being checked. Rather, it checks for a \OutOfRangeException exception which is never thrown according to the method's phpDoc.
4. It should check if the method exists before calling it.

I could throw a \LogicException, but as it is it would break implementation #3 anyway.

500 error code aside, the API should also return a separate code/message about the issue. Have you tried checking that?

2T306/4	INVALID_DATABASE
1T306/5	NO_CATEGORY
1T306/6	NO_AUTHOR
2T306/G	NO_PERMISSION
1T306/D	TITLE_CONTENT_REQUIRED
1S306/E	UPLOAD_FIELD_NOT_OBJECT
1T306/F	UPLOAD_FIELD_NO_FILES
1T306/G	UPLOAD_FIELD_MULTIPLE_NOT_ALLOWED
1T306/H	UPLOAD_FIELD_IMAGE_NOT_SUPPORTED
1T306/I	UPLOAD_FIELD_IMAGES_ONLY
1T306/J	UPLOAD_FIELD_EXTENSION_NOT_ALLOWED

The API currently allows only 3 options:

• Create a new personal conversation
• Add a reply to an existing personal conversation
• Delete an existing personal conversation

There is no way to list/retrieve a member's personal conversations right now. 🤷‍♂️

Disabling the right click is not an effective way at all. There are countless ways to bypass that limitation (disable javascript, scrape the site, look at the image URL in the page's source, etc.). Personally, I think it's a waste of time even trying. 🙄

I'm unaware of any 3rd party plugin that does this, but there are several such examples if you just search for them (Google, Bing, etc). If you still want to go ahead with it, find some JavaScript code and add it to your theme.

You need to establish a connection to the external/remote database you want to use, and then run the queries with the usual framework code to retrieve/display the data:

The first codebox shows an example of how to start an external database connection.

No, you're not missing it. There is no option in Invision Community for that.

I've seen modifications to hide images for specific groups, but not based on the member's age if they're logged in.

I'm not sure how it happened, but the same user was able to react twice to one of my posts here on this forum:

You can see there are 2 Thanks reactions from the same user.

I also received 2 separate inline notifications for it.

Yes, you need to add your own API key now. The default API key stopped working almost 1 year ago:

1 hour ago, Mick23 said:

IMO this kind of bug really should never have gotten through basic smoke testing of the release.

Releases used to be trustworthy but I think I'll hold off on them for a month or so after they are available to try to avoid this kind of thing.

I usually wait 1-2 weeks after a new release to avoid exactly this kind of issues. The time is usually enough for IPS to release a patch for any major issues.

You can use Staff Messages:

Keep the message private, and only moderators will ever see it.

1 hour ago, Jim M said:

You're running PHP 8.3 which is not supported. Please downgrade to PHP 8.1 or 8.0

You guys should really consider adding a maximum PHP version check both in the suite and the requirements checker. I'm not saying to lock everything with the wrong version, even a simple warning in ACP would to the job.

With a simple check for the maximum version, you'd avoid dozens of support requests... 🙄

Sorry, that doesn't help. Can you post here a few of those queries?

That said, since you mentioned the _new suffix, I think your database might not be utf8mb4. Does the Support page in ACP list any errors for the MySQL database?

What kind of queries are you being asked to run exactly? There were a few changes, but not that many. 🤔

From the js file (line 61):

ips.createModule('ips.ui.uploader', function(){

To create a new one you need to copy/paste the file in your app, change the name, update the names/references, edit the code you need, and call the new module's name in the HTML.

This is the code that registers the module (I'll use the dialog one which is more used):

		ips.ui.registerWidget('dialog', ips.ui.dialog, [ 
			'url', 'modal', 'draggable', 'size', 'title', 'close', 'fixed', 'destructOnClose', 'extraClass',
			'callback', 'content', 'forceReload' , 'flashMessage', 'flashMessageTimeout', 'flashMessageEscape', 'showFrom', 'remoteVerify', 'remoteSubmit'
		], { lazyLoad: true, lazyEvents: 'click' } );

You need to change the dialog name (maybe dialogbis) which registers the widget. All the other values in the array are the options you can use inline.

This is how the code would be with the original dialog module:

<div data-ipsDialog data-ipsDialog-title="TITLE" data-ipsDialog-remoteSubmit data-ipsDialog-flashMessage="ITEM SUBMITTED">

This is how it would look with your updated dialogbis module:

<div data-ipsDialogbis data-ipsDialogbis-title="TITLE" data-ipsDialogbis-remoteSubmit data-ipsDialogbis-flashMessage="ITEM SUBMITTED">