Of course Pretty much all URL handling in IPS4 is handled by the \IPS\Http\Url class which is super-clever at figuring things like that out. The code to call the URL you specify is: $url = \IPS\Http\Url::external( $row['url'] )->setQueryString( 'version', $row['current'] );
$response = $url->request()->get()->decodeJson(); In applications/core/tasks/updatecheck.php
I had a ticket today where ModSecurity was triggering a block because of content it perceived as dangerous in the recentEmoticons cookie. While I have advised the customer to disable that rule, which has fixed the issue, it does seem the format we use for the recentEmoticons cookie is unusual and could probably be simplified to prevent something like this happening again. This is just a reminder to to look into that whenever we get a chance - since it's not actually a bug, we don't need to worry about it immediately.
\IPS\core\setup\upg_40000\Upgrade::step11() /* @note - If the content item class isn't present or the data hasn't been updated yet, this might not work - evaluate */
$content = $className::load( $report['exdat3'] ? $report['exdat2'] : $report['exdat1'] );
$insert['author'] = $content->mapped('author');
$insert['perm_id'] = $content->permId();
catch( \Exception $e )
The topics/posts tables haven't been renamed at this point so perm_id (and author) don't get set and the reports subsequently don't show. We have a couple of options, though since we are specifically only handling reports from our apps (reports for third party apps get deleted) - I would just replace the $className::load() call with database queries, and take into account that the the topics/posts tables won't have been renamed yet. Alternatively, we could move this to another part of the upgrader, or a background queue task after the upgrade is complete. Incidentally: there is also a note about records from Pages not being right, and in general when I tested this, converted reports seemed weird - I had a report where the content of the report was actually the content of the reported post, not what I entered when submitting the post, for example. We should test reports of everything (including comments) across all apps.
The possible scenarios are: Notification preference when someone replies Notification preference when someone mentions me Expected behaviour Current behaviour Email Email I get one email I get one email Email Inline ?? I get an email and an inline notification ?? I get an inline notification Email None I get one email I get nothing Inline Email ?? I get an email and an inline notification ?? I get an email Inline Inline I get one inline notification I get one inline notification Inline None I get one inline notification I get nothing Following with "none" option Email I get one email I get one email Following with "none" option Inline I get one inline notification I get one inline notification Following with "none" option None I get nothing I get nothing Not following Email I get one email I get one email Not following Inline I get one inline notification I get one inline notification Not following None I get nothing I get nothing This is actually a simplified table. It is possible to have separate preferences for quoting and mentioning and of course you can be both mentioned and quoted in a post in a topic you're following, and the same issue applies there. This will be tricky, but I have some ideas about how to go about this. We're going to "Future" this for now because we're not going to make such substantial adjustments in an RC, but will fix it in 4.0.1.