Feld0

Members
  • Content count

    439
  • Joined

  • Last visited

About Feld0

  • Rank
    Member

Recent Profile Visitors

8,594 profile views
  1. We found that when a user is banned from a topic, if they were following it, they still receive notifications from it. Could this behaviour be changed?
  2. This is possible, but note that all changes to the individual club forums (the sections in them, permissions, group members) will need to be done by a forum administrator, as there's no way to limit the control of this further than the ability to manage all forums, the ability to manage all groups, or the ability to manage all permission sets. IP.Board does not have a concept of "section admins" who can manage a specific area but not the rest of the site. For what it's worth, this isn't a feature I've seen in any of the other major forum packages, either. If your administrative staff are active, it's workable. :)
  3. It uses a lot of storage, but from personal experience, I think it's well worth it. If you're running a large site with loads of activity, you're probably on dedicated hardware anyway, for which storage is pretty cheap. :) I'd love to see this in the core, but considering the server requirements it comes with, it might qualify as a "niche" feature. That said, forums are all about content, and images are a huge part of that. One might as well say that attachments are "niche" because free file hosting services exist that someone could easily link to instead, but attachments last as long as the forum does.
  4. A member brought an issue to my attention today which allows users to easily bypass their group's signature image size restrictions. When a member sets up their signature, IP.Board will check the dimensions of any embedded images to ensure they fit within the restrictions. However, if an image is embedded into a signature and is subsequently replaced by a larger one at the same URL which breaks the size restrictions, IP.Board will not react to it in any way, and will happily let the new image stay. Re-checking the image on every pageview would create some pretty bad resource issues, but... fortunately, there's a way to work around it. :smile: Avatars used to be prone to the same issue, but they were neatly fixed when the option for a "remote" avatar was modified to download the remote image to local storage after a one-time size check, where users can't touch it anymore. The same could be done for signatures - copy images to local storage after checking they fit the restrictions. Even better would be an option to upload signature images to the forum directly, if they're going to be copied to the server anyway. :smile:
  5. Docs are there: :smile: http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/how-to-interact-with-purchases-r113 http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/itemsphp-extension-file-r134 http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/actionsphp-extension-file-r133 And I believe IP.Downloads makes use of these same API's, so a source dive there might reveal some hints. Think you might have an ETA on the next update? If it's still a bit far out, I might take a crack at building a Nexus gateway myself.
  6. Hi Mike, Any update on the implementation of the IP.Nexus gateway? Having completely different payment systems for donations and the store on my site is confusing to some of my users. The Nexus gateway would make things a lot more consistent for them, and give them alternatives to PayPal as well.
  7. Awesome! Thanks, Adriano. :) But it's only for topics - any chance you could add notifications for approved posts to the hook as well (or perhaps in a new hook)? That would be really useful for forums where individual replies to topics need to be approved.
  8. +1. This suggestion came up in one of my own communities, and it would be great to see it implemented.
  9. +1. The ability to whitelist specific domains for dofollowing would be excellent for me, as I'm building a larger network of websites for my members, and expect an awful lot of links to the rest of the network to pop onto the forums in due time.
  10. I'm developing a new application using Foundation. Originally used Bootstrap because that's the framework everyone talks about, but when I discovered Foundation, the better grid (every column becomes its own twelve-column grid) won me over, so I switched. That, and I like that it's less opinionated about how your site should visually look, since my app needs to have a distinct design for the users' enjoyment anyway.
  11. Looks like it. :O Thanks for the link, Marcher - I was unaware that the fix existed. Down to just 8 queries now. :D
  12. Thirded. :smile: I understand why you choose PHP 5.3 as your lowest supported PHP version. 5.4 is already supported by cPanel, however, and it is only going to spread in the time you take to release IP.Suite 4.0. I just hope it doesn't hamper your development too much, as 5.4's new playthings are excellent. Any chance you might bump up your minimum required version at some point during the 4.0 lifecycle, or can we count on PHP 5.3 remaining the baseline until 5.x?
  13. In its current design, IP.Board runs the following query once for every single member in the Currently Online list (replacing the "3479" at the end with the ID of each active member, of course): SELECT m.*, m.member_id as my_member_id,p.*,pp.*,g.*,ccb.cache_content FROM members m LEFT JOIN pfields_content p ON ( p.member_id=m.member_id ) LEFT JOIN profile_portal pp ON ( pp.pp_member_id=m.member_id ) LEFT JOIN groups g ON ( g.g_id=m.member_group_id ) LEFT JOIN content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id ) WHERE m.member_id=3479 It would be sensible to refactor the feature to use eager loading to grab all the members in a single query, no matter how many of them there are: SELECT m.*, m.member_id as my_member_id,p.*,pp.*,g.*,ccb.cache_content FROM members m LEFT JOIN pfields_content p ON ( p.member_id=m.member_id ) LEFT JOIN profile_portal pp ON ( pp.pp_member_id=m.member_id ) LEFT JOIN groups g ON ( g.g_id=m.member_group_id ) LEFT JOIN content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id ) WHERE m.member_id IN (3479, 5654, 4543, 6576, 8695, ...) The online list alone is responsible for adding well over a hundred queries to our index. Disabling it made it come up a good half-second faster. All these queries add a great deal more traffic and overhead to the database connection than there needs to be.
  14. Here's my guest permission set: It appears to be correctly configured for me; however, the issues in my site are accessible by direct URL (I can PM you with an example if needed).
  15. It appears that TracDown's permissions aren't programmed correctly. Most of our bug tracker is configured to be viewable only to specific groups, but every issue is visible to guests. The category pages are not, as intended, but the issues they contain are accessible by direct URL and made it into Google's index.