G17 Media

When will we see a public alpha test?

I am out. I'll wait until I can test the editor integration on IPS5. Then I can say what I miss. Or I do not miss anything and am unlimited happy. Make me happy, IPS. This would be the best solution for both of us. 😉 

The alpha testing group probably mostly consists of those who are at least experts or well-versed in using web technology and quick learners. @13.'s suggestion is probably more aligned with how I see normal users using it.

No disrespect but that's a stupid weird argument. Alpha testers are extremely tech savvy users, they don't represent the common users in any way.

Any person who OWNS A WEBSITE/FORUM is not a common user... None of the users in this community is a common user IMO.

I agree with @Omri Amos.
In fact, even by @Matt's definition: 
That means Alpha testers are forum owners. We have experience running a website that contains a forum. 
By contrast, many common users have no clue whatsoever how to use a forum. Some have only a limited understanding of the English language.
Sometimes, I get emails with questions. When I reply that they can't email me their questions, and that they have to post the questions in the forum, they tell me "I don't know where to start, I don't understand how the forum works." 
Another example: many, many new members don't know what "Title" means when they post their first topic, so they enter their username in the "Title" field. 
Your customers (our peers) know better. We have a decent grasp of what a forum is, how it works, and what a topic title is. Don't overestimate most common forum users. Many of them have only limited Facebook or Twitter experience, but zero forum experience, and get lost very quickly. 
I agree that the arrow buttons are confusing (I first encountered similar arrow buttons on a forum powered by Kunena, and at first I couldn't make any sense of them myself, despite my years of experience running a forum). The idea of a clickable interactive area by @13. is a much more intuitive solution. 

Indeed, the requests for custom styling buttons or HTML source code are for the admin, or article authors (in the Pages section), not common users. 
The discussion on common users was related to the functionality to add a new line below a quote block. 
No one made that argument. You're mixing up two different discussions. 
 

What items? 
It is a bug, Jim. You are speaking of crawling efficiency all the time. In this case, you give search engines a suggestion to index something, that they should not index. It is not effective. It spends crawling quota for nothing. 😞

The alpha testing group probably mostly consists of those who are at least experts or well-versed in using web technology and quick learners. @13.'s suggestion is probably more aligned with how I see normal users using it.

The alpha testing group probably mostly consists of those who are at least experts or well-versed in using web technology and quick learners. @13.'s suggestion is probably more aligned with how I see normal users using it.

The alpha testing group probably mostly consists of those who are at least experts or well-versed in using web technology and quick learners. @13.'s suggestion is probably more aligned with how I see normal users using it.

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either 
I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

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.

Source editing definitely a must for admins. Somethings we cannot embed without this functionality.

as admin use it for the below
to embed cms blocks via the 'external embed' method
to embed 3rd party website embeds/iframes
not just for forum posts but for nearly all content items such as articles, events etc
 

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.

For records in Pages.
Tables Removing tags, that I cannot remove or repair other ways, like <abbr>-tags Adding styles like ipsButton or ipsMessage

I also use source mode all the time. Sometimes to inspect and clean up user posts, but like Sonya mostly for Pages articles. Custom classes, custom embeds …

As above, source mode has been removed. Modern editors (all of them) manage markup differently. If you added something the editor couldn't handle via HTML, then it would just remove the unsupported code when you hit edit.

Source mode was added back when we had BBCode and it was.. less than perfect in how it handled it, so it allowed admins to go in and edit it to fix it. Likewise, CKEditor was such a pain to write plugins for, it was easier to just say "oh, use source mode to add stuff". Tiptap is much easier to develop for.

What do you use source mode for?

I can say supporting multiple editor frameworks is not something we're likely to consider. Editors today are not copy/paste bundles, and there is a lot of stuff we built on top of the core frameworks.
Thousands of lines of code which use the Tiptap and Prosemirror APIs would need to be translated, then all the edge cases would need to be sorted out. After migrating from CKEditor4 to CKEditor5, then from CKEditor5 to Tiptap, I can definitively say from experience that is a lot of work, and there are always differences in how features are actually implemented. And that's not even covering extensions which would be a pain to make compatible.
This is why sticking to one editor is the way to go to provide you and all our customers top notch features. We won't lose days, or potentially even weeks, going back and forth to double implement and test features as they come out, and can guarantee things will "work".
As a side note, I actually do remember Lexical from when we initially compared editors. We didn't find it to be a great option because it's very new: they are still only on version 0.15.0.
Also, not too long before Lexical came out, Facebook first created Draft.js, then abandoned it when it was only a couple years old before version 1 ever came out. In fact, I think a lot of the docs that are now available for Lexical didn't even exist 6 months back.

Not to discount your request, but this is likely highly unlikely to happen. Changing editors much less building the capability to support multiple editors is a HUGE undertaking and touches nearly every part of the suite. 

It was nearly 6 months of development effort so far to replace ckeditor 4 and is not fully done yet. So just dropping in another random editor just because it might be cool to have two most likely is not in the cards anytime soon.  If this is important for you, it might be better to engage a 3rd party resource developer. 

More downtime on May 8th (45mn). 
More downtime just now. 
Very frustrated Cloud customer. The Invision software is amazing, but the Cloud hosting is unreliable. 

You could literally just fire a proper request to the GraphQL endpoint instead of including the IPS framework and instead of utilizing it direct, using then the GraphQL class. 

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.

You wouldn't other than seeing it appear in blogs or release notes. Its important to know that suggestions do not necessarily mean they will be added. In many cases they won't, and in others it may be a considerable amount of time before they are, as they would be things we would put into our over all goals for the product.