bfarber

Our Stripe checkout process already supports SCA. Can you point me to documentation on the chargeback protection you are referring to and where it is stated you must be using the Stripe-hosted checkout process? It is unlikely we will move to a Stripe-hosted checkout solution anytime in the immediate future.

Let me ask you this - do you think that a "fake" account is capable of supplying a username, but not passing a CAPTCHA challenge? Something tells me those accounts are likely being created by real people, even if the details are later turned over to a bot to abuse. As a general rule, when you allow people to sign in using other social login services, you are putting your trust in those services to properly vet and validate the account signups on their end. A better long term solution might be require moderation of new submissions for all new users until they have 2 or 3 approved content submissions. This would help you weed out fake or spam users without allowing their content to be visible to the community at large, while not placing a heavy burden on the signup/login process.

This is dependent upon factors in your configuration and is not the "norm". If you aren't using cron jobs to run your tasks as @Maxxius mentioned, that would be a good place to start.

We have not publicly posted a release date expectation for 4.5 yet I'm afraid. This is covered in the blog entry already.

Sounds like it might be a bug - I've made a note to check into it.

I haven't reviewed the third party requirements recently, but there used to be prohibitions on interstitial pages for such things.

Your existing attachment limits will already apply. 🙂 At the end of the day, these images are nothing fancier than attachments, just with a nice UI to submit.

I see the problem looking at your string there. I'll raise a bug report. Basically, your first option is just "de" and we're looking for "de-DE". Your other options have a quotient applied and we're not handling that in our basic sniffer. In other words, it just comes down to the formatting of your Accept-Language header not being accounted for.

It depends on the Accept-Language header your browser sends, ultimately. If it sends "en-US" we can guess you are probably from the US for instance.

There are group permissions to control which groups can use the feature where there is an editor field. For any other upload field (such as profile cover photos), the option is simply available if (1) this new feature is enabled and (2) the user can upload there. The reality is, nothing stops a user from visiting pixabay, downloading the image, and then uploading it to your community - so the reality is, preventing users from using this feature in any area is really only making the work harder on your members. If they want to upload a pixabay image they can, so why not make it a smooth and easy process for them?

The country should automatically be set to your country (i.e. if I visit from the US it should default to the US, if I visit from China it should default to China).

I've made a note to take a look.

max_input_time can be a limiting factor if the user's upload speed is very slow, or (again) it could be a limit set in your server software. I can't give you a blanket answer I'm afraid - there are plenty of causes. If your user is at all technically inclined they may be able to open the developer tools in their browser when performing an upload to capture the actual response from the server. This will probably help identify what is causing an error.

This is just my personal opinion mind you, but Yes, us developers here at Invision are aware of the request. It pops up now and then. Personally, I do not think the request sits well with discussion topics. Discussion topics by their nature are linear (perhaps with a handful of offshoots where you might implement threaded conversations ala Facebook comments), but are not generally an area where the "best posts" can just bubble up to the top and everything else be ignored. That;s not how a conversation works. That said, I have had use for this type of functionality in Pages databases in the past where the comments were not intended to be linear but more of a work log-type of situation, and showing the most recent comments at the top would have worked well there. Given how our framework works, if we implement it in one area because it has value there, it would be available Suite-wide (at least at the code level).

Here's a cake for making the post of the day