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



  • Posts

  • Joined

  • Last visited

  • Days Won


 Content Type 



IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog



Everything posted by Colonel_mortis

  1. I don't say this much about this software, but the new ACP onboarding wizard is great. It has almost everything you need to bootstrap the community. However, it is missing settings to configure the ingoing and outgoing email addresses, and (less critically) the SMTP/etc settings, which means that emails default to being sent from the admin user's address (and therefore often don't get delivered).
  2. Why is "Logging into the front-end from a new device" so far away from "Logging into the front-end from a known device"? They should really be next to each other IMO (also, changing email/password/2fa settings would also make sense to be together). This is on a fresh install.
  3. XRegExp is 135KB when minified as part of root_library.js (that whole bundle is only 383KB, so it's a significant chunk), but it's only used in two places: In ipsautolink/plugin.js, it's just used to evaluate a native JS regex, which I believe is totally unnecessary (use this.urlRegex.test(text) instead!) In ips.search.results.js, where it's just used to replace using a native JS regex (use $(this).text().replace(new RegExp(...), '...') instead, as you do for each subsequent replacement in that chain) (while you're at it, why does that code replace with HTML, HTML escape everything, then selectively unescape the content you just added?!) Removing those two places that don't, to my understanding, utilise the library in any meaningful way would allow you to slim down the site by a not-insignificant amount, and make certain people happy.
  4. Currently, there are no config options when following a member, so it's just binary following/not following. This means that you have to opt into all or nothing for being notified about new content posted by your followees - there's no way to follow a member for status updates only. It would make sense if the follow dialog when following a member let you choose between "status updates only" and "all content". Implementing this would be pretty straight forward I believe - just update the special casing of following members in \IPS\core\front\modules\system\notifications::follow to add another option for status updates only, then update the follow types checked when sending status notifications to include that type. Unfortunately the aforementioned follow method is basically unhookable because it constructs and uses the form in the same method without exposing it to hooks.
  5. I deleted a plugin's hook in the dev center, but it wasn't removed from hooks.json. It was caught by CI for me, but it's obviously not great.
  6. Needing an "Other Settings" panel in Account Settings is a bit of a red flag that maybe all of those settings-related things should be unified to make them more coherent. I see no reason for ignored users to be separate Notification settings has a slightly more complex UI, but I can't see any blockers to bringing that UI into settings, and doing so would bring it inline with other sites (GitHub, Stack Overflow, reddit, and iirc also facebook etc) Profile settings is more arguable because having it as a dialog when viewing your own profile is good, but the profile settings is also where I think the most benefit can be gained - users expect their signature settings to be in their profile, because that's where their other public-facing things are configured, and they expect to be able to change other things by going to settings. This probably needs more consideration of the tradeoffs, and maybe finding a neat solution, but my feeling at the moment is that unifying them would make sense.
  7. Similar to Stack Overflow, it would be neat if the checkForNewReplies behaviour extended to checking for edits to existing posts, probably as a button per post rather than in the existing toast.
  8. I noticed that in a few places you're hacking around support for lower case (http2) headers, and there are a bunch of places where you don't handle them correctly. Is there a reason that you're not lowercasing all headers when storing the headers (and also storing the originals for back compat)? eg there are a bunch of places where you test for $response->httpHeaders['Location'] || $response->httpHeaders['location'], but if you standardise them then you can just test one. You already standardise location, but you may as well do it for everything then deprecate the upper case ones.
  9. 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.
  10. Version 1.0.1


    Without this plugin, when you click a popup notification, either at the bottom of the page (toasts) or in the OS (web notifications), you are taken to that item but the count on the notification icon is not updated and the notification remains marked as unread. This plugin fixes that behaviour, so clicking the popup notification will mark that notification as read - it will no longer show up as bold in the notification list and the notification count will be decremented by one. Security has been taken into account, so members cannot use this to mark other members' notifications as read. This plugin doesn't change any other behaviour.
  11. I may have misunderstood what you mean by this, but I can't seem to find any way to install a plugin from the files without the XML, IN_DEV or not. Writing the hook data to disk is great though, and if nothing else the XML file can at least now be reconstructed.
  12. I want to check my code into git, and be able to get started on a new install fairly easily by just cloning it. This lends itself well to collaborative environments, being able to easily recover from scrapping and restarting development environment, and potentially even CI workflows. I also currently deploy my code using git. For apps, it's great. I just clone my repo, click an install button in ACP, and I'm good to go. For plugins though, it really sucks: Hook information isn't stored in a file anywhere, so in order to check in enough information to reinstall the plugin I would need to download the xml, copy it back to my plugin dir, then commit that too Then I get those annoying uncaught exception handler blocks added in my dev environment For that reason, plugins can only be installed through the "upload xml" workflow, so installing a dev version means installing the xml then finding it in disk and adding the dev files separately Hook class names are install-specific, so once I get it installed in a new environment I end up with a bunch of git changes - this makes it impossible to collaborate with them Plugin names are case insensitive and get lower-cased when xmled, which looks ugly when you've installed a camel-cased plugin. There's also no option to make them snake- or kebab-cased because of the arbitrary alphanumeric restriction For these reasons I've been trying to centralise my plugins into apps, but that loses the flexibility of having small plugins that just do what they say on the tin, without needing to worry about a place for a settings UI for one or two options. That solution is obviously untenable for plugins that aren't just being developed for a single site though. If you implemented these fairly simple changes (hooks.json file, install from disk, custom names for hook classes, retain case and allow -_ in plugin names), I would be much happier when developing small changes like this. I think all of these things can be implemented in a backwards-compatible way (for hooks.json, if not present fall back to creating it based on the contents of the DB), so I can dream that my complaints haven't missed the 4.5 boat.
  13. If a user posts a poll and sets it not to display the names of the people who voted for each option, members don't get warned that their vote will be public and they may wish to share their opinion anonymously. However, the author of the poll can just edit the poll to set it to public, and see the names and choices of everyone who has already voted. This defeats the point of having private polls. Either it shouldn't be possible to change a poll from private to public, or votes from when it was private should be anonymised.
  14. It would actually be super easy to implement - they just need to remove the check for author != loggedIn()->member_id in checkForNewReplies (just removing part of a single line). The only other consequence of doing this is that you'll get "1 new reply" toasts for your own replies if you have it open in multiple tabs/browsers, but I think that isn't a bad thing.
  15. It would be great if there was a user option to only receive email notifications when they're offline, or to get a summary email of the notifications that they've missed if they don't visit the site for some period of time (as Stack Overflow does). There's no point getting email notifications when you're actively browsing the site, but equally if you're only an infrequent visitor you don't want to miss any replies to things that you're interested in or that you posted, and something like this would strike that balance (while also helping to boost retention in a user-friendly way).
  16. At the moment if there is a video embedded in the editor, it can be difficult to remove because clicking it just controls the video. If it was a widget and had a grab handle, it would be a bit easier to control.
  17. My furl.json entry is "status_view": { "friendly": "status/{#id}", "real": "app=statusupdates&module=status&controller=view", "verify": "\\IPS\\statusupdates\\Status", "seoPagination": true } but this causes a redirect loop when trying to access /status/1/page/2/ because it doesn't remove the page url correctly when normalising it to check that it matches the canonical version - normally the page part is matched in the {?} seo title variable when finding the furl to normalise with, but there isn't one available here. There must already be logic somewhere which copes with page path params because it does identify the furl template correctly in most places, just not when finding the template to normalise for equality. I have worked around it by adding "alias": "status/{#id}/{!}", to catch the paginated version, but this isn't ideal.
  18. I usually complain that most of your new features have great concepts, but just don't get delivered properly and end up not being useful. There is of course still plenty of time, but I have been very pleasantly surprised by how well implemented this looks, and I'm actually looking forward to rolling this out on my site! Thank you, and please keep it up!
  19. I don't know what you've come up with, so maybe it is legitimately irreversible (a random value stored in a cookie would probably be good). But in the world of GDPR, md5(member_id) (or anything else that I could easily reverse with an SQL query) doesn't go far enough to be described as anonymised, and I would be very cautious of advertising it as such.
  20. I don't disagree, and I think it makes sense. However, I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead. Even if you have keep-alive disabled (as ips did for a while, although they may have changed that now), the dns lookup will always have been cached and if you are running an up to date version of openssl and nginx/apache you can get 0- or 1-rtt tls session resumption, so there should only be 1-2 round trips of overhead. Resending the cookies is still a reasonable concern, but the others are not.
  21. If you're using the Rules app, you need to update to the latest version to fix this issue
  22. Not all of my members want to receive new device emails - some people regularly log into different devices or are browsing at work and don't want to leave cookies behind. I do want staff members to receive new device emails, and currently there is no way to have it both ways. I propose that the new device email setting should be 3- or 4-way configurable – on for everyone, default on but customisable, default off but customisable, and off for everyone. The setting would fit nicely on the "Account Security" page (2FA) of account settings. Alternatively, at least make it a per-group setting. It would also be nice to get a similar email for ACP logins, perhaps using the same device tracking as the front end to avoid sending too many emails.
  23. I've not read through the whole topic in detail. However, for what it's worth, enabling X-XSS-Protection (XXP) breaks embeds in Safari under certain circumstances. Also, XXP has absolutely nothing to do with ddos attacks, it is just a rudimentary safeguard against reflected XSS attacks. Of the handful of XSS attacks that I can recall finding in IPS, only one could be blocked by XXP (and as it happens, it was on a page where XXP was enabled and the attack was blocked in the browser which support it).
  24. All activity currently checks for updates automatically, but only inserts them when you click the button. It would be nice, as suggested by one of my members, to add the option of automatically showing the new posts too. It adds no extra server load, because the posts are already loaded into the browser during the background poll, not when then click show. This could get annoying if the user is scrolled below the top and there is no handling of scrolling the viewport to match where they were looking, but this can be solved by making it an option, or by implementing viewport scrolling so the posts are inserted above but the browser is scrolled accordingly so they don't notice.
  25. Downloading the image was the thing I originally posted in the OP... But glad to hear that you're working on it.
  • 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