Jump to content

Community

Colonel_mortis

+Clients
  • Posts

    1,361
  • Joined

  • Last visited

  • Days Won

    4

Reputation Activity

  1. Agree
    Colonel_mortis got a reaction from ptprog in Embeds should also redirect when the topic is merged   
    When topics are merged, the view (manage) requests are redirected, but not any other controller methods, including not embeds. The redirects are really useful, but given that most links are actually in the form of embeds there's a significant gap there.
    There's also a lot of room for improvement on stopping people from destructively merging the wrong way on big topics (followers don't get ported across, and are irrecoverably deleted, maybe some other things too). The first post in the topic will always be the oldest, regardless of which was kept, and in almost every case I can think of, that means I would want to keep that post's title and therefore URL as well.
  2. Agree
    Colonel_mortis got a reaction from CoffeeCake in Embeds should also redirect when the topic is merged   
    When topics are merged, the view (manage) requests are redirected, but not any other controller methods, including not embeds. The redirects are really useful, but given that most links are actually in the form of embeds there's a significant gap there.
    There's also a lot of room for improvement on stopping people from destructively merging the wrong way on big topics (followers don't get ported across, and are irrecoverably deleted, maybe some other things too). The first post in the topic will always be the oldest, regardless of which was kept, and in almost every case I can think of, that means I would want to keep that post's title and therefore URL as well.
  3. Agree
    Colonel_mortis got a reaction from Mr 13 in IPS spam service is harmful   
    I run a large site, so I have a lot of legitimate members and receive a fairly significant number of spammers. I turned it off (but continued to collect members' spam scores) several months ago, due to the volume of requests by legitimate people who were being caught by the spam filter. I've run some statistics based on registrations over the past month, comparing whether they have been flagged as spammer (which is very closely correlated with whether they were actually a spammer (this may not be true - see my post later in the topic)) and the code that the IPS spam service gave. The results are:
    +-------+------+----------+ | FASed | code | count | +-------+------+----------+ | 0 | 0 | 77 | | 0 | 1 | 5657 | | 0 | 2 | 3 | | 0 | 3 | 5 | | 0 | 4 | 147 | | 0 | null | 233 | | 1 | 0 | 3 | | 1 | 1 | 616 | | 1 | 2 | 13 | | 1 | 3 | 75 | | 1 | 4 | 155 | | 1 | null | 2 | +-------+------+----------+ Breaking this down:
    12% of registrations are spammers 6% of registrations receive a spam score > 1 4% of registrations receive a spam score of 4 So far, these numbers don't seem unreasonable. However,
    If someone receives a spam score of 4 ("user is a known spammer"), they have 51% chance of actually being a spammer A precision of 51% is totally useless.
    If someone is actually a spammer, they have a 28% chance of receiving a spam score > 1. That's a pretty shoddy recall too.
    If I set my site to reject members with a spam score of 4, I will lose ~150 members to the spam filter each month; even if I use 2 as the threshold instead it will still only reduce spam by 28%. That's not an OK trade-off to me.
    You may say that the answer to this is to set accounts to require admin validation instead when caught by the spam filter, and that's not unreasonable. However, I'm not logged into ACP every day, so I suspect this would result in the loss of a large portion of the potential registrations who will just go and ask their question on a different forum because they didn't want to wait. Furthermore, it's often not possible to tell whether the account is legitimate just based on the registration info, so that 28% hit rate is going to drop quite a lot more.
    I appreciate that catching spam is a very hard problem. However, I believe these number demonstrate that the current system is not fit for purpose, at least with the level of confidence that you currently assign to it ("member is a known spammer" in the config page is a long way from the truth, and "certain spammer" from your marketing materials is an outright lie).
  4. Like
    Colonel_mortis got a reaction from Jordan Invision in Option to turn off Login Notifications at user level.   
    I had a few complaints about it from my members too, and I ended up fixing it by changing the logic for sending a new notification to not send it if it's from an IP that they have used previously (except moderators and admins, which I retain the old behaviour). Since making that change, I haven't had any complaints from members.
    if ( \IPS\Settings::i()->new_device_email && ($member->isAdmin() || $member->modPermission() || \IPS\Db::i()->select('count(*)', 'core_members_known_ip_addresses', ['member_id=? AND ip_address=?', $member->member_id, \IPS\Request::i()->ipAddress()] )->first() === 0) )  
  5. Like
    Colonel_mortis got a reaction from CoffeeCake in Option to turn off Login Notifications at user level.   
    I had a few complaints about it from my members too, and I ended up fixing it by changing the logic for sending a new notification to not send it if it's from an IP that they have used previously (except moderators and admins, which I retain the old behaviour). Since making that change, I haven't had any complaints from members.
    if ( \IPS\Settings::i()->new_device_email && ($member->isAdmin() || $member->modPermission() || \IPS\Db::i()->select('count(*)', 'core_members_known_ip_addresses', ['member_id=? AND ip_address=?', $member->member_id, \IPS\Request::i()->ipAddress()] )->first() === 0) )  
  6. Like
    Colonel_mortis got a reaction from Matt in Option to turn off Login Notifications at user level.   
    I had a few complaints about it from my members too, and I ended up fixing it by changing the logic for sending a new notification to not send it if it's from an IP that they have used previously (except moderators and admins, which I retain the old behaviour). Since making that change, I haven't had any complaints from members.
    if ( \IPS\Settings::i()->new_device_email && ($member->isAdmin() || $member->modPermission() || \IPS\Db::i()->select('count(*)', 'core_members_known_ip_addresses', ['member_id=? AND ip_address=?', $member->member_id, \IPS\Request::i()->ipAddress()] )->first() === 0) )  
  7. Like
    Colonel_mortis got a reaction from OptimusBain in IPS spam service is harmful   
    I run a large site, so I have a lot of legitimate members and receive a fairly significant number of spammers. I turned it off (but continued to collect members' spam scores) several months ago, due to the volume of requests by legitimate people who were being caught by the spam filter. I've run some statistics based on registrations over the past month, comparing whether they have been flagged as spammer (which is very closely correlated with whether they were actually a spammer (this may not be true - see my post later in the topic)) and the code that the IPS spam service gave. The results are:
    +-------+------+----------+ | FASed | code | count | +-------+------+----------+ | 0 | 0 | 77 | | 0 | 1 | 5657 | | 0 | 2 | 3 | | 0 | 3 | 5 | | 0 | 4 | 147 | | 0 | null | 233 | | 1 | 0 | 3 | | 1 | 1 | 616 | | 1 | 2 | 13 | | 1 | 3 | 75 | | 1 | 4 | 155 | | 1 | null | 2 | +-------+------+----------+ Breaking this down:
    12% of registrations are spammers 6% of registrations receive a spam score > 1 4% of registrations receive a spam score of 4 So far, these numbers don't seem unreasonable. However,
    If someone receives a spam score of 4 ("user is a known spammer"), they have 51% chance of actually being a spammer A precision of 51% is totally useless.
    If someone is actually a spammer, they have a 28% chance of receiving a spam score > 1. That's a pretty shoddy recall too.
    If I set my site to reject members with a spam score of 4, I will lose ~150 members to the spam filter each month; even if I use 2 as the threshold instead it will still only reduce spam by 28%. That's not an OK trade-off to me.
    You may say that the answer to this is to set accounts to require admin validation instead when caught by the spam filter, and that's not unreasonable. However, I'm not logged into ACP every day, so I suspect this would result in the loss of a large portion of the potential registrations who will just go and ask their question on a different forum because they didn't want to wait. Furthermore, it's often not possible to tell whether the account is legitimate just based on the registration info, so that 28% hit rate is going to drop quite a lot more.
    I appreciate that catching spam is a very hard problem. However, I believe these number demonstrate that the current system is not fit for purpose, at least with the level of confidence that you currently assign to it ("member is a known spammer" in the config page is a long way from the truth, and "certain spammer" from your marketing materials is an outright lie).
  8. Like
    Colonel_mortis got a reaction from OptimusBain in Manually added quotes should be included when quoting a post   
    If I have a manually added quote (ie a quote added using the quote button rather than by quoting another post), it is often a relevant part of the actual post (especially when it's in the first post in a topic), so it would make sense for those quotes to remain as nested quotes when that post is quoted (especially now long quotes are truncated). It wouldn't be too hard to achieve - just look for the attribution attributes on the quote before stripping it.
  9. Like
    Colonel_mortis got a reaction from Jordan Invision in Manually added quotes should be included when quoting a post   
    Exactly
     
    Yeah, some sort of styling difference between the quote types might make sense. I think I'd want something that stands out slightly more than that, such as by adding a left border, such as stack overflow:

  10. Haha
    Colonel_mortis got a reaction from Nathan Explosion in Manually added quotes should be included when quoting a post   
    I cheated, it doesn't do that by default.
  11. Thanks
    Colonel_mortis got a reaction from CoffeeCake in Items without containers don't support some features   
    This was also brought up in the following topic, but there was no answer from IPS there and I do believe it is solvable:
    In almost all places where Item::$containerNodeClass is used, there is an isset test before accessing it and graceful fallback when it's not present. However, that check is missing in a few places that affect following and tagging.
    For followable:
    \IPS\core\Followed\Table:99 - this join should actually be within the preceding if statement (since I believe it only makes sense when permissions are used) core/front/table/tables/rows.phtml:104 - the if should also check that method_exists, as it the pattern everywhere else (but this isn't insurmountable because it will use the table desc if available) core/front/tables/manageFollowRow.phtml:43 - as above \IPS\Content\Search\Elastic\Query:467~487 - (what's going on with that code structure?) you should only honour $includeContainers if isset($class::$containerNodeClass) \IPS\Content\Search\Mysql\Query:416~436 - as above for tags:
    \IPS\Content\Item:7684 - should also check isset($containerClass) \IPS\Content\Item:7727 - I think this should be a constant if containerClass is empty, but I'm not sure how it's used so I may be wrong here. To my eye, all those changes should be feasible, and would make it much easier to avoid nasty hacks involving pseudo-nodes. nb. I searched for these occurences using intellij, so there may be places that I missed because the static analysis wasn't powerful enough.
  12. Thanks
    Colonel_mortis got a reaction from CoffeeCake in Memory + behaviour leak when destroying CKEditor instances   
    When an ips.ui.editor instance is destroyed, you are following the answer from a Stack Overflow question and trying to manually destroy the CKE instance. Unfortunately, that manual destruction is not sufficient, and is leaving references to the editor and behaviour. Take ipsautosave as an example (and maybe the only example, I've not looked further) - it maintains a reference to `editor`, and runs autosave on it every two seconds. It attaches a `destroy` event handler, which would be triggered when calling editor.destroy(), to cancel the timeout and therefore release the editor reference, but because you never trigger the destroy event it's not sufficient. (I'm noticing this because I am trying to use multiple editors on a page with the same autosave key, but it's still a problem without that.) It looks like there are a few other references that destroy manually cleans up, so there are presumably a few other things that are leaked too.
    At a minimum, you should be doing `editor.fire("destroy")` to trigger all of that cleanup code, but ideally you should find the things that prevent editor.destroy() from working and fix those in CKE. As a middle ground, maybe you could do `try { editor.destroy(); } catch (e) { /* existing manual best effort */ }`.
  13. Like
    Colonel_mortis got a reaction from sobrenome in PHP 8.0 is here   
    Ugh it's the patch from ticket #70349 again. Looking at the patch again it doesn't seem to break either of the things that I've run into, so it seems I somehow managed to misapply it (my linux git doesn't like that patch file at all, it's missing the a/ and b/ prefixes). Apologies for wasting your time twice for that.
  14. Like
    Colonel_mortis got a reaction from sobrenome in PHP 8.0 is here   
    If you've not discovered it yet, I'm also getting
    TypeError: array_merge(): Argument #2 must be of type array, null given (0) in \IPS\forums\Forum::formatFormValues:1120 (neither $whereString nor $whereParams are defined as far as I and my IDE can tell, and $where seems to be unused).
     
    Also there are a few places where you have
    new\DateInterval( which seems to now be lexed as calling the function DateInterval in the namespace new, rather than applying the new operator to the root-namespace class DateInterval [1].
  15. Thanks
    Colonel_mortis got a reaction from sobrenome in PHP 8.0 is here   
    I've only been playing around with it IN_DEV so far, but I'm not noticing a difference. I don't think the JIT compiler is expected to make too much difference for web apps, but I would love to be wrong there.
  16. Like
    Colonel_mortis got a reaction from sobrenome in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  17. Like
    Colonel_mortis got a reaction from LaCollision in Items without containers don't support some features   
    This was also brought up in the following topic, but there was no answer from IPS there and I do believe it is solvable:
    In almost all places where Item::$containerNodeClass is used, there is an isset test before accessing it and graceful fallback when it's not present. However, that check is missing in a few places that affect following and tagging.
    For followable:
    \IPS\core\Followed\Table:99 - this join should actually be within the preceding if statement (since I believe it only makes sense when permissions are used) core/front/table/tables/rows.phtml:104 - the if should also check that method_exists, as it the pattern everywhere else (but this isn't insurmountable because it will use the table desc if available) core/front/tables/manageFollowRow.phtml:43 - as above \IPS\Content\Search\Elastic\Query:467~487 - (what's going on with that code structure?) you should only honour $includeContainers if isset($class::$containerNodeClass) \IPS\Content\Search\Mysql\Query:416~436 - as above for tags:
    \IPS\Content\Item:7684 - should also check isset($containerClass) \IPS\Content\Item:7727 - I think this should be a constant if containerClass is empty, but I'm not sure how it's used so I may be wrong here. To my eye, all those changes should be feasible, and would make it much easier to avoid nasty hacks involving pseudo-nodes. nb. I searched for these occurences using intellij, so there may be places that I missed because the static analysis wasn't powerful enough.
  18. Like
    Colonel_mortis got a reaction from Open Dev Community in Marketplace onboarding flow   
    The marketplace onboarding flow is quite annoying when there are lots of non-marketplace apps/plugins to have to select "not in the marketplace" for each one, and to me it was non-obvious that I needed to do that. Ideally, I would like to be able to click continue without having clicked "not in the marketplace" in each one.
  19. Thanks
    Colonel_mortis got a reaction from Octavian Dima in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  20. Thanks
    Colonel_mortis got a reaction from CoffeeCake in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  21. Like
    Colonel_mortis got a reaction from abobader in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  22. Like
    Colonel_mortis got a reaction from AlexJ in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  23. Like
    Colonel_mortis got a reaction from aXenDev in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  24. Like
    Colonel_mortis got a reaction from DawPi in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
  25. Thanks
    Colonel_mortis got a reaction from Chris027 in PHP 8.0 is here   
    PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
    There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy