teraßyte

What kind of mysql issue exactly? Did they provide a list of slow queries or similar perhaps?

They like joking it seems. The problem is that PHP is not configured properly, the software has nothing to do with it. 🤨 I'm gonna ask just in case: have you provided them a link to the ips4.php file on the server where it shows the extensions are missing? If you already did and they still keep insisting it's the software I would just have them change you back to PHP 7.4 to get the site back online and then change hosting.

As per title, editing a department in the Commerce application doesn't list any custom packages in the Associable products option.

Most likely you're not allowing guests to see the forum. Check the setting in "ACP > Members > MEMBERS > Groups > Guests > Edit (pencil icon) > Can access site?"

Based on that error log, this is not something related to Invision Community but some other kind of gallery script.

Upload the file to your forum's root (where the conf_global.php file is located) and then access it from your browser using this url: https://www.singaporebikes.com/ips4.php

When adding a new extra field in Downloads the option Include field in topics? is never saved correct. Enabling it will always show it as disabled when you go edit it again. The issue is caused by the code in \applications\downloads\sources\Field\Field.php on lines 152-157: if ( \IPS\Application::appIsEnabled( 'forums' ) AND isset( $values['cf_topic'] ) ) { /* Forcibly disable include in topic option if it is a paid field */ $values['topic'] = ( isset( $values['downloads_field_paid'] ) AND $values['downloads_field_paid'] ) ? $values['cf_topic'] : 0; unset( $values['cf_topic'] ); } The code checks if the paid field option is active and disables the include in topic option. The problem is that the code above does the opposite and always disables the include in topics option when the paid file is NOT required. I swapped the values to fix it: $values['topic'] = ( isset( $values['downloads_field_paid'] ) AND $values['downloads_field_paid'] ) ? 0 : $values['cf_topic']; Another bug related to this setting is that when the topic is updated the pre-edit value is used. For the edited value to show up in the support topic you have to re-edit again the file and then it properly shows up in the topic content.

Going to the url in the first post I get redirected to https://riverandreef.store/index.html right now. Anyway, just to double check, have you run the Requirements Checker in order to confirm all the needed extension are available?

The Send diagnostic data? setting has 2 options: Usage data Error reports Disabling only 1 option (doesn't matter which) shows both options enabled again once the change is saved. The only way to keep them disabled is to disable both option at the same time.

Upon further review the file/folder I mentioned above can actually be deleted completely. In another upgrade step later on \applications\downloads\setup\upg_101088\upgrade.php the code does the same thing I described above for the fix: It drops the index It changes the column to MEDIUMTEXT (instead of TEXT) It re-adds a new fulltext index

Hmm, on big posts tables the query could cause a big delay retrieving the last guest post from the table. Not to mention that there could be multiple guests posting at the same time and they would block each other from posting. You could try checking also the IP, but if all or most of the guests are are using the same VPN/proxy that would be a problem too for example. Maybe some kind of local cookie that stores the last post date? It can be manually deleted and bypassed, but it would still work better. 🤔

What version are you upgrading from? Upgrades from old 2.x or 3.x especially are very, very troublesome. I just did one from 3.1.4 recently and it was indeed a mess. 😅

The new version has been approved. 👍

Hmm, I kept thinking something felt wrong with this code and then I finally figured it out. The code above to "fix the custom fields" drops the columns + indexes and then re-adds them, but the columns' data is not saved whatsoever? After the upgrade every custom field's data is lost. 🤨 The code should be changed to drop the index, run a CHANGE query on the column, and then re-add the fulltext index. === EDIT Just noticed I failed to include the file's path in the first post: The file is \applications\downloads\setup\upg_100013\upgrade.php

I hit the error updating an old 3.1.4 site with Downloads 2.3.1. The problem is that an upgrade script uses the wrong index type when updating the custom fields in the 4.0.0 RC 1 step. I compared the upgrader code to the normal code run when a new custom field is added and noticed the wrong type is being used. Open the file and find this code on lines 26-54: /** * Step 1 * Fixing custom fields * * @return array If returns TRUE, upgrader will proceed to next step. If it returns any other value, it will set this as the value of the 'extra' GET parameter and rerun this step (useful for loops) */ public function step1() { foreach( \IPS\Db::i()->select( '*', 'downloads_cfields' ) as $field ) { if( $field['cf_type'] == 'Select' ) { try { \IPS\Db::i()->dropIndex( 'downloads_ccontent', "field_" . $field['cf_id'] ); \IPS\Db::i()->dropColumn( 'downloads_ccontent', "field_" . $field['cf_id'] ); } catch ( \IPS\Db\Exception $e ) { } \IPS\Db::i()->addColumn( 'downloads_ccontent', array( 'name' => "field_" . $field['cf_id'], 'type' => 'TEXT' ) ); \IPS\Db::i()->addIndex( 'downloads_ccontent', array( 'type' => 'key', 'name' => "field_" . $field['cf_id'], 'columns' => array( "field_" . $field['cf_id'] ) ) ); } } return TRUE; } The problem in this case is the addIndex() call on line 49 which uses key as index type instead of fulltext. Here's how I changed it to match the code when adding a new custom field in ACP: \IPS\Db::i()->addIndex( 'downloads_ccontent', array( 'type' => 'fulltext', 'name' => "field_" . $field['cf_id'], 'columns' => array( "field_" . $field['cf_id'] ) ) );

I hit the error updating an old 3.1.4 site. The problem is that some packages have a NULL or empty string value for the p_base_price column in the nexus_packages table instead of 0. The upgrade process stops because MYSQL complains about a "Truncated incorrect DOUBLE value" error. Open the file \applications\nexus\setup\upg_40000\upgrade.php and fine the code on lines 585-594: public function step14() { $offset = isset( \IPS\Request::i()->extra ) ? \IPS\Request::i()->extra : 0; $select = \IPS\Db::i()->select( '*', 'nexus_packages', NULL, 'p_id', array( $offset, 50 ) ); if ( \count( $select ) ) { foreach ( $select as $row ) { \IPS\Lang::saveCustom( 'nexus', "nexus_package_{$row['p_id']}", $row['p_name'] ); \IPS\Lang::saveCustom( 'nexus', "nexus_package_{$row['p_id']}_assoc", $row['p_assoc_error'] ); I simply added this code below right at the start of the foreach cycle to fix the issue: # Change NULL or EMPTY STRING prices to 0 to avoid "Truncated incorrect DOUBLE value" errors $row['p_base_price'] = empty($row['p_base_price']) ? 0 : $row['p_base_price'];

Yeah, they should make it a bit more obvious that there's a renewal pending. I've seen a lot of people confused by it. 👀

While I was looking into changing the number of comments per page for database records (see this link) I found out that IPS actually already allows to control it. The problem is that the number is tied to the setting that also controls the number of records shown per page. The setting I'm talking about is "Field Options > Records per page" when editing a database settings. The name implies it controls the number of records, but at the same time it controls also the number of comments: /** * Set custom posts per page setting * * @return int */ public static function getCommentsPerPage() { if ( ! empty( \IPS\cms\Databases\Dispatcher::i()->recordId ) ) { $class = 'IPS\cms\Records' . static::$customDatabaseId; try { $record = $class::load( \IPS\cms\Databases\Dispatcher::i()->recordId ); if ( $record->_forum_record and $record->_forum_comments and \IPS\Application::appIsEnabled('forums') ) { return \IPS\forums\Topic::getCommentsPerPage(); } } catch( \OutOfRangeException $e ) { /* recordId is usually the record we're viewing, but this method is called on recordFeed widgets in horizontal mode which means recordId may not be __this__ record, so fail gracefully */ return static::database()->field_perpage; } } else if( static::database()->forum_record and static::database()->forum_comments and \IPS\Application::appIsEnabled('forums') ) { return \IPS\forums\Topic::getCommentsPerPage(); } return static::database()->field_perpage; } While simply changing the text to mention it controls also comments can be a fix, I would rather you add a separate setting that controls comments specifically. Without a new setting it would be impossible to keep showing 25 records per page but only 5 comments per page. You'd have to also show only 5 records per page. It's not ideal to have the same setting control both.

A new 1.0.1 version is currently pending approval from IPS. Here's a preview of the changelog: @Hisashi I looked into your request and I found out that CMS already provides a way for an admin to change the number of comments per page. The problem is that it is tied to the Database setting in "Field Options > Records per page". As the name implies this setting control the number of records shown while viewing a category, but I found out it also controls the number of comments per page at the same time. The problem is that you can't have 25 records show per page and only 5 comments; it's either 25 records/comments or 5 records/comments. Now, this to me looks like a bug actually. Depending on how IPS decides to handle the situation there's no need for me to add it to my plugin. For now I'm going to make a bug report for IPS to look into it. EDIT The bug report is here:

Yeah, looks like that plugin is quite old. The $anonymous parameter was added back in 4.6 if I remember right.

That's the standard download attachment link, but newer ones usually have a security key in them. Are the ones you can't download all uploaded after a certain date perhaps? If so, it may be because the security key is missing from the download link that you're getting the error. But as Jim M said, that's a custom modification so you should contact whoever made it for you. If they're not available anymore you can look at the Providers list to find a new developer to take a look at it for you:

Are you using 4.6 or an earlier version perhaps? The new hCaptcha option is available only in 4.7.0:

@My Sharona Yes and no. WebP is supported, but there's a bug in 4.7.0 preventing it from being allowed in several places (basically any forms with upload fields that allow images).

The suite not being able to load that single file is clearly some kind of permission issue with the server. You could try bypassing that error screen with the UPGRADE_MD5_CHECK constant, but that wouldn't resolve the root issue and the upgrader might still break later on. I guess your last resort would be to change hosting...? 🙄

As @Dean_ said you are running a really old version. Even IPS doesn't support upgrades from it anymore. If you are comfortable upgrading yourself that's an option, otherwise you can hire someone else to do it for you if you are unsure on how to proceed. You'll also want to check the modifications you have, if there are updated versions of them available in the marketplace, and if not consider hiring someone to update them for you if you don't know how. You can find someone in the Providers list filtering by IPS Legacy Upgrades for help with the upgrade and filter by the Programming options for help in updating eventual custom modifications: https://invisioncommunity.com/third-party/providers/ I'm on that list too if you need help. 😉