Jump to content

teraßyte

Clients

  • Joined

  • Last visited

View Profile Find content

Bug Comments posted by teraßyte

    The API does have the code to send out the notification:

    		$post = $commentClass::create( $item, $postContents, TRUE, NULL, NULL, \IPS\Member::load( (int) \IPS\Request::i()->from ), \IPS\DateTime::create() );
		
		$item->first_msg_id = $post->id;
		$item->save();

		/* Authorize sender and recipients */
		$item->authorize( array_map( function( $member ) { return (int) $member; }, array_merge( array( \IPS\Request::i()->from ), \IPS\Request::i()->to ) ) );

		/* Send notifications */
		$post->sendNotifications();

		return new \IPS\Api\Response( 201, $item->id );

    If the notification is not going out, the default option for PMs must be set to disabled in your ACP. New users use the default values setup in ACP:

    ·

    Edited by teraßyte

    4 hours ago, marklcfc said:

    Does it still notify you of new replies now?

    No, it doesn't. Looks like I need to remember to refresh each tab before I reply now. For example, I wouldn't have replied to the topic I linked above since the user clarified in newer replies that it was actually HTML/JS rather than PHP.

    I don't remember this feature removal being discussed anywhere. It's a rather 'annoying' change. 😒

    @Matt Finger Unfortunately, while there was a slight improvement, the lag is still huge most of the time. Typing long messages in the editor gets rather frustrating.

    Still, I noticed something else that might help: the lag varies depending on the page. For example, the editor is rather fast when posting a new comment in this bug report, however, when I try to post a reply on a topic with lots of replies, or a personal message with 20+ replies, the editor lags a lot more.

    I think the content on the page directly impacts the amount of lag. The more content there is, the more it lags. In this bug report, with only 6 comments, and no sidebar (except for a small text block), the lag is basically non-existent if I type normally. It still lags behind a bit if I type random characters fast, though.

    ·

    Edited by teraßyte

    It looks like your WordPress plugin adds a function with the same name.

    As a temporary workaround, instead of renaming init.php, comment/remove this code at the bottom of the file:

    /* Custom mb_ucfirst() function - eval'd so we can put into global namespace */
eval( '
function mb_ucfirst()
{
	$text = \func_get_arg( 0 );
	return mb_strtoupper( mb_substr( $text, 0, 1 ) ) . mb_substr( $text, 1 );
}
');

    Otherwise, editing the code to this should work, too:

    /* Custom mb_ucfirst() function - eval'd so we can put into global namespace */
if ( !\function_exists('mb_ucfirst') )
{
	eval( '
function mb_ucfirst()
{
	$text = \func_get_arg( 0 );
	return mb_strtoupper( mb_substr( $text, 0, 1 ) ) . mb_substr( $text, 1 );
}
');
}

    IPS can implement a fix to check if the function exists before running the eval() code. This function is included with PHP 8.4.0+, so it can be removed then. However, since v4 doesn't support PHP 8.2.+, we'll eventually get there with v5.0.0.

    On 1/21/2025 at 6:28 PM, Matt Finger said:

    As a side note, the slow editor issue should be resolved in the next release, but it’s one of those things that is very hard to test as it works performantly on our machines.

    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.

    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

    ·

    Edited by teraßyte

    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.