CoffeeCake

You can see the IP addresses you've banned, if any, from Admin CP > Members > Ban Settings > IP Addresses, if the issue is Invision specific. However, depending on your configuration (i.e. if you are using something like Cloudflare), or if your host provides options for you to restrict traffic to your web server, there may be other places where the traffic is restricted. Issues registering could be other problems, however, as well. Does the individual get a specific error message they could share with you? It may also be the IPS Spam Defense service if you have that enabled. See this guide for details: If that's the case, you can modify your community settings to let flagged accounts register and then manually unban the user, assuming you have ban member ticked, or whitelist the e-mail address following the steps here: Good luck!

♟️

Yes, that would be good. Who are these developers that have made such a plugin?

I'll chime in with adding link validation to profile fields as well. The ability to moderate links in profile fields (signatures, text boxes, etc.) would be a wonderful addition.

You could setup a page rule to disable cache on the RSS feed (assuming that's what's breaking). Not sure if you need a subscription to use page rules though. The free plan includes three page rules. Set cache level to bypass.

Sure, that might be a consequence. Just throwing out ideas off the cuff, but consider having a developer indicate something like a service-level agreement at the outset at the time of purchase. "This is $10, but no guarantees it will continue to work in the future" vs. "with ongoing support and maintenance for the 4.x series" And I would think that the trigger to have a resource opened up to the community would be after some inactivity or by the developer communicating their intentions to IPS. Maybe Adriano wins the lottery, moves to a private island, and lives this rest of his days sipping from coconuts. He decides that he'll sell 10 of his extensions to Kevin, 20 of them to Scott, 40 of them to Veronica, etc. He updates his extensions to indicate the new account supporting them. Or maybe Adriano can't be bothered by all that, and drops off the face of the earth, jetsetting around the globe with supermodels and the uber rich, and doesn't log into his account or make any updates or respond to any support requests for a year. In that last case, the hypothetical clause kicks in and IPS says "Hey, this stuff appears to be unsupported. We've reached out to the developer via e-mail three times, called him once, and no response. In 30 days, we'll make it available at your own risk as open source." I may just be suffering from too much cabin fever, but I think it's a novel idea.

Completely understand. You're a busy person and you can't easily sell this extension. It causes support headaches for the folks that misconfigure something for IPS. It's not worth the time or hassle--who wouldn't understand that? However, it seems that some communities rely on it and want to continue iterating on your good work. It seems that this would be a good candidate to open up as open source project that others, who have an interest in maintaining this project, can fork or contribute to. We don't use this, yet I think it's important to encourage an ecosystem where in those infrequent circumstances that an extension gets to this place, there's a mechanism to move forward with non-core items for those for whom continued development and support do make sense.

I was speaking on contractual terms. "As a condition of using the marketplace, developer agrees insert terms here." This is entirely possible. I understand that it's all at your own risk only now, yet I think there's an opportunity for improvement. This would both encourage developers to make arrangements external to the marketplace (turning over a resource to another developer, for example) to continue a revenue stream, and encourage communities to purchase extensions knowing that at the very least, if someone gets hit by a bus, there are provisions in place to continue a developer's good work.

In fact, this should be a precondition of selling on the IPS marketplace, I think. If a person can no longer support an extension, then IPS should mark the extension as no longer supported. Keep it available for download, yet note that the developer is no longer supporting maintenance of the project and open it up for the sites that have come to rely upon it. It's dangerous for a new community to come along and install (or worse yet, purchase) things that are essentially abandonware.

Tracking changes to any fields that appear on a member's profile and signature. For example, the fields at Admin CP > Members > Profile.

Perhaps it's time to open source the code and throw it up on Github for others to help maintain going forward?

Might be a nice (configuration option?) to have <author>communityemail@example.com (Display Name)</author> Or, even better, extend it with a namespace declaration that allows for something like a Contributor field that doesn't include an e-mail address, only display name.

@Adriano Faria: would you consider adding tracking of profile fields?

What would be nice is to only show threads with zero replies for a given user for threads that they can actually reply to. So, if a thread is archived, or the user only has read but not post permission, or the thread is closed to new replies, etc. This would make it an actionable view: "Hey, here's threads you should consider replying to!" with the goal of getting the number displayed down to zero (everyone gets a response) Would be an instant purchase if it worked this way.

So, a closed thread with no replies will show up in the view to a user who has permission to view that thread, even though they can't post a reply? For example, if I create an announcement/pinned thread that is closed to replies, a standard user who can view that message will still see it in this view you've created?

@Fosters, how does this handle displaying a thread with zero replies to a person with no permission to reply to it? For example, a thread that has been closed, or a thread where permission is that a person can read it, but not reply.

The lack of communication channels surrounding these "hidden" updates (only visible to a community administrator if you click "Something is wrong" in the Admin CP), which has the undesired consequence of clearing out all cached files, simply needs to be reconsidered by Invision.

Right now, when selecting "Delete content submitted already" in Spam Prevention > Flagging Spammers, content is immediately deleted. We are wanting instead to have that content moved to the "deleted content" queue that serves as a sort of recycle bin, in the event that someone needs to reverse the action. Please add this as an option, so that our choices aren't only hide or delete instantly. We want to delete in the same fashion as deleting manually as a moderator.

I know we reached out interested to use the plugin, and the "lite" version's code is obfuscated. We never heard back from the plugin's author after seeing that the plugin is no longer available for sale. Our tests with the lite plugin mirrored @IOhIO's review. I'd suggest disabling the plugin on your test or production site (whichever is most appropriate for you) and look at what impact that has on your TTFB metrics. We weren't able to purchase the full version and with the plugin author's decision to make the lite version's code difficult to read, we couldn't be sure it was using efficient means of converting furl requests.

That plugin is known to significantly increase page load time.

Are you using this plugin? (or the "lite" version)

I was looking for the exact same scenario--basically, have the settings and behavior there regardless of which option is selected in Posting > Links: Allow any links Allow any links apart from the links specified Allow only the links specified Right now, this plugin only works with "Allow any links" and we'd like it to work with Allow only the links specified. I'm surprised it doesn't work this way. Our use case is to allow internal links (our own URL) and moderate any other URL. We want to allow certain usergroups the ability to post without the moderation. Can this be added?

What application was that? Something from the Marketplace?

It would be wonderful to have this with the setting/option to create a new support request instead of a PM. Not all members have PM privileges on our site.

As to what's likely happening, see: