Jump to content

Stuart Silvester

Invision Community Team
  • Posts

    3,606
  • Joined

  • Last visited

  • Days Won

    25

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Stuart Silvester

  1. It's also worth noting that your email server (whether SMTP or other API like SendGrid) is responsible for assigning IDs to messages as part of the sending process. That's not something that we do.
  2. That sounds like you've got a member account in vBulletin with a stored post count of more than 8,388,607 (the maximum our equivalent field can store). I'm fairly sure this would be a bogus value or a bug in vB that stored the wrong value. If you have a look at the users table in your vB database, have a look for any users where the 'posts' column is larger than 8388607 and adjust it to something smaller.
  3. Your staging site is behind a password prompt, you would need to temporarily disable that whilst you sign in. Alternatively, you may be able to exclude <url>/index.php?app=core&module=system&controller=marketplace from your password prompt.
  4. Invision Community doesn't have the concept of ResourceOwnerIds. It isn't part of the OAuth 2 specification that we follow. Something like that would be used where many tenants/sites may be hosted on one single platform, i.e. where customers use Azure AD the ResourceOwnerId would be the tenant ID to make sure the requests are going to the correct customer account.
  5. Sitemaps are automatically submitted to Google when they're generated/updated. However, if you want it to be viewable in Google Search Console you still need to submit it for it to show up in the UI. <community_url>/sitemap.php is the correct URL to submit
  6. The viewing member is being added to the widget via JS if it does not see them listed (this can happen when the widget is cached). Take a look at JS: core.front.core.onlineUsersWidget
  7. Yes, that's right. The image library choice affects anywhere an image may be uploaded.
  8. Yes and no, it's currently only supported on Cloud when using GD library to process images but we default to ImageMagick library since it's much better (speed, resource usage etc) for processing images. We are going to be reviewing this soon, so I've made a note for us to look further into this.
  9. 4.6.11 is the March release, it was released this morning. If your community hasn't seen the update yet (it only checks once per day) you can go to AdminCP > System > Applications and click on 'Check for updates'.
  10. That wouldn't quite work either, it would include screenshots, links from all versions and also include new files that are pending approval
  11. $files isn't an array, but an Iterator. You might be able to do something like {{foreach array_reverse( iterator_to_array( $files ) ) as $k => $file}} I haven't tested and I'm not certain that it'll work, but worth a try.
  12. I was giving context for anyone else reading this topic about why it was happening.
  13. Thank you, I have filed a bug report so we can review this. Typically it would mean that the file you're uploading is too large or empty.
  14. This issue was specific to the 4.6.11 beta. It has been fixed for the final release.
  15. Yes. The issue was mostly related to third party login methods that don't provide an email address (steam). When the end user provides an address they need to validate it
  16. Your purchase of the resource expired. You can renew it from here: https://invisioncommunity.com/clients/purchases/
  17. I've got some ideas I want to look at for this situation, deleting existing subscriptions (and thus removing records of purchases) isn't one of them though. If they're upgrading to a higher tier subscription, they could renew the one they have now and then upgrade it. I know it isn't ideal, but it's a working upgrade path. However, not seeing an error message when the member tries to log in is not intended, I have filed a bug report for that and we'll take a look. They should be seeing an explanation for the issue instead.
  18. Randy is right, in the process of removing support for the native application we removed a method that most customised themes will be calling in their global template. We've put this method back for the time being (it doesn't do anything now) so it won't cause theme errors.
  19. We've re-added the method we removed for the final release (it will be removed again in a future version), but I would still strongly recommend that everyone check their customised templates when they upgrade and implement any changes.
  20. You will need to create a new theme in that case and set it as the front-end default or you can revert all of your customisations to the globalTemplate.
  21. Your custom theme is out of date and needs to be updated. You can follow the instructions here: You can also go to https://invisioncommunity.com/index.php?app=core&module=system&controller=plugins&do=diff and click 'show differences' to see what the changes are between 4.6.10 and 4.6.11 Beta 1
  22. Thanks, we're aware of the issue and working on pushing out a fix for it.
  23. Thank you for you report, a fix will be included in our upcoming release.
  24. PayPal are completely in charge of when they take payment (unlike other payment gateways, we cannot tell them when to charge the customer). With that type of set up, it isn't really possible for us initiate a duplicate charge unless the customer has gone through the checkout process twice and set up two different subscriptions. We have previously seen PayPal Subscriptions collect payments a month or more late though which may explain this. You may find that the customer didn't get charged for the previous period. I have created a support ticket for this so we can look further.
×
×
  • Create New...