Jump to content
You're invited! Join our 4.6 Live Event on ZOOM 6/24 ×

Community

Colonel_mortis

+Clients
  • Posts

    1,380
  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Colonel_mortis

  1. That isn't quite the issue that I was talking about above, but there are two sides to your issue - doing it your way means that if you don't actually click some of the notifications (for example, it's a notification about a like and you know what post it is, or it's a quote notification but you're already following the thread), they wouldn't be marked as read, which would be annoying. The current system isn't ideal either though, so the solution must be a middle ground somewhere in between. My original post was talking about changing when notifications are sent for status updates, rather than how notifications actually work.
  2. I use redis along with some custom plugins to move more things into redis (which reduced response times by >30% from what I remember) on a high traffic (10k peak online users, normally closer to 1-2k online at a time), and the mean server response time is ~100ms (median is <50ms). One thing that made a massive difference was removing the Who's Online block. Sure, it makes the site look good because lots of people are online, but it had a very significant impact on performance.
  3. Even if just the notification collapse feature was added, it would make a massive difference.
  4. Yes - go into email settings under System>Settings in ACP, and change the outgoing email address to whatever you like.
  5. If you delete everything in the datastore it will be regenerated automatically - it's just a cache.
  6. This will be fixed in 4.1.18, but if you want to fix it now I have detailed the fix in
  7. The follow system is very powerful, and generally gives users most of the options that they want. However, status update replies don't use that system, and instead have the following logic: If the status was posted by you, you want a notification (no way to opt out) If the status was posted on your profile, you want a notification (no way to opt out) If you have posted a comment on that status, even if it is hidden, you want a notification (no way to opt out aside from deleting the comment) Moreover, the comment notifications don't collapse together to form one notification when multiple people reply to the same status. That leads to situations like this: (from one of my members). This is absolutely ridiculous. Yes, members can turn off all status reply notifications, but that isn't the solution to the problem, because obviously that means that they will not get any notifications about status update replies at all. My proposed solution: Make status notifications collapse together (really simple to do - just replace $this with $this->item() on line 142 of \IPS\core\Statuses\Reply, and copy most of the logic from \IPS\core\extensions\core\Notifications\Content::parse_new_comment into \IPS\core\extensions\core\Notifications\Profile::parse_profile_reply) Make status updates implement the Followable interface, and make them work like normal content items. Obviously there isn't room for a full follow button on the status update, but a little feed icon would suffice - click it to follow or to open the follow dialog. You should still be autofollowed if the above conditions are met, but it needs to be possible to opt out of getting notifications. When following, I would prefer it if you left status comments as a separate setting, rather than being controlled by the followed content notification preferences.
  8. That error code occurs if the member tries to resent the validation email too soon after it was last sent. There should be an error message with it to that effect.
  9. Correct, only the settings in the full notification settings page affect all followed items.
  10. Because while you are protected against passive attackers in that case, you are not protected against an active attacker who has injected a script into the page to read credentials from the page when entered and send them back to the attacker. Also, doing it this way means that site operators can't bypass the warning by setting the form action to https, then overriding it in JS to actually sent to a HTTP origin. While that is pretty stupid, I suspect some site operators would do that to try and avoid the browser warning.
  11. That's not a Chrome bug, that is very intentional. Both Chrome beta (56) and Firefox beta (51) will be visibly insecure (rather than simply not visibly secure as they are now) if there are any password inputs on the page. It's not an interstitial page or anything like that, just a marker/message in the address bar. In firefox, it looks like this: while in Chrome where you currently have an (i) in the address bar it will say "Not Secure" (I can't seem to force it to show now using a pre-release build though). If you are not logged in, all pages contain a password field, because they have a login dropdown. Making the registration page load over https is a very good suggestion, but it is not the solution to your problem. The solution to your problem is to force the entire site to load over HTTPS. Switching from HTTP to HTTPS will not have a significant impact on your Google rankings in the short term, and in the long term it will boost them because sites loaded over HTTPS are ranked higher than those loaded over HTTP. There are no excuses left for not switching to HTTPS - it only benefits your site (potentially faster load times, extra features available to developers, better search engine optimisation, not to mention that it's actually secure).
  12. In the {template} template tags, it would help massively if you could specify the app except where there is a specific reason not to, so that the templates can be reused in other apps. The one that's bothering me specifically at the moment is on line 2 of core/html/front/system/settings.phtml, where you include the pageHeader without specifying that it needs to be in core. This means that, without requiring everyone who will use my app to modify that template to add the app in there, there is no way to reuse that template in my own app. The reason I want this is that I am adding a new item to the settings page (which is a painful experience btw), but I need the URLs to be handled by my own app rather than all in a settings hook, because I need a whole controller for it, and I have some extra authentication checks in execute. For now, can you please add that particular app specifier so that my app will work, and in future can you try to include them where possible. In future, it might make sense (though it would be a breaking change) to make the app default to app that the current template is from (so anything inside a template from core would be assumed to be in core), with maybe a special specifier like "@current" to use the current app that the user is viewing.
  13. Do you have javascript enabled? For some reason, the bar is only displayed when JS is enabled.
  14. Go into ACP->customization->languages, then click the globe "translate" button on the relevant row (probably "English (USA)"). In the search box, enter the keys (one at at time), and in the "English (USA)" textarea, enter the corrected version.
  15. You need to turn it on in the "Terms & privacy policy" settings in ACP.
  16. Edit the language and find notification__new_mention and notification__new_quote. At the end of each of those, add ": %s", so the mention becomes becomes "{!#[?:%s mentioned you in]} %s: %s".
  17. This was suggested to me by a user, and I thought it seemed like a good idea. If users were able to add polls to status updates, it would make status updates even more useful for just quickly gauging people's thoughts on a particular subject (particularly if it's very off topic).
  18. A while ago, but I'm not able to do anything with it at the moment because it's on a computer that I don't currently have access to. When I have some time, I will see whether I can obtain it from elsewhere or recreate it, but I don't have any time at the moment.
  19. A 4xx error would be correct, but 403 is not. The semantically correct code would be 400 (Bad Request) or 409 (Conflict). The article you linked has nothing to do with reporting warnings... That is about displaying errors on the page, not logging them to stderr (aka the apache error log) which is where it looks like that error message has come from. Logging warnings is fine (and generally encouraged). In the original post, it says "the call was successful" - I haven't tested it, but to me that means that the member was created, in which case a 200 or 201 response would be appropriate; if that only means that the request made it to the API dispatcher, then, as I said, a 4xx code is correct, but 403 is not the right choice in my opinion.
  20. Yes, I have (frequently enough in fact that some people have been copying my response from one topic to the next, to avoid me having to reply). https://linustechtips.com/main/topic/636640-please-stop-signing-me-out-on-desktop-when-i-sign-in-on-mobile/ https://linustechtips.com/main/topic/643184-change-active-sign-in-to-three/ https://linustechtips.com/main/topic/639648-increase-max-simultanious-client-count/ https://linustechtips.com/main/topic/657350-stay-logged-in-on-different-os-boots-same-pc/ None of them are super recent topics because I fixed it to work properly. It's probably not come up in a ticket because who would submit a ticket just because someone got logged out (because it is not at all obvious why you are being logged out), particularly when they can log back in and everything seems fine. Just because someone hasn't reported something, doesn't mean they aren't affected by it. I was very annoyed by this issue for quite a while before I actually got around to reporting it. Look at the responses to this thread for an example. And your example is not what I was talking about at all. I log into my iPhone on the 1st January I log into Chrome on my Windows desktop on the 3rd January I use my iPhone and Chrome Windows regularly, including on the 5th July, when I am still logged in On the 6th July, I decide to try Microsoft Edge, and log into the site there. I quickly get annoyed by the editor not working correctly on Edge, and switch back to Chrome Unfortunately, because I logged into Edge, I am now logged out of Chrome and my iPhone. I've already got annoyed at the site because of my editor issues in Edge, so I just give up and don't use the site again. As I said though, whether you fix it or not is irrelevant to me, since I have fixed it myself, and have a concerning feeling that I will end up fixing everything from now on. Not currently, because I think Lindy will just point people to that plugin rather than fixing this issue, but if things don't improve, I will publish it.
  21. Chrome on iOS is exactly the same as Safari on iOS in the backend, so it will behave the same. You should report this as a bug (by submitting a ticket), but the devs are unlikely to be able to fix it because it's probably an editor issue.
  22. No - in Chrome on Android, once the editor has loaded, it is focused so the keyboard appears and you can start typing, only one tap required.
  23. It works for me (Android 6.1, Chrome, Nexus 5), but only if the editor is empty (so stuff hasn't been inserted due to autosave).
  24. If you've not used them, yes. If you've been continually using them, then get logged out because you log into a new device, that is not OK. Whatever, it doesn't affect me, because I made a plugin to provide the behaviour that my users expect.
×
×
  • 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