Miss_B

The 4.5. version revolutionised the forum world imo. It is the best. They really did a wonderful job.

We did away with our heavily customized forum skin and just went with the default, with our own header and footer added. Then I changed the colors of that skin to make a dark version. It required a few lines of code in custom.css and it's not quite finished, but the results are really good. This is the best our forum has ever looked, and it's also the lowest-maintenance its ever been.
The integrated GIFs, little changes like the rounded border around the reactions display, and other subtle improvements have made this update really nice. My community site feels lightweight, responsive, and alive. It definitely feels more like a "social community" than a boring old forum.

It works with ips regardless where the connection comes from. You can exclude ip(s) as well from the restriction if there is any vpn connection that you want to make an exception.
 

This is something that will require custom coding.

I'm not sure what happened or why the error occurred, but it seemed to rectify itself.
Thanks for all the advice and assistance.

OK, sounds great. I'll get it installed and cross my fingers.

Great to see this add-on 🙂 though i have some suggestion for it if you can add some features in it. Instead of admin CP i want this on public end. Like an option with quote post that anyone who has permission to view dupes can click and check if any duplicate accounts exist for that user in db or not.
 

There is a proxy/vpn blocking app that might interest you.
 

If you genuinely believe those files to be Ok (original files, and writeable) then you can add:
 
\define( 'UPGRADE_MD5_CHECK', FALSE ); In your constants.php file.

This prevents the file check from occurring. 

Hi,
I purchased this application but there are some minor issues I am facing - http://prntscr.com/upu63v
Is it possible to select which user class to show records for?
It shows actions from all user groups including non-staff groups The date/time is the same for everyone? Also shows a deleted guest account and banned user class as well  

Hi,
I wanted to clarify the process for any critical updates you may need to make that may potentially need a higher priority when it comes to a review. A critical issue would be something that causes a large impacting issue to your resource, such as a fatal error that prevents it from working.
Submit the new version of your resource with only the fix for the issue, no other bug fixes or enhancements. Specify in the change log what the fix is for (so it's obvious to us what you are fixing). Submit a support ticket asking for an expedited review. Asking for an expedited review doesn't guarantee we'll be able to do it, but we'll try our best where possible.
Thank you!
Stuart

Yes, we had so many issues, so much support overhead and so much customer dissatisfaction with inconsistency and sloppiness prior to 4.5. We only provided cursory reviews for initial submissions and as is often the case, a new product (or resource) tends to start with a base and then future releases build upon that with enhancements. Without screening updates, we were missing some pretty significant issues that broke communities. Couple that with the disorganization of customers manually managing updates for resources, leaving their community in an unstable site with a hodge-podge of outdated third party code, we had to make a decision. Either limit the damage a third party resource could do to a community, which would mean removing some of the flexibility that makes resources so useful -- or exerting control over what's pushed through the Marketplace. We opted for the latter as it ultimately benefits the majority. The majority of contributors from a support and even, to an extent, piracy standpoint. Customers because the resources have far more stringent standards, are screened - even for upgrades - which can only increase confidence and stability in the product. IPS, because the support overhead is reduced due to out of date third party resources, poorly updated resources, etc.
We recognize there have been a few bumps and I apologize for same. I have the utmost confidence and faith in this change. Regarding approvals, more information regarding the process for critical updates has been posted in the contributor forum - please be sure to follow that forum if you don't already. In short, there's a provision for critical updates. Normal updates should be expected to take 24-48 hours or so, which is typical of an app store based on my research.
 

It’s currently 10% and has not yet increased to 20% - we’ve left it alone in light of Covid and ironing out the new marketplace.
That said, even at 20% it’s expected to almost break even. The marketplace operates at a net loss to IPS just because of the price point of most resources. So on. $5 resource, we get a $.50 commission - now, say that $5 resource has a chargeback that’s $20. So our net loss on a $5 resource is $20.50. That also means we need up to 40 more of those transactions in commission just to break even on the original transaction. There is also payout fees to pay the authors. The marketplace operates in the red even before considering the staffing. When you slice it up, you could see why apple takes 30% and never refunds their fees.
Thats neither her nor there, my comment was reinforce we don’t make money in the marketplace - the opposite, so it’s ok if you use the authors site too. It’s just not ideal (for you.)

Good to see you around, Tiger. That is very... passionate feedback on the URL reset fee. Although it's been addressed before, I'm happy to do so again. 
Firstly, prior to limiting the resets, it was very easy to "license hop" - that is, swap URLs around, obtain support, upgrades, etc., swap them around and repeat, etc. So, while not necessarily the original intended purpose, it does help keep the honest... honest in the same sort of way that a deadbolt keeps the undetermined at bay--obviously, the determined/committed can kick the door in. 
Secondly, in many cases, there actually are costs incurred with fresh installations by way of support. Frequent URL resets are a byproduct of tossing ideas around, deleting, reinstalling, configuring and deleting. Quite often, there are numerous support requests involved and unfortunately, often the same questions/concerns over and over again on each reinstall. The spirit of tech support provided is based on a single installation and not so much to support 'tinkering' and perpetual reinstallation support. The fee, when applied, helps (in a small way) offset some of that overhead.
I would hope a number of customers here would attest to the fact that we will generally just update the URL for you if you contact us - especially if you're just changing the URL on an existing installation. In cases such as those described above, the fee may apply. 
I'm sorry you consider it a barrier, but I can assure you, we're not funding private yachts from license reset fees. 🙂 Even with license reset fees, we frankly still typically tend to have a net loss when it comes to many of those (not all, but many) that kind of toss ideas out to see what sticks. You've been around a long time (for which we're appreciative!) - you're a power user (who still sees us as a 'forum provider') and you won't likely require much support throughout your tinkering journey. That's not usually the case here. 
Just drop us a note if you find you need to change the URL on file. We're generally able to help if that's all you need. 
Thanks for the feedback. 

Any methods that alter the state of something. So, saving settings (which happens already if you are using \IPS\Helpers\Form), deleting, editing, etc. etc.
So, for instance, on a delete button you would do:
array( 'title' => 'delete', 'icon' => 'trash', 'link' => \IPS\Http\Url::internal( "app=myapp&module=mymodule&controller=mycontroller&do=delete" )->csrf(), 'data' => array( 'delete' => '' ) ) Then your delete method would do:
public function delete() { \IPS\Request::i()->confirmedDelete(); // ... etc ... } For any other method, you would do:
\IPS\Http\Url::internal( "app=myapp&module=mymodule&controller=mycontroller&do=somethingThatChangesSomething" )->csrf() Then:
public function somethingThatChangesSomething() { \IPS\Session::i()->csrfCheck(); // ... etc ... } Most of the framework will largely handle this, however you should be mindful. A good example is flagging a member as a spammer in the admin members controller. This does not use a a form, or anything that would automatically apply a CSRF check, however it's an action that alters the state of the site (ban the user, hide their content, etc.). Therefore, it needs a CSRF check to make sure it was an action the administrator actually wanted to do.

We have removed the session id from the ACP urls, meaning that you have to make sure to use CSRF protections in all your methods which change a state!
We also advice to use \IPS\Request::i()->confirmedDelete() in all your methods where you're deleting data!
 
One of the few examples from the MP reviews is this code:
protected function approve() { if ( !\IPS\Request::i()->id ) { \IPS\Output::i()->error( 'node_error', '2myApp', 404, '' ); } $a = \IPS\myApp\Item::load( \IPS\Request::i()->id ); $a->open = 1; $a->save(); /* Log History */ \IPS\myApp\History::addEntry( 'foo', x, \IPS\Member::loggedIn()->name ); \IPS\Output::i()->redirect( \IPS\Http\Url::internal( '.' )); }  
Once an administrator with a valid ACP session calls the url, he would automatically approve the advert, meaning that any member could post an encoded URL (or use one of the other methods which I'm not going to mention here ) to lead the admin into the trap!
 
To prevent that this happens, you have to utilise the CSRF key and to check in your method if the key is valid, before anything else is done!
 

Hi @jaeitee given that you have an existing Invision Community installation:
1.  Prepare the existing Invision Community installation by making sure it's on the latest version.  Same thing with your vBulletin installation.  You also want to create a test copy and a back-up copy at every major step.  
2.  You should make sure that your membergroups are set-up correctly for the 'combined' installation, since you will need to map those permissions during the import.  
3.  Run some test migrations if needed.
 
Some other notes:
1.  You can check out this blog post that I wrote with real experiences of vBulletin clients switching to IPS.  The members that I interviewed are actually all real and active members of the community. (One of them was active ... 18 min ago!)
 
2.  In terms of community strategy, you want to communicate, communicate, communicate.  Invite over your superusers in a private access test; send out blast emails, send out notifications, share screenshots, send instructions, etc.  Then repeat again as you get closer to the actual migration.  As Rhett mentioned above, any accounts that share the same email will be merged, so don't be afraid of inviting over members to preview and acclimate themselves to the new community.  
3.  This is totally up to you and how much of a hoarder you are 🙂, but you might want to think about cleaning out your vBulletin database.  Delete old topics, remove outdated instructions and how-tos, revert to vanilla, etc.  
4.  For the migration itself, you can ask IPS to do it as a paid service, a third-party provider do it as a paid service, or yourself.  For list of third-party providers (and then filter by Data Conversion): https://invisioncommunity.com/third-party/providers/

Also, have a look at these topics. 
https://invisioncommunity.com/4guides/getting-started/migrating-from-another-platform/running-the-conversion-r211/
https://invisioncommunity.com/news/guest-blog/10-tips-for-converting-from-vbulletin-to-invision-community-r1131/
 
 

Good luck with the conversion. Let us know how it will go.

Also, have a look at these topics. 
https://invisioncommunity.com/4guides/getting-started/migrating-from-another-platform/running-the-conversion-r211/
https://invisioncommunity.com/news/guest-blog/10-tips-for-converting-from-vbulletin-to-invision-community-r1131/
 
 

When you run a conversion, it will use the email address to match up accounts and merge them if they are the same. As with all major changes like this, doing a test run on a copy of your community may be a good idea for you. 

Thank you, worked like a charm! 🙂

First of all, make a backup of your forums_posts table, then run the following sql query at the SQL box of your phpmyadmin for the database that you have used to install your forum.
UPDATE forums_posts SET queued = 0 WHERE author_id = x; Replace x with the actual id of the member whose posts you want to make visible/unhide again. 
I hope it helps.  Please let me know if you will have any additional questions. 

The first result when searching for 'ignore'...