Everything posted by teraßyte
-
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.
-
If you don’t want to use the visual language editor, you can edit/translate the name from the ACP instead:
-
Was the MySQL 8 configuration the same as MariaDB? If the configuration values are different, it’s possible that MySQL 8 was simply using non-optimized values. I know some of my clients switched from MariaDB to MySQL and their sites were faster overall. However, their configuration was also tuned by expert server administrators. 🤷♂️
-
Yeah. The red/green backgrounds appear on page load, but then some JS takes over and removes them. I guess it’s related to the new Monaco change for the code boxes: 🤔 #3189: Use Monaco editor for code boxes
-
I entered this content in the editor: "Hello" 'world'! The editor however converts the single/double quotes to: “Hello” ‘world’! It shouldn’t replace the text I type. At least it seems the replacement is not done inside code boxes.
-
I used the “mark all content as read” to get rid of the items for now.
-
INT: ~2 GB (signed column) or ~4 GB (unsigned column). BIGINT: ~9.2 EB (signed column) or ~18.4 EB (unsigned column). You’re good for a while. 😹
-
@Matt Previously I also posted a bug report about the tooltips being laggy. Could it be the same root issue somehow? 🙄
