teraßyte

Just submitted the new 1.0.1 version: Just waiting for IPS to approve it now.

Looking at your screenshot you have a suspicious autoDeleteMsg task that has never run and is not tied to any specific application/plugin either. My guess is that that task is always failing to run and is blocking everything else after it in the queue. That's why you keep getting the "tasks not running" message.

By "hitting finish without making the change" do you mean the last step where you're supposed to make the change in conf_global.php? Depending on the charset you converted from you might see errors and the forum won't load until the change is applied.

Have a look at this topic: 🙂

I was asked by PM but I'll reply here for everyone. 🙂 This modification is already compatible with 4.7 but I haven't submitted an update yet because I plan on including a couple of changes and submit directly a new version. Those who have it already installed can keep using it without worries. Those who want to install it and are already on 4.7 have 2 options: either wait until the new version is submitted and approved, or just download the plugin from my site and install it manually in the ACP. It won't be long anyway. 👍

Use the constant mentioned in this topic to temporarily bypass the error:

I noticed the same issue with an upgrade earlier. It seems the MD5 hash of the new patched files is wrong for that specific one. I bypassed the error by adding the constant to skip the MD5 check for now.

It's a theme template: nexus > global > invoices > printInvoice

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. 👀