Stuart Silvester

You need to be extremely careful using |raw especially if the content is coming from an outside source without being cleaned. Incorrect use could open your community to XSS attacks.

FWIW, I was referring to the resource you recently submitted for review.

Don't forget about the potential security issues and other issues we also rejected it for. We care about the quality of resources our customers can install, even more so with the much wider audience enabled via the AdminCP Marketplace. That means we need to hold submissions to a higher standard than we did prior to the release of 4.5, unfortunately that does mean that some submissions will be rejected and will need to improved.

Yes, if you don't have any vB CMS data to convert, uncheck 'pages and records'. We've fixed this in an upcoming release so it's a bit smarter and knows if you don't have vb CMS even if you check the box.

This can happen when you export a database with the wrong character set, i.e. if moving server etc. You would need to specify --default-character-set=utf8mb4 when running mysqldump. It is irreversible, you cannot restore the now corrupt emoji data.

@Paul E. makes some great points. Communication is the key with your members, let them know when things are going to happen and (if you choose to run the background tasks after launch as they're designed) let them know that some things may look slightly wonky for a short time. I would also recommend not making knee-jerk reactions to comments your members make immediately after the conversion. People generally do not like change and will be saying "make this work like vBulletin". Take some time and let them settle in with how the new platform works and then collate their feedback. We did throw some good muscle at that conversion (and it wasn't vBulletin) so you might not be as quick, but we've definitely made some good performance related changes. A note I made when working on the performance changes says "[vBulletin 3/4] Posts step was around 900ms per 200 posts instead of 19 seconds". Your mileage may vary of course based on many factors. @Paul E. There were many performance specific tweaks, but the changes to how links are handled showed the biggest improvements (a lot less queries).

I did a conversion on a site with around 60 million posts late last year (there were actually millions more posts in the source data). We did a performance sweep of the converters for 4.5 for this project and incorporated many things that improved the speed. One of these performance improvements would be in the userland code (your converter), I would recommend taking a look at our vBulletin converters, especially the use of `$this->app->preCacheLinks(...)` which can hugely reduce the number of SQL queries needed. The speed can greatly depend on how you write your converter though, make sure your queries are efficient in loading data and using indexes. Speed is also dependant on the server/configuration you're running the conversion on too. The above mentioned project took about 1.5 days to run convert (clarification: describing the conversion process itself, not the post conversion background tasks) the site (excluding image attachments - having that many is a completely different story of its own).

As Brandon notes, using our converter framework would be the best way to go. It already does a lot of the legwork for you. All you really need to do is feed it the relevant data, it'll put it in the right places and process it as needed. You would be better to use an application and store your converter files within that application rather than writing a plugin to load them from elsewhere (it's nicer to keep them in their own location than throw them in another (IPS) application). You will still need to add a hook to the software() method to define your custom converter location. Doing a conversion via AdminCP is perfectly fine, command line conversions are not supported.

The issue was that your SSL configuration on your server is broken, disabling SSL between Cloudflare and your server works around the issue. This is a workaround specifically, if you fix your SSL certificate, you can switch it back to full SSL mode.

That shouldn't be the case, we'll have a look into this 🙂 thank you for letting us know.

Delta conversions are not supported, it depends what you're including in a 'full conversion' (i.e. background tasks) but I wouldn't expect the conversion itself to take 3 days on a community your size. Open a ticket and we can look at the performance aspect on your server. Personally I would recommend starting your live conversion with a fresh install, it just makes sure you're not going to have any orphaned data from previous testing lying around for eternity.

Conversions are generally quicker in 4.5, we added vBulletin specific performance improvements too.

'EX0' is an uncaught exception, essentially it's anything that is unexpected. On registration, it's typically caused by a third party plugin/application.

There are a series of background tasks that run after the upgrade to re-format and upgrade content. You can view the progress of these on your AdminCP dashboard.

We have made some optimizations for 4.6, mainly disabling Redis data being encrypted by default.

Click into your license, then click 'create request'. Do not submit ticket at the Zendesk URL it may not get answered.

2Checkout is also an American processor. I think Stripe would be the most International you could get with the built-in support since they have a dual HQ in both Dublin, Ireland (originally an Irish company) and San Francisco. There are however 3rd party payment gateways available in the Marketplace, many of these add support for processors based in other countries. https://invisioncommunity.com/files/category/172-commerce/

Our 2CO implementation doesn't support recurring billing like that, but our Stripe implementation does (Stripe is far more popular with our customer base too).

The referral ID does work on any page if referrals are enabled. The content share links will automatically add the referral ID to the URL you can copy and also to the buttons to share directly to other platforms. Granted it only appears on pages that have content, but the functionality does exist.

It's up to the author whether they want you to buy a license for each community you install it on. They have the capability to define this (and they should) in their terms and conditions that appear prior to purchase and prior to install/update. Generally without renewing you can still use the resource, but you won't get any technical support or updates for it. As mentioned though, authors can set their own terms and conditions so you should read them carefully if they are provided. I have never known someone to reinstall a resource to fix an issue. What you would do there is contact the author for help. If they find an issue, they'll fix it and publish a new update. Of course, you would typically need an active purchase of the resource for that. Additionally, if you maintain backups of your community you shouldn't have an issue either. As noted, it's up to the author to define these terms as they can differ between resources. They have the ability to display their own terms & conditions prior to you purchasing or installing the resource. This was also a new capability we added with 4.5, I expect these T&Cs will be populated as files are updated. p.s. here's what that looks like:

We've pushed out a change to the Marketplace today for this, it was related to how we were avoiding sending renewal invoices to those who's licenses have expired. Expired license holders still won't get an invoice, but the renewals will no longer be removed from the purchase. We've also made a change for those that have purchased a resource then had their license expire, from today the customer will be able to continue to install/update the resource they have paid for until it expires. Renewing it will still require an active Invision Community license.

Certainly, I'm going to link to all of the recent topics that are related (although the titles may not initially indicate that). https://invisioncommunity.com/forums/topic/457951-localhost-downloading-of-marketplace-appsplugins-manually/ https://invisioncommunity.com/forums/topic/458681-marketplace/ https://invisioncommunity.com/forums/topic/458402-when-pluginapplication-upgrades-fail-in-45/ https://invisioncommunity.com/forums/topic/458417-marketplace/ (this was your topic, but I believe our response in here still applies and gives an overview of why things are like they are) I appreciate that's a bunch of links, but they do collectively give a good idea of where we stand in regards to the Marketplace. -------------------- I did remove your workaround and we will continue to do so. As noted in the topics above, how the Marketplace works can also greatly impact on how we provide support and the speed of that support. We're not going to allow any workarounds to how this works to be advertised.

Yes, you would still need to configure the CORS headers. The main difference is that you will be sending requests as an authenticated user instead, so they'll only be able to see things that they're allowed to see and perform actions where allowed.

The difference is that when you use an API key, you're interacting at a high level. These requests do not have extra permission checks on them to determine if the end user can see the content. Even if you're specifically crafting a URL to fetch topics from a certain forum, your same API key could be used to fetch topics from a secret forum that you don't want anyone to see. https://invisioncommunity.com/developers/rest-api