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. :)
I roll with a pretty nice dedicated server for MLP Forums and my other sites. It's a very big step up from shared hosting, but as long as you're able to pay for it and are comfortable managing sysadmin tasks (or have someone capable running the server for you), you will not regret moving up.
I may be assuming a few things here, but a community large enough to require a dedicated server should be large enough to pay for it, too. If money is the main issue keeping you from upgrading your hosting, look at asking your members for donations, offering subscriptions, or even putting up ads. It only takes a few generous individuals to keep the site online for everyone else. :)
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.
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:
If a donation goal in IP.Nexus has been reached or surpassed, the button to donate towards it disappears (strangely, this does not appear to affect administrators; I'm working out whether that's a bug or not with IPS right now).
The only way around this is to raise the goal amount or remove it entirely. Raising the goal amount may not always be appropriate, and removing the goal amount also hides the counter showing how much has been donated, which can bring up accountability concerns when asking a community to raise money for a cause. But it's not uncommon for people to want to "overcontribute" to a cause (Kickstarter is a very strong example of this), and there's no way to accommodate that with Nexus while keeping the original goal amount visible - users like to know how much they overshoot it by!
I suggest either removing this behaviour, which would make it so that the only way to disallow donations to a goal is to remove it; or adding an option in the ACP to let admins configure whether they want contributions to be cut off once the goal is reached. The latter would be preferable, but the former would be an acceptable compromise if adding another option to the ACP presents an issue.
Docs are there: :smile:
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.
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.
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.
+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.
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.