teraßyte

Edit the option Can login anonymously? for your groups in ACP. It has 3 choices: Allowed Forced Disallowed If you're seeing everyone invisible this option might be set to Forced. If it's set to Allowed it might be a bug with the conversion that converted every member to hide their online status instead. Or you can force everyone to be visible by choosing Disallowed so every member's choice doesn't apply.

The new 1.0.1 version is now approved and available. 🙂

Yeah, it's a known issue. Since it's a weekend and no developers are around it will be fixed tomorrow most likely:

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