13.

I think we need to include this functionality as well.

This could be achieved with super-simple hook. ... parent::_htmlPurifierModifyHtmlDefinition($def); $def->addAttribute( 'a', 'name', 'Text' ); ... Keep in mind what name attribute is deprecated and not a part of HTML5, so it would be better to use something like data- attribute and then in JS on client side make an id attributes from it's values after checking that these IDs will not conflict with existing IDs.


I did it some time ago for my communities, here is a live example.

This would be great if it's implemented as a core system function.
 

My community uses messages quite a bit, and sometimes I want to read a message right away but reply later on.
It would great if I could mark a message as unread in this scenario so I remember to get back to it after. 
Just like with email, basically.

Currently we can report only content items, but sometimes it would be useful to report a user, for example in cases when user account was made is only in order to leave links in it's profile and "About me" section, like this.

@Joy Rex, it's about filtering at the IPS level, not CKE.

Currently we can report only content items, but sometimes it would be useful to report a user, for example in cases when user account was made is only in order to leave links in it's profile and "About me" section, like this.

In this announce new feature called "quote collapse" was mentioned. It would be nice to have the same feature for code blocks. Thanks.
 

In this announce new feature called "quote collapse" was mentioned. It would be nice to have the same feature for code blocks. Thanks.
 

name — no problems except it was excluded from HTML5 🙂 id — what if user will specify ID which already exists on the page? It could brake some JS-based functionality in cases when JS refers to this id.

We can add official plugins for CKEditor from the repository. And we can create our own plugins. The issue is that HTMLPurifier does not allow to use some HTML attributes whether we add a custom button or not. It would be helpful to have additional configure option for CKEditor:
Allow additional attributes like name, class, id and so on. This can be an additional setting field in ACP like Allowed CSS Classes, where Administrator enter HTML attributes he wants to allow. This way we could use plugins that adds HTML anchor or any additional functionality. I have used it in other CMS and it was very handy.
Example for anchor:
<a name="test" id="test"></a> This is not allowed right now. If you could define name and id as allowed attributes, then we could use anchors out of the box without allowing to edit HTML.
Thank you!

@Mr 13, I know. This was just a suggestion to make it generally available for all admins without hooks. The official link plugin adds both attributes id and name. But both of them are wiped out after saving. I do not really see any security issue with those two attributes. I use link plugin above to format mail and phone links. However anchor is a pain without customization. At the same time anchor is very wide used to add structure to the long pages. E. g. structured articles that Googles like so much at the moment 😏

Hi
We have been doing test migrations and I noticed a huge amount of memory usage from Imagick on our install which reminded me that there is another option, GraphicsMagick which was a branch from Imagick a few years ago.
Generally it runs much faster and lighter than Imagick and also it seems to have less security issues. It does have some limitations over Imagick but most of them seem to be related to more advanced image processing so I *think* they would not be an issue for IPB.
If php was directly calling the Imagic binary rather than the php wrapper you used to be able to directly swap them out and it would mostly work if I recall.
Just a thought.

Well, it's your assumption. No more no less. But what about the diagnostics instead of assumptions? WIll IPS provide informative error instead of just "-200"?
93 frames and 816kb is nothing for GIFs. Most of uploaded GIFs on my forums has a lot more frames and sizes (and a lot of them was uploaded when i used ImageMagic).

As i already said, problem is not related to the count of frames of to the size of the GIF, it just appears with some of GIFs, not matter how large or small they are, or how much frames does they have. I've uploaded bigger GIFs with much more frames and it worked just fine. Played around with timeouts and memory limits, e.t.c. and it does not affected the error with GIFs which has lower size and less frames.
Does not matter, the actual problem is lack of information in the error, that's it.

I have the same issue with some animated GIFs when using ImageMagick, and it does not related to connection speeds or file sizes in my case. Temporarily switched to GD, because did not have a time to investigate this problem yet.

+1 for more diagnostic info in this error.

What about my case, when i get this problem with not large animated GIFs and only with IPS+ImageMagick, while having enough memory and very powerful server?
Any other PHP apps which using ImageMagick (WP, for example) are working just fine on this server with the same GIF files, i have this problem only with IPS.
Tested with this GIF: outline.zip


Any tips about how to diagnose this problem more specifically?

You provided the issue in your reply  "Large animated gif's"  Other software likely uses a different upload method to be honest, and which may be something we can improve on.  
That single image you attached is actually 93 images 😂 which is why you are likely seeing issues as it's pretty large to handle, and GD seems to do a more efficient job in this case on that file type. 

Hello,
Since I allowed upload of images on my forum, more and more users with slow connections are getting this non-descriptive error.
Thing that makes me mad from your side, dear Invision Community, is that you didn't bother to at least add a description to that error.
My findings are that is a thing purely from your side, since my server settings as well as image settings are optimized to the core.
Can someone shed some light on this issue?

It will be mature enough when next Invision Community will be released ;)
Personally i would love to have this feature in IC as soon as possible, because ~83% of my users are using chromium-based browsers, and most of them are on up-to-date versions. It's good enough value for giving them this native feature and use IPS's implementation as Polyfill for other small group of users.

As i already said, it should search not only on tags but also on titles, including localized ones (as it was in 3.x).

As i already said, it should search not only on tags but also on titles, including localized ones (as it was in 3.x).

@webrain_merged
PC:

Mobile:

Download:

Dark mode is neither necessary nor desirable.