Jump to content

Colonel_mortis

Clients
  • Posts

    1,452
  • Joined

  • Last visited

  • Days Won

    5

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Colonel_mortis

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. Agreed, especially as complying with user requests to delete accounts is required for compliance with the GDPR.
  10. Actually, never mind, turns out I was looking at the wrong column, and it is taking an insignificant amount of time. Sorry about that.
  11. rules_rules doesn't have any indexes, and is queried a few times with where parameters.
  12. If dev mode is enabled, the app breaks the site because an E_NOTICE is emitted by line 435 of your ipsPatternsActiveRecord hook (__set) when you try to get an undefined index from _data (because it's being set for the first time). You should probably add an array_key_exists or isset check there to prevent that error. Also, can you add some indexes to the Rules tables? The queries are currently fairly slow, and adding an index should help quite a lot.
  13. Editing an administrative profile field using the edit profile form on a member's profile (front not ACP) doesn't save.
×
×
  • Create New...