teraßyte

That shouldn't be the case. If that column is missing nothing else should be loading. Unless it's using the built cache and the code works because of it. If that's the case, it will break next time the cache is rebuilt, though. Most likely you're getting that error trying to login into the ACP because the task doesn't use cached data but runs a query directly on the table (with the missing column). 🤔

If you weren't doing any upgrades or anything else in the database, then you have a problem. A big one. The core_applications.app_directory is a required column for the software, if it's missing something went wrong somewhere. You'll most likely need to restore the last working backup you have.

Rather than checking the permissions, look at the text at the top. It's saying that some files might not have been uploaded correctly. The upgrader checks if the files are all for the version you're upgrading to before letting you start the process. It's possible your FTP program didn't properly upload/overwrite some files.

Okay, I found out what is going on thanks to an email from Google. It seems some of their Google Maps JS (?) was also using polyfill.io: The text doesn't explicitly say they were using it too (only examples), but nothing else comes to mind since I don't use that JS library on my site, either. 🙄

Unfortunately, there are only 2 options available at this time: You can manually remove the EXIF data from the template: gallery > front > view > metadata. Use a custom modification to hide/remove it without editing the template. Not editing the template means it can auto-update with future upgrades rather than getting stuck on your custom edit. (Recommended)

I just ran a grep on the 4.7.17 files, but there are no references to that domain in any file. If CloudFlare detected it on your site, it must be coming from another script. Or maybe a 3rd party modification you're using.

The authorization/token is most likely linked to the APP ID/API key. If you change them, the token becomes invalid/unavailable. It would be a security issue if you could just switch the keys anytime.

To add one more issue: If you set a minimum time (for example: 25 June, 3:00 AM) and select a time lower than 3 AM (for example: 25 June, 2 AM) the field's error says: The date must be after 06/25/24 03:00:00 AM. However, if you enter that exact minimum date, the value is processed without error. The error should be updated to clarify that the minimum value is accepted, too: The date must start from 06/25/24 03:00:00 AM. === The date must be at least 06/25/24 03:00:00 AM. Either option or something else would work.

I noticed one more issue with the code in the first post when the time option is enabled for the min/max checks: if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } ======================= if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } The code passes the logged-in member's object as the first parameter to determine the language, but the function accepts that value as the third parameter instead: /** * Format the time according to the user's locale (without the date) * * @param bool $seconds If TRUE, will include seconds * @param bool $minutes If TRUE, will include minutes * @param \IPS\Lang|\IPS\Member|NULL $memberOrLanguage The language or member to use, or NULL for currently logged in member * @return string */ public function localeTime( $seconds=TRUE, $minutes=TRUE, $memberOrLanguage=NULL ) Both localTime() calls should be updated to: ->localeTime( TRUE, TRUE, \IPS\Member::loggedIn() ); It would be nice if there were also a new option to decide if we want to show the seconds/minutes in the error, but that's a request rather than a bug. 😋

The problem is that all language strings are currently in the same IN_DEV lang.php file. There is no distinction on where they're used. At least in 4.x, no idea about v5. The developers would need to go through all language strings, manually change the file format flagging each string with admin/public (or both), and finally change how the file is parsed reworking the build process. And if you then use an admin-only or public-only language string in the other area, you'd have to remember to go back and update the flag or it would display wrong. IP.Board 3.x used to have separate admin/front language files, but that also caused issues because there were tons of duplicate strings since the files were only loaded in their respective areas. Which is why I assume they unified everything for 4.x. While the flag idea is a simple one, honestly I can't see an easy way to actually implement it. 🤷‍♂️

The latest version fixes a bug I reported a few months ago: Files marked for removal from the bucket were never actually removed because the task wasn't activated properly. In your case clearing the system caches from ACP should have rebuilt the CSS files if they were deleted by error (it shouldn't have happened, though).

A lot of people using that old application actually switched to using Radical Tags, which includes a tool to import the data:

I'm helping with the upgrade, and I figured it out. I'm posting the cause in case someone else hits the same issue. The Gallery application was not updated to the latest version (5.0.5) for IP.Board 3.4.6. Some required tables/columns added in newer versions were missing, which caused the errors.

The only option would be a modification that allows bypassing the cutoff time setting for first posts. I think there was one in the old marketplace, but I can't find it anymore. EDIT: Nathan's solution might work, too if you don't need to strictly edit the first post as long as the updated list is clearly visible.

Line 1932 of that file is this exception: public function getTableDefinition( $table, $columnsOnly=FALSE, $getCollation=FALSE ) { /* Set name */ $definition = array( 'name' => $table, ); /* Fetch columns */ if( !$this->checkForTable( $table ) ) { throw new \OutOfRangeException; } However, there is no call to getTableDefinition() in the 40000 upgrade step of the gallery application. 🤔 There might be more info logged inside /uploads/logs. Try looking there. As for disabling the gallery, it would be best to restore a backup, and not upgrade the application from the start rather than trying to bypass it now. It would only cause a mess.

If you're hosted on CIC/Cloud, IPS can do it for you. If you're self-hosted, try asking your hosting if they can help. If your hosting can't help, you can hire a 3rd party Provider to help you. It's a simple thing. As long as you know what you're doing, though. 🙂

Seems like you had the Pages application installed before and it wasn't removed correctly. 🤔 I think you'll need to delete manually any tables with the cms_ prefix in your database. Then try installing again the application. Always make a backup before deleting any tables, though.

From which version did you upgrade? Some functions had their parameters changed (example: \IPS\Model::setLastComment), so it's possible that the compatibility checker disabled those applications until you update them.

Promotion rules are only checked when a member logs in. If a member is inactive and doesn't visit the forum anymore, the rule to move them will never be triggered. I assume the mod to member 2 group is a similar rule. Inactive moderators are downgraded to normal members. Again, if the member doesn't visit the site the rule isn't triggered.

Sounds like you have chosen the Administrator validation option. For the user to receive an email you need to choose Email validation (Recommended). Or choose Email and administrator validation if you also want an admin to validate the account after the user validates their email.

If you are using Pages, the best option is to make custom templates with all that information removed (or hidden for specific groups) rather than adding per-database settings. There are already way too many settings there. 🙄

Since you're also switching the PHP version you need to do a manual upgrade. The automatic upgrade from the ACP won't work in this case. Here's a link to the guide: https://invisioncommunity.com/4guides/advanced-options/server-management/install-and-upgrade-r259/#manualupgrade

As Randy said, there is no way to alert admins with a notification that a user clicked the link. However, if you're interested, it is possible to create a custom modification for it.

It's in the alpha testing stage right now. There's no specific release date just yet. 🤷‍♂️

It's called Topic Summary. You can enable it in ACP > Community > FORUMS > Settings > Forum Settings TAB. 👍