13.

Those elements are not intuitive for inexperienced users (i.e., almost all users).
It would be much more intuitive and easy to use if there were an area where users could click to start writing in a new empty paragraph. This area should always be placed right after the existing content in the editor:

If this is implemented, even inexperienced users won't get stuck in a state where they can't add a new line and don't know where to search for a button to do that.

For example, I add a class to an embedded YouTube video to center it. The embedded block does not respond to the centering buttons from editor.

Love it! Although I am concerned my members will write their entire posts in H1 😄

Hi Kudos to IPB Team they have added tiptap as new editor for IPB5 it looks amazing. But it would be really great if team could also add support for Lexical Editor so admin could choose between tiptap and Lexical for their communities 


Here is Playground Demo Link

https://playground.lexical.dev/


Here some noticeable feature about Lexical Editor:
MIT License (Developed by Facebook Core React Team)
Its headless and built-in excalidraw 
Lets you convert the html content into JSON and vice versa.
React 18+ support. Lexical is very minimal. it's closer to an API for a virtual DOM around content-editable than it is to a text editor framework. That's pretty low-level
Lexical is 22KB gzip. The rest is shipped as plugins that users can seamless plug and play (as they're as independent from the rest, including the real-time collaboration plugin) and you only pay the cost of what you need 

and many more out of box !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Here is Short Video Demo Link
https://i.imgur.com/kCPmiBd.mp4

Please submit your comments and Likes so this feature get enough votes to be added 🙂

Thanks
Dia ^_^

@Matt Finger Thanks for your inputs, I totally agree what you mentioned above, Here My Two Cents:

Only problem with Tiptap is, As they are very small startup as compared to Billion Dollars Facebook. They just recently raised some seed round and they have been surviving by selling Licenses for PRO Features which are freely available in other Text Editors. Sooner or Later there will be less updates for Free Version to push the users to buy premium licenses which will be not good for long term sustainability of IPB Development & IPB Based Communities.

it is true Facebook killed Draft.js ( But Lots of Startups Shut Down Too)
Lexical Now is what Draft.js wanted to be. Lots of developments going on with Lexical right now. Moreover Facebook has very good track records as compared to others to develop Open Source Projects which have been become industry standards.
Thanks!!

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown).
Each page must have a unique H1.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown).
Each page must have a unique H1.

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this.
Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity.
Now:
Should be:

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this.
Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity.
Now:
Should be:

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

Transitioning from "Display Name or Email" to solely "Email" logins isn't seamless for users who have stored their login credentials using their Display Name.
They repeatedly click "Sign In" without comprehending the issue when login attempts fail.
Adding a simple tooltip to the login field when the entered value is not an email would greatly improve UX in this case. This way, users can easily see and switch without encountering further problems.
Example:

Also, it would be a good idea to keep the "Sign in" button in this form dusabled until both fields are valid (email is validated and password is not empty), so users won't waste their login attempts with this kind of little mistake.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

Hi there,

We unfortunately have come across some abuse of the private message / conversation feature.

What happens:
Users can message each other, then block the others / themselves from a conversation. As the conversation then has no participants, it's deleted and we have no trace, making it difficult to moderate.

Expected behaviour:
When there are only two participants, users shouldn't be able to remove the other member (to cause the deletion), or there needs to be some way of verifying that the PM did exist as a forum admin.
 
How to reproduce:

Here is the steps to reproduce from our team:
 
Log into AccountA - send a PM to AccountB Within the PM UI, select AccountB from the list of participants and select "Remove from conversation". Delete the message from your inbox as AccountA. Log into AccountB - see that this PM "never existed" but you still have an email confirming it was sent to you.  
The class / method in question is
Messenger\Conversation::deauthorize


If you need any more information, please let us know.

The ideal solution would be if any photo/video format could be converted on the fly to something useable, the way Facebook does it. 

Hello !
In future releases, will it be possible to display .avif images directly in messages ?

At the moment, the .avif file is displayed as an attachment, even though the system saves it perfectly and my browser (obviously) supports this format.
I think that allowing this format in the Gallery application (as well as in the others, I haven't checked) would be a good thing.
That'll be all! 😜

currently all browsers support avif by default already, so maybe its the right time to add support into invision community apps 🤔
and not only by showing avif images directly in posts, but i cant set avif images as grid card images as well 😞

and also image settings should be improved 🤔 theres quite a big difference between same quality value accross different formats - and avif is missing there as well

i also use some external images embedded in a code and with same level of visual quality i squeezed them with avif from 2,6 MB to 0,6 MB which is quite significant saving 🤔
and not speaking about all images in theme resources which still use almost 30 years old formats, mostly png 🤐
so please, do something about it 😔

Yes. This site has been slow to load pages regardless. But with a browser, you get feedback. With the PWA, on iOS, at least, you get almost no indication that the request has been made and the PWA is waiting for the response from the server. 
So, I end up clicking multiple times, probably making the server even more overloaded. 
I’m hoping Invision devs are spending a lot of time using the PWA to test and develop v5 and the PWA will be more reactive. 
That is, I’m hoping the PWA is a high priority for v5, instead of an afterthought as it is in v4.