teraßyte

You could save the member ID in a custom profile field before the import. Then when you import the members (and their custom profile field) you can use that field as game server ID rather than their core_members.member_id value.

I've recently noticed the badge missing the SVG image like that also on two upgraded 4.7 installs (from 4.4). You might want to check that too. 😋

Your best option would be to compare the API file to see how the code actually changed. From which version did you upgrade? The code above doesn't help though. We'd need to see the code that actually calls the API to see in which format the data is being sent. That's where the error is.

Editing a department settings in ACP the Associable products option doesn't list the custom packages. === Something else related is that when creating a product and enabling the option Show 'Submit Support Request' button the package is not automatically added to the list of associable products for the department. When said department requires an associated product (and a custom product at that) there is simply no way to setup it right now.

I reordered the fields in "ACP > Commerce > STORE > Custom Fields" but the display order changes only when viewing the product in the frontend store or manage purchases area. Viewing/editing a product in ACP the fields are still ordered by ID (in the order they were created).

Yeah, I thought it was a custom app at first but that error comes from the CMS API to create/update a record. Specifically the code that handles files for a custom upload field: elseif ( $field->type === 'Upload' ) { $multiple = $field->is_multiple; $imageOnly = ( isset( $field->extra[ 'type' ] ) AND $field->extra[ 'type' ] === 'image' ); $extensions = \is_array( $field->allowed_extensions ) ? $field->allowed_extensions : array(); /* Did they meet the api parameter type requirement (the field must be an object) */ if ( !\is_array( \IPS\Request::i()->fields[ $field->id ] ) ) { throw new \IPS\Api\Exception( 'UPLOAD_FIELD_NOT_OBJECT', '1S306/E', 400 ); } It it was working before I guess the API code is old while the forum was updated at some point and the API code changed but the external code was not updated.

With just that code it's hard to say anything really. It would also help if you post the full backtrace of the error rather than just "UPLOAD_FIELD_NOT_OBJECT".

Version 7.17.5 in the dropdown should work. It's higher than 7.2.0 and lower than 8.0.0. 🤨

What @Randy Calvert said. While the IPS Legacy Upgrades filter is unrelated to your issue (you're not upgrading your forum), developers listed under it can certainly help better than others since they deal with Legacy Upgrades. I'm in that list too if you want to shoot me a PM with more details. 😉

I recall there was a patch related to dates for Pages. Do you have any patches listed in ACP > Support that need to be applied? If yes apply the patches and then try again.

Only if it's PHP 8.0.21 or lower since 8.0.22 has the same issue. To be completely safe any 7.4 version works.

I've seen a few issues around with 8.1. I think using 8.0 is better for now.

Switching back to PHP 7.4 should work too as a temporary fix in case disabling the calendar app is not an option.

Those tasks do their own things in batches. Doing everything at once would just lock the task with a timeout error otherwise. Especially on big boards. viewupdates is for storing the temporary views into their proper column in the content's table (like topics views). Updating constantly the table would lock it all the time, the code instead saves each view as a new row in a temporary table and then the task counts the rows and adds only once the views in the proper table. clearcache drops the caches from the core_cache table and the guest output cache. The code simply drops rows that are already expired. Other code in different files checks if a block/sidebar/widget cache is expired and refreshes them.

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