G17 Media

Google doesn't need to render the code. 2FA/TOTP QR code generation does not require data being sent to Google. There is not a need for IPS to be sending these codes to Google for rendering, it could be done locally. Google Authenticator is one app for 2FA/TOTP codes, but you can use other apps. Even Google Authenticator itself does not transmit/backup TOTP codes to Google unless you activate its optional backup function.

Is 2FA data really being sent to Google for rendering? 😕

To replicate on any IPS community: Create File Moderator subgroup, add it to Moderators, give every File/Downloads permission (including hide/unhide). Post a file where approval is required. Note that the file appears in the approval queue for a user in that moderator group. Post an update to said file, where approval is required. Note that the file is not shown in the approval queue for this moderator group, nor can they actually approve the file. I've fixed this on my community so I don't need this to be fixed upstream - but this is a heads up for a bug in Invision Community.

Moderators with all Downloads permissions granted do not see pending versions in the approval queue. Is there a permission I'm not seeing for pending files versions?

We're experiencing an issue with moderators with only file permissions granted being unable to see pending versions in the approval queue. I looked into this and there's a check in ./applications/downloads/extensions/core/ContentRouter/Files.php:49 where PendingVersion is only inserted where \IPS\downloads\File::modPermission( 'unhide', $member ) is true. However, since no container is provided, this will only return true if the user has global content unhide permission.

That's a complete bizarre modification DigitalOcean have made to MySQL. There are definitely use cases for not using a primary ID in some tables. As @Marc Stridgen mentions it's not even needed for replication. We also use replication on our self-hosted infra without this need. Be aware that if you make any schema change, IPS will attempt to undo it every upgrade.

The conversion page mentions new terms, could you link to them on that page or here? I can't seem to find them.

Also seen this - it's rare enough we never reported, but certainly seems to happen.

Did you ever get a chance to do this?

Bump - this is a big issue for forums which are image or embed heavy and go beyond 1 page. This would also benefit those Cloud customers to fix 😉

The core of the issue I uncovered during testing was a failure in IPS' URL encoding and had nothing to do with Minio/Wasabi (although I am happy to be wrong -- works fine in our environment with a one line fix). The "scariest" feature IPS really uses is multipart file uploads, which work on pretty much any S3 compatible service I've used.

Hello, I've discovered a bug in how IPS' lazyloading works on dynamic elements. in ./dev/js/library/app.js, line 61, you define a hook/override for $.fn.html. This makes sure that if dynamically loaded HTML contains lazyload elgible content, you instate the lazyload handler on it. The problem seems to be instead of looping each lazyload element, ips.utils.lazyLoad.observe is called on the entire element. This then registers the IntersectionObserver on the entire element, causing each lazyloading element to be loaded straight away, defeating the point of the lazyload. The fix is to instead call ips.utils.lazyLoad.observe on each lazyload capable element, like it's done elsewhere in the suite. I have patched this locally, but thought it would be useful to share to the IPS developers. Happy new year!

IPS sets the headers just fine! Provided your guests don't change the theme. And provided they don't use a different language. 🤔

I remember IPS mentioning their S3 implementation was meant for S3 and not S3 compatible services. So you will probably be on your own here hacking at /system/File/Amazon.php to make it work. There is also an incompatibility in their generateTemporaryDownloadUrl/URL system which at some point made their signature URLs invalid with Wasabi & Minio. I'm not sure if it's still an issue, as we use a heavily patched /system/File/Amazon.php for our Minio deployment.

Edit: This seems to only happen on very old gallery images. So perhaps it is old data causing that to be NULL?