bfarber

We are not ignoring this topic. We just haven't commented is all.

We are not ignoring this topic. We just haven't commented is all.

We are not ignoring this topic. We just haven't commented is all.

Invision Community represents what I've looked for in community management software for nearly a decade.  
Simple/intuitive content management - CHECK Powerful member management tools - CHECK Robust engagement capabilities - CHECK Ability to extend built-in capabilities via API - CHECK I can now easily deliver a fully dynamic and engaging user experience to my members from within a single tool.
Rob
STSF.net

We have some ideas to improve forum selection with fluid view in a future release.

We have some ideas to improve forum selection with fluid view in a future release.

We have some ideas to improve forum selection with fluid view in a future release.

We have some ideas to improve forum selection with fluid view in a future release.

You did not specify these were multiple-GB files. I also would not store those in the database, indeed.
You can store files outside of the web root directory if you write a PHP script as a gateway. Look at /applications/downloads/interface/legacy/screenshot.php and /applications/gallery/interface/legacy/image.php. These are present because 3.x allowed you to store files outside of the web root directory, and upon upgrade we do not move the files to a new location (so a gateway script is necessary to read and print those files out). You just have to enter a custom URL into the file storage handler "http://mysite.com/applications/downloads/interface/legacy/screenshot.php?path=" and then the actual path of the file gets appended to the URL (at which point it is passed as a query string parameter to screenshot.php which does the rest).
In short, this is largely already possible, although I can't say if it's something we want to push to the forefront and make a common feature.

We have discussed this, but it's tricky. For instance, I considered looking at calling our IPS Spam Service for emails sent through the contact form, but we decided that this couldn't be done because a valid user who was blocked from registration by the spam service would then have absolutely no way to contact the site admin to let them know or get assistance.
Unfortunately, if you leave a contact form in place, spammers will use it. It's tricky to block spam effectively here without resorting to "hacks" (like scanning the email for specific text which may not actually be indicative of spam).

If you open a new ACP tab from an existing ACP session you can use multiple tabs no problem. If you login in a separate tab, however, any existing sessions are invalidated. This is a security precaution.
We will be moving towards cookie-based authentication at some point I expect, which would resolve your concern.

If you open a new ACP tab from an existing ACP session you can use multiple tabs no problem. If you login in a separate tab, however, any existing sessions are invalidated. This is a security precaution.
We will be moving towards cookie-based authentication at some point I expect, which would resolve your concern.

If you open a new ACP tab from an existing ACP session you can use multiple tabs no problem. If you login in a separate tab, however, any existing sessions are invalidated. This is a security precaution.
We will be moving towards cookie-based authentication at some point I expect, which would resolve your concern.

The AdminCP session timeout is based upon your PHP configuration - you can update it to extend the session timeout if you wish (using the regular session configuration options).

The AdminCP session timeout is based upon your PHP configuration - you can update it to extend the session timeout if you wish (using the regular session configuration options).

Mine started also to recover since IPS 4.3.

We are exploring possibilities as Lindy said, including implementing more event-based triggers (which we do in some places already, such as MemberSync extensions) and looking into adjusting the hooking system to allow it to work with traits as well. As Lindy said, we will update everyone with more information in due course.
 

We are exploring possibilities as Lindy said, including implementing more event-based triggers (which we do in some places already, such as MemberSync extensions) and looking into adjusting the hooking system to allow it to work with traits as well. As Lindy said, we will update everyone with more information in due course.
 

There isn't a problem with those pages, as the canonical is set to the correct one on all of them:
<link rel="canonical" href="https://invisioncommunity.com/forums/topic/442742-large-community-you-have-a-problems-with-sitemap/" />  

Account deactivation will be coming very shortly, but this is not to be confused with account deletion. There are no immediate plans for an automated deletion system for various reasons outlined in other topics. It's worth noting that the GDPR provides for lawful bases of collection and processing of information. If money has been exchanged, for example, they cannot demand you delete their account and existence provided you have a purpose for retaining it and in the US, we are obligated to maintain financial and legal records. You must, however, outline a retention policy (ours will be forthcoming.) In terms of content, unless a post or other content item contains personally identifiable information such as a physical address, you do NOT have to delete a member's content - it belongs to the community, not the member (and that should be clear in your policy.) 
So, the impending account deactivation will disable the profile and effectively archive the account. There will be no way to contact the member, even with an admin override (and no such modifications will be allowed in the marketplace) through the software and they will receive no further communication from the site. This will satisfy requests in which the user wants to leave but cannot be forgotten. 
Right to erasure requests for which there's no legal basis for processing (communities where there's no contractual premise) an do require deletion would still need to be processed manually by the admin. Again, there's too much to consider there - hacked accounts, validation, purchase records, etc. for us to comfortably automate without a fairly significant amount of development time, testing and resources and our efforts are better focused on keeping people on your community, not spending weeks developing functionality to allow them to delete themselves with the click of a button.  
We'll have more info on GDPR as it relates to IPS and account deactivation soon. Thanks for your patience. 

The new Search Console has some useful tips and offers a few clues.
https://support.google.com/webmasters/answer/7440203
On one of my sites, entirely powered by IPS (Pages, mostly Gallery, no Forums), it says 2.5k out of excluded 6.5k urls were excluded for being duplicate pages without canonical tags.
Looking at the list, a lot of them are as a result of Google following various sort and display options for Gallery albums in Profile view, but these are albums that don't exist because the user is brand new and hasn't even submitted anything yet. I'd exclude them too!
Another 1.8k Pages were marked as excluded for being Alternative page with proper canonical tags.
Again, looking at the list, the urls seem to relate to different sized versions of Gallery images.
380 were excluded for Excluded by ‘noindex’ tag.
These appear to be various Pages Articles urls appended with options such as "sortby=record_views&sortdirection=desc&page=1&d=1&advancedSearchForm=1".
Another 409 were marked as "Crawled - currently not indexed: The page was crawled by Google, but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." Very informative! These seem to be urls of Gallery images and page articles.
Another 300 or so were excluded for being soft 404s, mostly calendar events.
One area I've had a lot of Google errors in the past is with Tags not being crawlable, on one site in particular the majority were Tags on Blogs, supposedly fixed in a future release according to a ticket at the time.

I think it’s just Google doing it’s ‘thing’.
I’m pretty sure this has little to do with sitemaps. I process all my sitemaps each night with a simple in-house script for my 500k or so topics. It only takes a few minutes to run. I have been doing it this way for years.
All the links show up in Google as being in the sitemap. But about a year ago, Google started dropping them from the index by the hundreds of thousands. Also my home page key words used to be in the top 3 at Google, now they've been lowered into obscurity. It’s not blacklisted. Some links are still there but just not ranking.
Yet, if I post something on YouTube or set up an empty store on a popular ecommerce site, all of a sudden those links are up at the top of some search results. So, it may just be Google on yet another new algorithm deciding who gets to see what.

The system is more geared towards digital goods being distributed, or site-sponsored physical goods.
There are third party addons on the marketplace that facilitate user-to-user sales of items (i.e. "classifieds"), and we have some ideas rolling around internally to open up Commerce further.

The system is more geared towards digital goods being distributed, or site-sponsored physical goods.
There are third party addons on the marketplace that facilitate user-to-user sales of items (i.e. "classifieds"), and we have some ideas rolling around internally to open up Commerce further.

"their" in English is taken to mean "belonging to them". As we do not know the gender of the user, we can't say "his" (as in belonging to him) or "her" (belonging to her), so "their" is an acceptable gender-neutral solution.
But, as you use a translation that adjusts the verbiage anyways, I'm not sure why this matters.