Colonel_mortis

To reproduce: Go to the full search page, /search/ Apply a date filter (either created or updated), with value set to "Custom" and a start and/or end date Enter a search term, and submit Refresh the page (or click one of the "Didn't find what you were looking for" suggested filters) Expand the search filter options again, and observe that the supplied date filter has been cleared Edit the search term, then submit the search request again, and observe that the date filter is no longer being applied This is because in core/html/front/search/filters.phtml, lines 193/197/219/223, you're directly stringifying the current value, which is a \IPS\DateTime {$elements['search_tab_content']['updatedDateCustom']->value['end']} which results in a non-ISO8601-compliant timestamp like "11/03/22 12:00 AM" (rather than 2022-11-03). You probably need to do something like you already have in the regular Date form element template value="{{if $value instanceof \IPS\DateTime}}{$value->format('Y-m-d')}{{else}}{$value}{{endif}}" (This was reported to me by a user using Firefox, and reproed also in Firefox. It's possible that other browsers tolerate the invalid values, I haven't checked, but doing so would not be standards compliant).

To reproduce: Create a moderator with the permissions set to "Restricted", but leave everything checked (the thing that actually matters here is that the "All" checkbox is enabled in the forum selector in the forums tab) (From any user) attempt to report a forum post Observe that you get redirected to an error saying "You have already reported that.", and that the original request returned 500 Stack trace: TypeError: in_array(): Argument #2 ($haystack) must be of type array, int given (0) #0 /opt/forum/system/Content/Content.php(1714): in_array() #1 /opt/forum/init.php(940) : eval()'d code(62): IPS\_Content->report() #2 /opt/forum/system/Content/Controller.php(3001): IPS\moderation_hook_Content->report() #3 /opt/forum/system/Content/Controller.php(2271): IPS\Content\_Controller->_report() #4 /opt/forum/applications/forums/modules/front/forums/topic.php(1240): IPS\Content\_Controller->__call() #5 /opt/forum/system/Dispatcher/Controller.php(107): IPS\forums\modules\front\forums\_topic->__call() #6 /opt/forum/system/Content/Controller.php(50): IPS\Dispatcher\_Controller->execute() #7 /opt/forum/applications/forums/modules/front/forums/topic.php(39): IPS\Content\_Controller->execute() #8 /opt/forum/system/Dispatcher/Dispatcher.php(153): IPS\forums\modules\front\forums\_topic->execute() #9 /opt/forum/index.php(13): IPS\_Dispatcher->run() #10 {main} The buggy code is \IPS\Content::report, L1710-1719: if ( $canView === TRUE and $container = $item->containerWrapper() and isset( $container::$modPerm ) ) { if ( isset( $perms[ $container::$modPerm ] ) and $perms[ $container::$modPerm ] != '*' ) { if ( ! in_array( $item->mapped('container'), $perms[ $container::$modPerm ] ) ) { $canView = FALSE; } } } The tag for a moderator with no forum restrictions is -1, not '*': if ( isset( $perms[ $container::$modPerm ] ) and $perms[ $container::$modPerm ] != -1 )

Leads to It had originally been failing to load the whole page, but I think that's because I had designer mode enabled.

When you hide a topic, the notifications relating to that topic are deleted. However, if there are notifications still queued to be sent (eg because there were a large number of followers), those notifications still end up getting sent, so users receive a notification about a post that they can't see, and the notification doesn't ever get deleted.

Sometimes when a topic is becoming fairly heated, members want to step back and stop replying. However, when they get quoted, they frequently can't resist coming back to continue the argument. It would be really helpful for those users if they could choose to stop receiving quote (and perhaps mention, although that's less prevalent) notifications for a specific post or topic, to help with their self-control.

When databaseCheck is run as part of the 4.7.2 -> 4.7.3 upgrade, it ends up running additional queries to fix the schema, because they weren't included as queries by the upgrader: ALTER TABLE `calendar_events` ADD COLUMN `event_external_url` VARCHAR (255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL , ADD COLUMN `event_latitude` DECIMAL (10,8) NULL , ADD COLUMN `event_longitude` DECIMAL (11,8) NULL ; This doesn't cause issues because it was caught by the databaseCheck, but as with the previous time that something like this happened: this could cause problems in future.

Error: Call to a member function format() on null (0) #0 /var/www/html/ips-themes/system/Patterns/ActiveRecord.php(335): IPS\calendar\_Event->get__happening() #1 /var/www/html/ips-themes/system/Theme/Theme.php(4620) : eval()'d code(36): IPS\Patterns\_ActiveRecord->__get() #2 /var/www/html/ips-themes/system/Theme/Dev/Template.php(171): IPS\Theme\theme_calendar_front_view_coverPhotoOverlay() #3 /var/www/html/ips-themes/applications/calendar/sources/Event/Event.php(2309): IPS\Theme\Dev\_Template->__call() #4 /var/www/html/ips-themes/applications/calendar/modules/front/calendar/event.php(166): IPS\calendar\_Event->coverPhoto() #5 /var/www/html/ips-themes/system/Dispatcher/Controller.php(118): IPS\calendar\modules\front\calendar\_event->manage() #6 /var/www/html/ips-themes/system/Content/Controller.php(50): IPS\Dispatcher\_Controller->execute() #7 /var/www/html/ips-themes/applications/calendar/modules/front/calendar/event.php(64): IPS\Content\_Controller->execute() #8 /var/www/html/ips-themes/system/Dispatcher/Dispatcher.php(153): IPS\calendar\modules\front\calendar\_event->execute() #9 /var/www/html/ips-themes/index.php(13): IPS\_Dispatcher->run() #10 {main} To repro: Create an event that repeats every 6 years, with a start date in 2019 Try to view that event This is because Event::nextOccurrence only searches within a couple of years, and returns null if it goes out of range, but get__happening doesn't handle null.

Given the prominence of the banner, I would argue it's visual clutter for all but new members, but that does make sense. I'm just not a fan of features only showing up to non-staff, because then we don't form opinions on them (for the same reason, our admins are not exempt from ads). I like the idea of having users choose a topic type, though I'm not sure what the solution would need to look like to be customizable enough (eg different sections have different options).

Search query was "solved"

If a user is a moderator, they never see the solved_did_it_tho_title banner to prompt them to mark a post as the solution, and also don't see the prominent "mark as solution" button. This means we don't know it exists until a member complains about it. This is because you condition both on $topic->isNotModeratorButCanSolve(), when it should really be something like $topic->isNotModeratorButCanSolve() || $topic->starter == \IPS\Member::loggedIn(). As feedback, I would like to be able to configure which forums the banner shows up in, and users get corresponding re-engagement emails - I have solutions turned on for all forums, because it is sometimes useful, but there are only a few where I truly want to push it. // repost from bug report since apparently this is WAI

If a user is a moderator, they never see the solved_did_it_tho_title banner to prompt them to mark a post as the solution, and also don't see the prominent "mark as solution" button. This means we don't know it exists until a member complains about it. This is because you condition both on $topic->isNotModeratorButCanSolve(), when it should really be something like $topic->isNotModeratorButCanSolve() || $topic->starter == \IPS\Member::loggedIn(). As feedback, I would like to be able to configure which forums the banner shows up in, and users get corresponding re-engagement emails - I have solutions turned on for all forums, because it is sometimes useful, but there are only a few where I truly want to push it.

Whoops\Exception\ErrorException thrown with message "Undefined array key "icons_homescreen_maskable"" Stacktrace: #6 Whoops\Exception\ErrorException in /var/www/html/ips/applications/core/modules/admin/customization/icons.php:218 #5 Whoops\Run:handleError in /var/www/html/ips/applications/core/modules/admin/customization/icons.php:218 #4 IPS\core\modules\admin\customization\_icons:processApplicationIcon in /var/www/html/ips/applications/core/modules/admin/overview/onboard.php:183 #3 IPS\core\modules\admin\overview\_onboard:manage in /var/www/html/ips/system/Dispatcher/Controller.php:118 #2 IPS\Dispatcher\_Controller:execute in /var/www/html/ips/applications/core/modules/admin/overview/onboard.php:40 #1 IPS\core\modules\admin\overview\_onboard:execute in /var/www/html/ips/system/Dispatcher/Dispatcher.php:153 #0 IPS\_Dispatcher:run in /var/www/html/ips/admin/index.php:13 URL: /admin/?app=core&module=overview&controller=onboard&initial=1 (on submitting the onboarding wizard) The only action I took during the wizard was to change the site URL (no uploads). I'm IN_DEV.

The nullability analysis doesn't take into account nulls that are explicitly in the global namespace (which is unnecessary but legal). Hook: public function canSetBestAnswer( \IPS\Member $member = \NULL ) Original method: public function canSetBestAnswer( \IPS\Member $member = NULL ) Analysis: [ "method" => "canSetBestAnswer", "reason" => "method_issue_parameters", "parameter" => null, "subclassFile" => "/applications/lmgsys/hooks/bestAnswer_ForumsTopic.php", "baseFile" => "/applications/forums/sources/Topic/Topic.php", "baseClass" => "\IPS\forums\Topic", "subclassMethod" => [ "final" => false, "security" => "public", "static" => false, "name" => "canSetBestAnswer", "parameters" => [ "member" => [ "name" => "member", "type" => "\IPS\Member", "nullable" => false, "passedByReference" => false, "packed" => false, ], ], "returnType" => null, "lineNumber" => 17, ], "subclassName" => "\IPS\forums\lmgsys_hook_bestAnswer_ForumsTopic", "baseMethod" => [ "final" => false, "security" => "public", "static" => false, "name" => "canSetBestAnswer", "parameters" => [ "member" => [ "name" => "member", "type" => "\IPS\Member", "nullable" => true, "passedByReference" => false, "packed" => false, ], ], "returnType" => null, "lineNumber" => 1388, ], "class" => "\IPS\forums\Topic", "priority" => true, ], [ "method" => "canSetBestAnswer", "reason" => "method_issue_nullable", "parameter" => "member", "subclassFile" => "/applications/lmgsys/hooks/bestAnswer_ForumsTopic.php", "baseFile" => "/applications/forums/sources/Topic/Topic.php", "baseClass" => "\IPS\forums\Topic", "subclassMethod" => [ "final" => false, "security" => "public", "static" => false, "name" => "canSetBestAnswer", "parameters" => [ "member" => [ "name" => "member", "type" => "\IPS\Member", "nullable" => false, "passedByReference" => false, "packed" => false, ], ], "returnType" => null, "lineNumber" => 17, ], "subclassName" => "\IPS\forums\lmgsys_hook_bestAnswer_ForumsTopic", "baseMethod" => [ "final" => false, "security" => "public", "static" => false, "name" => "canSetBestAnswer", "parameters" => [ "member" => [ "name" => "member", "type" => "\IPS\Member", "nullable" => true, "passedByReference" => false, "packed" => false, ], ], "returnType" => null, "lineNumber" => 1388, ], "class" => "\IPS\forums\Topic", "priority" => true, ], ],

I'm not proposing that they proactively monitor all exceptions reported by everyone (although I do think that with the right architecture (clearly they should not look at every single individual log) it would be feasible with minimal overhead, and fairly valuable). All I am asking for here is that when someone reports a bug relating to an uncaught exception, IPS support use the logs to see whether it's a widespread issue or just isolated to the reporter, and handle it accordingly. If the logs aren't being used for proactive or reactive error investigation, I'm struggling to see why they bother to collect them at all.

It does also report exceptions 🙂 /** * Should a given exception be reported to IPS? Filter out 3rd party etc. * * @param \Throwable $exception The exception * @return void */ final public static function reportExceptionToIPS( $exception ) { $response = \IPS\Http\Url::external('https://invisionpowerdiagnostics.com')->request()->post( array( 'version' => \IPS\Application::getAvailableVersion('core'), 'class' => \get_class( $exception ), 'message' => $exception->getMessage(), 'code' => $exception->getCode(), 'file' => str_replace( \IPS\ROOT_PATH, '', $exception->getFile() ), 'line' => $exception->getLine(), 'backtrace' => str_replace( \IPS\ROOT_PATH, '', $exception->getTraceAsString() ) ) ); if ( $response->httpResponseCode == 410 ) { \IPS\Settings::i()->changeValues( array( 'diagnostics_reporting' => 0 ) ); } }

All uncaught exceptions are reported to IPS automatically (when opted in), right? Is it really too much to ask that when I report an exception, you check whether that exception is widespread? The problem here is not the changes that I made to this code (which were put in place to address other similar issues, although I don't know if they are still relevant). As far as I can tell, Google made a breaking change to their API to cause this. I'll add it to the list of modifications that I make to IPS files.

TypeError: Cannot access offset of type string on string (0) #0 /opt/forum/system/Login/Handler/OAuth2/Google.php(299): IPS\Login\Handler\OAuth2\_Google->_userData() #1 /opt/forum/applications/core/modules/front/system/settings.php(165): IPS\Login\Handler\OAuth2\_Google->userProfileName() #2 /opt/forum/applications/core/modules/front/system/settings.php(64): IPS\core\modules\front\system\_settings->_overview() #3 /opt/forum/system/Dispatcher/Controller.php(118): IPS\core\modules\front\system\_settings->manage() #4 /opt/forum/applications/core/modules/front/system/settings.php(49): IPS\Dispatcher\_Controller->execute() #5 /opt/forum/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\front\system\_settings->execute() #6 /opt/forum/index.php(13): IPS\_Dispatcher->run() #7 {main} I've not looked into why this is happening, but it seems to be happening fairly frequently. I'm on 4.7.0, but this code doesn't seem to have changed in 4.7.1.

Reported to me in https://linustechtips.com/topic/1443429-if-theres-a-username-behind-the-cursor-when-youre-reacting-to-a-post-the-hover-card-is-appended-to-the-bottom-page/ (there's a video there which illustrates the issue pretty well). To reproduce: Find a post that somebody else has reacted to Open the react menu, and position the cursor above the username of the member that has already reacted, eg on funny in Click to react to the post Have the request to ?do=showReactionsComment complete: After the reaction menu has closed, so that the hovercard starts getting triggered due to the hover event on the username Before the hovercard has finished loading The hovercard will appear at the bottom of the page rather than in the correct location under the cursor This happens because you take a reference to the hovered element when triggering the hovercard, but then when ?do=showReactionsComment completes the whole reactions block gets replaced, so the referenced element is no longer in the DOM. I'm not sure what the right solution is here, though it could probably be helped by checking that the element exists in the DOM when trying to position the hovercard and aborting if not.

Also had some members reporting today that the most recent posts were still not visible after the deletion had completed. It does look like the cached post count (used for computing the page count) was pretty far off: mysql> SELECT posts FROM forums_topics WHERE tid=901907; +--------+ | posts | +--------+ | 143021 | +--------+ mysql> SELECT COUNT(*) FROM forums_posts WHERE topic_id=901907 AND queued=0; +----------+ | COUNT(*) | +----------+ | 143048 | +----------+ I'm not sure what caused the discrepancy to be this big, but this looks like a pretty classic race condition. Resyncing the comment counts (which would have happened organically if anyone had replied in the past few hours) has fixed it, and it's probably not straight forward to reengineer to avoid this, but it does suck.

I do understand moving around pages, but there are clearly some optimizations that can be done to the elasticsearch utilisation because it should not need to reindex all 150k documents 10k times. That topic's db record also seems to be corrupt, but I need to look into that further (I think the posts field in the db is out of sync with the actual number of replies, but have not verified it).

I have a topic that had >150k posts. A member has requested that their account and posts be deleted, which includes about 10k posts in that topic (and 4k posts in other topics combined). That deletion has been running for the past 20 hours, maxing out the CPU on my server the whole time, and is about 71% complete. The massive topic is having issues where pages are disappearing and reappearing, I think due to consistency issues due to the rate of updates to that topic (although solving that without transactions might be hard), and submitting new posts is very sluggish. The CPU is mostly being consumed by elasticsearch, I think because each post results in every post in the topic being updated in the index. There must be a better way to do that, batching the updates by topic or something.

The symptom of this for regular status updates is that when you submit the status, it gets stuck on "Saving", despite having submitted successfully:

If you have something like <div data-controller="foo"> <div data-controller="bar"></div> </div> ips.controller.register("foo", { initialize: function() { ips.controller.cleanContentsOf(this.scope); } }); The controller on bar will be initialized on the dead element, and never cleaned up: ips.controller.register("bar", { initialize: function() { console.log(document.contains(this.scope[0])); // => false }, destroy: function() { console.log("destroyed"); // never called } }); This happens because ips.controller#_findControllers is called once to get all controllers to load, then the controllers are run one by one. If the foo controller is run first (and I'm not sure if that's guaranteed to be the case), cleanContentsOf will drop the bar element, but it won't run the destructor because the controller hasn't been initialized yet. When all of that logic has finished running, it then runs the bar controller, even though it is no longer applicable. Sure, you might say, but nobody would call cleanContentsOf synchronously during init, right? Yes, you do. Concretely, the problem this causes me is that the commentFeed of a status update exists twice, one in the document and one detatched. This means addToCommentFeed events end up getting processed by both, the detached one first, and the detached one ends up throwing an exception. There are a few different ways this could be fixed: Fix the double initialization of profiles. Seems straight forward enough, and that appears to be the only instance of this issue at the moment. Guard ips.controller#initControllerOnElem with node.contains(elem), to ensure that the node is still a child Run the destructor code from cleanContentsOf in a `setImmediate` block, to give the other controllers an opportunity to be initialized before getting cleaned up

Noticed this locally while testing out an unrelated thing, reproed here. Post a status update from your profile (or the create menu, or whatever) Refresh (open) your profile Status update has disappeared "See my activity" Status update isn't there, and there's no filter sidebar entry for status updates or replies I've not looked into why this is happening, other than that there is no entry in the system log (while not IN_DEV), and rebuilding the search index didn't resolve it (though it was also empty after rebuilding, so YMMV). I no longer use (stock IPS) status updates on my site, and the impression I got from the lack of support previously was that we were the primary user of them, so maybe nobody will notice?

The database changes related to the image scanner (adding core_files_temp.requires_moderation, core_attachments.attach_moderation_status, and core_image_scanner_logs) were added to the upgrade routine for 105013 (4.5.0 beta 1) rather than one of the 4.7 releases. This doesn't cause problems for most people because step 2 of the upgrade routine is to check the database schema, although this could cause problems in future if future upgrade steps act on this new table and someone is upgrading all the way though (and similar bugs in future could be more of a problem if they aren't just straight forward add queries). I ran into this because I replaced the upgrade wizard with a significantly (order of magnitude) faster CLI implementation, but that script had omitted the databaseCheck step.