Luuuk

ACP > Customization > Editor > Settings > Return Key Behavior
There is no setting for that.

Removed already in some early 4.6.x release:
 

There is already a related topic in the Feature Suggestions forum:
 

Hi,
There is no setting but you can use this plugin:
 

Sry totally forgot about this, also have to use a friends installation for testing ...

If it still works with PHP8 there should be no problems with the latest IPS version, but I can take a look this evening.

Hi,
While I understand that you are very eager to have the feature integrated one way or another it won't help to create multiple topics:
 

I completely understand. Our main focus now is to make our app simpler. Simplicity doesn't mean we lose power, expandability or configurability but it does mean that we can simplify workflow processes.

For example, CSS editing; as we allowed core CSS files to be edited, we needed a conflicts and merge system to detect changes and offer the admin a chance to automatically merge these changes in. This is a lot of complex code that we can remove. We also presented multiple ways in the AdminCP to edit CSS which leads to a weaker UI and more confusion. It also makes our documentation more complex and longer as we explain both methods.

By choosing simplicity and a single way to add custom CSS, we greatly simplify the code, the workflow and our documentation and make the software easier to use.  

Chill man 🤙 Go take a breath or something 😉 They care about customers, I can assure you.
Thanks Matt for the clarification. I think no one should have any doubts now that this change was needed.

Also, you can still view the full (concatenated) CSS files in web inspector. Just click the filename:

Then the format button:

Maybe y'all develop differently to me, but personally I wouldn't browse through a random CSS file to find classnames - there's no context (beyond the classname anyway; you don't get any of the cascade, inherited properties etc. that might affect it).
It makes much more sense to use the web inspector to see what is actually being applied to the element you want to change.
It may be a difficult transition at first but i would consider this an opportunity to improve your own development process.

There's a lot of confusion here, so I'll do my best to address it all.
Why have you removed CSS editing?
First off, we have NOT removed the ability to edit and add CSS to your themes. When we released Invision Community 4.0 way back in 2012, we added a "custom.css" file and asked everyone to add their custom CSS to this file. This means that when we make changes to the core CSS, you do not have to merge changes, or re-apply edits. Your custom CSS is untouched.

This is exactly what CSS is designed to do. The core CSS may contain something like this.
body { font-size:14px; font-family: Helvetica; margin: 10px color: black; } So, what do you do if you want to change the colour to red? In the past you could edit this core CSS file directly and make it like so:
body { font-size:14px; font-family: Helvetica; margin: 10px color: red; /* Changed color here from black */ } This would work fine BUT if we changed our core CSS to change the font-size to 16 like so:
body { font-size:16px; font-family: Helvetica; margin: 10px color: black; } This will now overwrite your changes, which means you'll need to re-edit it back to:
body { font-size:16px; font-family: Helvetica; margin: 10px color: red; } This does work, but means you are constantly having to compare your changes to ours.
Fortunately, CSS (cascading style sheets) is designed to allow new CSS files to overwrite rules that we set, and that is why we have a custom.css file ready for you to make your upgrade-proof edits.

So, if you wanted to make the body colour red, instead of editing our code and maintaining changes, you simply add this to custom.css
 
body { color: red; } CSS knows to combine OUR rules with YOUR rules. It's exactly what CSS was designed to do. The computed result (how the browser sees it) of this is exactly the same:
body { font-size:14px; /* from our core css */ font-family: Helvetica; /* from our core css */ margin: 10px /* from our core css */ color: red; /* from custom.css */ } This is clearly a much better way of changing the CSS rules. You can keep all your custom code in one place and you no longer have to maintain copy and paste edits to core CSS.
In short, CSS editing STILL VERY MUCH EXISTS!
Why this change?
To be frank, it's 2022 and there's no valid reason at all to be editing core CSS when CSS itself was designed to cascade and make your lives easier.

We should have locked out editing of core CSS a long time ago. As the web moves on, we have to move on too. Serving CSS from a single CDN will improve the page speed of your site as it will come from a cached no-cookie domain.

No modern application out there will allow you to edit core CSS, there just is not the need.
I realise that for a very small number of people this means changing how you work, but this is how you should have been working since 4.0 was released a decade ago.
If you actually use custom.css I promise once you have completed the initial population of this file, your life will be made so much easier!
This is industry standard
If you look at other apps, they allow you to add custom rules that cascade over the core CSS files. Like Squarespace, and Wordpress which states: "You can use the CSS editor to customize the appearance of your WordPress.com site. It works by allowing you to add your own CSS styles to override the default styles of your theme."

This is EXACTLY what makes it the right solution. This file was specifically created for this purpose. It even says so when you open the file. 
/** * This file is for your custom CSS. * This file is not modified or overwritten during upgrades */ This describes the purpose and why changes should only be made there.
You have no argument against that, because there is none. You are essentially just in denial. You are saying “if I was allowed to do it the wrong way in the past, you better let me keep doing it the wrong way”. And ironically, this practise is NOT an argument to revert the change, but instead an argument to make sure that this practise is indeed being stopped. 

Set it in custom.css and then you'll never have to worry about conflicts or updates again.
That's literally how CSS works (the C stands for Cascading).

It was always wrong though. You would change a core file and so every future update of that file would cause an unnecessary conflict. Adding an override in the custom.css was always the right solution. So, the change just prevents you from doing it the wrong way. 

Hi,
For Moderators with Restricted permissions:
ACP > Members > Staff > Moderators > Edit a selected Moderator > Content > Can award user's content?

...from reading this.


 

@Denniz38
I'm afraid I can't be helpful.
It looks that custom filter settings are fully ignored. I have tried various rules as well as the pre-definied 'plain-text' and none are interpreted. I have no idea why.
BTW. I made a feature suggestion to add a config for disallowed content:
 
 
 

You should always upgrade in the following order: IPS software > custom theme (and other third-party stuff). You will get the incompatible message during the first step.
1. Themes will stay "accessible" to be updated or removed. For minor upgrades it will be sufficient to use "Upload new version" feature. But in case of large upgrades such as 4.4 to 4.7, you should do a fresh installation of your custom theme.
2. That would be the theme currently set as "default". For safety reasons, I always swap a default theme from my custom theme to the Default theme before upgrading. Then after upgrading I upload a new version of my theme and set it back to "default".
 

Hi,
Related to this topic.
Currently we have Editor Settings > Advanced > a selective GUI for ACF "to loosen the restrictions". I think we need also a complementary filter to do the opposite without disabling rich text. See Filtering Pasted and Dropped Content.
An additional filter (called paste filter) can be configured to handle pasted and dropped content. It will be applied independently from ACF, so it can be used as the only filter (with disabled ACF), or as a complementary filter (for example to filter pasted content with stricter rules than all other content).

You should always upgrade in the following order: IPS software > custom theme (and other third-party stuff). You will get the incompatible message during the first step.
1. Themes will stay "accessible" to be updated or removed. For minor upgrades it will be sufficient to use "Upload new version" feature. But in case of large upgrades such as 4.4 to 4.7, you should do a fresh installation of your custom theme.
2. That would be the theme currently set as "default". For safety reasons, I always swap a default theme from my custom theme to the Default theme before upgrading. Then after upgrading I upload a new version of my theme and set it back to "default".
 

Hi,
For Moderators with Restricted permissions:
ACP > Members > Staff > Moderators > Edit a selected Moderator > Content > Can award user's content?

It means that if you want to make a change to the CKEDITOR config then that is the best way to do it.
In short...
Edit your globalTemplate template in your theme. At the bottom, before closing </body>, add the following and then save the template <script> if(typeof CKEDITOR != 'undefined'){ CKEDITOR.config.pasteFilter = '<WHATEVER>' } </script>