Everything posted by teraßyte
-
For now, as a workaround, I made the client disable letter photos and added a visible warning when the setting is enabled. -
I have an application that sets a member’s profile photo to an image uploaded in a different FileStorage extension. I’m talking about this code in the \IPS\Member::photoUrl() function: /* We have an uploaded or synced photo */ if ( $memberData['pp_main_photo'] and ( mb_substr( $memberData['pp_photo_type'], 0, 5 ) === 'sync-' or $memberData['pp_photo_type'] === 'custom' ) ) { try { $photoUrl = File::get( 'core_Profile', ( $thumb and $memberData['pp_thumb_photo'] ) ? $memberData['pp_thumb_photo'] : $memberData['pp_main_photo'] )->url; } catch ( InvalidArgumentException $e ) { } } /* Letter photos are enabled and we do not have a photo set, but only if this isn't for email */ elseif( Settings::i()->letter_photos == 'letters' AND $email === FALSE and isset( $memberData['name'] ) ) { if( $photo = static::generateLetterPhoto($memberData) ) { $photoUrl = $photo; } } /* Other - This allows an app (such as Gallery) to set the pp_photo_type to a storage container to support custom images without duplicating them */ elseif( $memberData['pp_photo_type'] and $memberData['pp_photo_type'] != 'none' and mb_strpos( $memberData['pp_photo_type'], '_' ) !== FALSE ) { try { $photoUrl = File::get( $memberData['pp_photo_type'], $memberData['pp_main_photo'] )->url; } catch ( InvalidArgumentException $e ) { /* If there was an exception, clear these values out - most likely the image or storage container is no longer valid */ $member = Member::load( $memberData['member_id'] ); $member->pp_photo_type = NULL; $member->pp_main_photo = NULL; $member->save(); } } I am talking about the second/last elseif check in the code above: /* Other - This allows an app (such as Gallery) to set the pp_photo_type to a storage container to support custom images without duplicating them */ elseif( $memberData['pp_photo_type'] and $memberData['pp_photo_type'] != 'none' and mb_strpos( $memberData['pp_photo_type'], '_' ) !== FALSE ) { try { $photoUrl = File::get( $memberData['pp_photo_type'], $memberData['pp_main_photo'] )->url; } catch ( InvalidArgumentException $e ) { /* If there was an exception, clear these values out - most likely the image or storage container is no longer valid */ $member = Member::load( $memberData['member_id'] ); $member->pp_photo_type = NULL; $member->pp_main_photo = NULL; $member->save(); } }The problem is that when letter photos are enabled the first elseif check before this one takes precedence and overwrites the custom image. The code must be changed to check/generate letter photos as the last step only if no custom image with a FileStorage container is specified.
-
Any way you can add that specific fix to this site? I’d love to test it asap. 🤞 Since the upgrade using the editor here has been extremely frustrating. It would also help confirm if the fix is indeed working or not.
-
It won’t work without updates. The PHP class names changed, the HTML too is completely different, etc. I recently finished remaking one of his applications for a client (Profile Photos & Covers), and I have requests for several of his other apps. However, rather than updating Mike’s code, I am coding my apps from scratch and including some code to convert any Devfuse data (if detected). That way I can resell the modifications in my store. The one I just mentioned, (TB) Default Profile Photos & Covers, will be available to everyone soon.
-
And if you have modifications installed, be sure to check there is already a compatible version available.
-
The g_fcontent_excludeFGroup column is not a default one. Based on the name, did you install a Featured Content application at some point? 🤔
-
Fixed in 4.7.19.
-
Fixed in 4.7.19.
-
Fixed in 4.7.19.
-
Fixed in 4.7.19.
-
It was fixed in 4.7.20 Beta 3 (or 4?).
-
Even backing up the app’s tables might not be enough. Some apps may have permissions, attachments, achievement rules, etc, and those are stored in core tables. The best option is to leave the app installed. The upgrade to v5 will disable it and retain all the data.
-
I’m unsure what this safety act says, but in case of issues, if a user reports a reply in a message, the moderator is added to the message’s user list and can review everything. Would that be enough? 🤔
-
@Matt Finger If you need help testing I’m available. 😋
-
Even clicking a single checkbox myself to select a message takes 1~2 seconds before the action is done. On v4 it’s instant. Something is slowing down considerably the JavaScript in v5 (at least on Windows 10 + Chrome v132): Tooltips are laggy The editor lags behind if I type too fast (I mentioned it to @Matt in another topic and even posted a video) The JS to select rows based on their type is extremely slow, too Other JS-related things feel slow, too
-
By valid HTML I mean that a DIV element MUST be inside <BODY>. You can’t add it before/after/inside the <HEAD> element, nor you can add it before/after the <BODY> element. You’re adding a <DIV> element before <HEAD> which results in this (extremely simplified) HTML below: <!DOCTYPE html> <html lang="en-US"> <div>Test</div> <head> <title>Testing a wrong DIV element</title> </head> <body> <div>This is a DIV inside the BODY element.</div> </body> </html>Try validating that HTML code and see you’ll get errors: https://validator.w3.org/#validate_by_input Then remove that first DIV above <HEAD> and you’ll see the validation is okay: <!DOCTYPE html> <html lang="en-US"> <!-- TEST DIV REMOVED --> <head> <title>Testing a wrong DIV element</title> </head> <body> <div>This is a DIV inside the BODY element.</div> </body> </html> Basically, the browser is trying to compensate/fix the HTML (but fails miserably) because you added an unexpected/wrong DIV element where it shouldn’t go.
-
While viewing the messenger I opened the menu to “Select rows based on type” (checkbox above the messages list) and clicked the All option. The JS took ~6 seconds to run and select All checkboxes. I then clicked None to deselect everything. It took about ~5 seconds. I then loaded a second page of messages (50 total) and selecting again the All option took ~14 seconds. I clicked again None and it took ~12 seconds. A third page (75 messages) took ~27 seconds and I even received a warning from Chrome that the page was unresponsive and I could wait or close it. ( I clicked wait.) Same thing when deselecting all 75 messages: ~24 seconds and again Chrome warned me the page was unresponsive. Clearly, there’s some JS issue. It shouldn't take this long. The more messages are listed, the more time it takes.
-
Yes, based on what you posted, this is most likely a bug introduced when adding the code to deprecate SendGrid.
-
Because it’s not valid HTML. The bug here is not that the HTML breaks, but that it shouldn’t allow you to choose that option.
-
Have you cleared the cache from ACP > Support after updating the setting manually in the database?
-
You really shouldn’t add HTML before or after the <head> tag, nor <body> for that matter. Only inside them.
-
SendGrid integration is being deprecated, at least I saw some code changes that indicate that in 4.7.20 Beta 3: public static function isAvailable() { if( Settings::i()->sendgrid_deprecated ) { return FALSE; } return TRUE; } However, it should still show for those who had it configured: /** * Show Sendgrid for those that have it configured * * @return bool|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 step2() { if( \IPS\Settings::i()->sendgrid_api_key ) { Settings::i()->changeValues( [ 'sendgrid_deprecated' => 0 ] ); } return TRUE; }
-
Speaking of MariaDB only, I know a client updated from 10.3 to 10.6 and saw noticeable improvements.
-
In case it matters, it’s Chrome v132 on Windows 10.
-
I noticed that sometimes the browser tab gets a (X) number in the title because there are new notifications, but when I open the tab itself the notifications icon doesn’t display any count. Only after I refresh the page the count properly appears on the bell icon. Most likely the HTML for the notification icon changed at some point but the JS to update the count was not updated with the new element. Just a guess, though.
