Thomas P

It should. It isn’t. That’s what I meant.

The profile is visible and accessible to anyone. You’ll have to edit their profile to remove the information you judge spam.

You didn't get it. Any clickable urls in the profile, added by the owner, should be hidden on mark as spammer. That would be awesome then.

Hi mates,
as it seems the "About me" section of a member profile shows all the added text and links, i.e. Spam, even after marked as spammer.
All posts and thread are hidden automagically but not the profile spam stuffing. So I guess our beloved spammers managed to bypass our spam measures...
Any ideas?

Thanks,
Thomas

I like to think of it as F for Fantastic. 
 
Complex layouts with user generated content on a platform that can manage text (forums) as well as gallery (large images) will never get an A from those automated tools. 
 
As I’ve mentioned multiple times, I can optimise the CSS for this site but it would break your theme. We want to reduce the footprint of our framework CSS but it is not a simple undertaking and will break every single theme on every single Invision community. 

I completely understand your position @Adlago. You are a power user with a very focused goal of attaining the highest possible pagespeed/CWV/lighthouse scores possible. This means spending days and weeks optimising CSS, JS, etc often making large amounts of changes and sacrifices to achieve your goal of a good rating from a brief audit with an automated tool.

That is what you want to do, and I understand that.

From my position, we want to deliver a very broad community platform that is capable of being used by a vast and diverse array of communities.

For example, these are both Invision Communities running the same major version.

 

Both of these websites use our base CSS. Now, if you wanted to make the Squarespace one super fast, you'd go in and remove virtually anything that is a colour, remove loads of the ipsBadge classes you won't need, all the various type styles and so on and save hundreds of bytes in the process. However, you could not then take that optimised CSS and make it work for the second example which has different needs.
My point here is that we cannot really create a very optimised set of CSS files for every potential community. What we want to do is overhaul the CSS to produce a much smaller footprint and be much more extensible but we don't have a magic wand. We have a finite number of developers with a growing list of things to do. Overhauling CSS means essentially starting a new theme from scratch and that means booking out our UI team for months.

Project planning is tough, but it's on the list to do.

It’s understandable that you don’t like this change as it prevents you from doing something you have gotten used to, but please keep it honest and factual. 
This was already answered. Clearly and thoroughly. So why ask it again? This is actually a dishonest debate tactic. By keep asking it, even though it was already answered, you are trying to suggest there is no good answer. 
And you know this how? So far, from the 27,436 active clients you are the ONLY ONE who mentioned a clear need to make drastic changes to the core CSS files. So it is questionable to suggest that “many” will turn away, when you have no foundation whatsoever to say that. You are likely just claiming it to give your position more weight. 

For my part, I would be happy if all CSS were readable, as before, for reference even if not editable. The latest patch shows modified CSS and allows reverts of existing changes but unchanged CSS are still hidden and therefore, you can't use search.
It was so useful being able to search for something (even something as simple as a colour) and then quickly locate the code, copy it and then paste a modded version into custom CSS.

I accept that the very few who make significant edits to our core CSS will find this change uncomfortable. The vast majority want to add or override existing CSS, so this change will not affect them.

We want to get to a point where we can serve CSS from a single set of files via a CDN. We also want to overhaul and modernise our CSS for efficiency and enabling a more streamlined output from a better build process.

These things do take time, and we have to take steps towards that goal, and drawing a line with 4.7.0 and asking that core CSS is not edited is the first step towards this.

As a temporary measure, a template edit in core/front/global/includeCSS to remove the framework CSS and instead link to a separate directory of your own optimised CSS would enable you to carry on with your heavily optimised CSS. I can help you with this if you wanted to explore this.

We had FTP but it was really very bad
See 
 
 

When you upload a file to AWS, it's using HTTP(S) to post the image via an API.  That is a one-time transfer from your server to AWS servers.  Once it is there, anytime the file is called, it's delivered directly from AWS via the bucket URL.  Meaning AWS is the one delivering the image instead of your server.
If you were to implement FTP, while it would not be difficult to upload the file...  downloading it would be much more difficult.  Modern browsers no longer allow the FTP protocol in the browser.  (For example with Chrome, it was removed in version 59.) 
This means IPS would have to each time it was requested, login to the FTP server and download it...  then deliver it to the user.  That would dramatically increase the work on the server, slow down the delivery of the site (because it has to be downloaded and then sent to the user), and increase bandwidth on both the web and FTP servers.  

It's save to ignore it!

Sorry to hear that. Hope the new upcoming features help with that  🙂 

Thanks Marc, think this is the first time you have let me down, I will get over it in time I guess. 😭

Just asking because this issue here.
Regarding development my question is, if there are any new features or planned improvements for the future.
Thanks 🙂
 

MariaDB: I am using version 10.11.2 without any issues.
PHP: 8.0 or 8.1 is the current IPS supported versions.
Redis: Version 6 according to IPS because version 7 is not yet support by PHPRedis extension, but I am using version 7 without any issues.
Elasticsearch: At least version 7.2.0, but less than version 8.0.0.
Before update make sure you disable all third-party plugins and app, and before enabling them back to make sure you update them to the latest version where they are compatible with PHP 8 and support IPS 4.7. 

Hello,
Yes, it is still supported. Regarding the developement part of the question, I am not sure what you mean by it. 

Nevermind, I'm not gonna cry for 20 bucks but this must be change sometime and from the dev side and from the IPS. A solution to not ask everytime I want to buy something....

Some of these are indeed not registered on kickbox as disposable yet. I'll forward them to be added.
I'll see if I can add support for verifymail.io too, but as this is a paid service you'd need an active subscription with them to use their e-mail verification. They may be a bit quicker adding some of these compared to Kickbox, but the prior does not require any form of monthly payment to utilize their API.

I should have an update for all my applications to add support for 4.7 sometime soon! It should be uploaded and approved hopefully by sometime next week.

@Michael.J hello, any news? Pretty slow support 🙁

i would say required in general.
 

It's now required as of 4.7.9

Also have this problem. Just one name in the list (no comma following), but it is still showing in the Multiple Posters list.

Yes 🙂
 
https://www.macrumors.com/2022/06/06/ios-16-support-web-push-notifications/