Linux-Is-Best

16 hours ago, beats23 said:

What's wrong with CKeditor, what would you get from other editors that CKeditor doesn't have?

CKeditor works fine for me. I would like the IPS to update it to V5 the latest and for it to be compatible with CKeditor plugins.

Speaking personally, from my own unique perspective. I manage an active community overseas that could be classified as servicing within an emerging developing country. Mobile devices are the primary source of medium there to access both the world wide web and our community. It is important to consider the responsiveness, performance, and compatibility of the software with the build of those mobile devices. I was aware CKEditor 4 did not match our required needs and waited with anticipation for the development and release of CKEditor 5. It had to do with another project. Unfortunately, the inflated hype surrounding CKEditor 5 was most disappointing, to be more marketing and less substance of functionality. I am further disappointed to say that has not changed since the initial release of CKEditor 5.

Invision has been taking some impressive and bold initiative with their development. They seem willing to expand the realm of online community development and I have found it most impressive with their continued ability to, metaphorically, “step out of the box and think differently.” However, beyond testing the functionality and versatility of the software, I could not actively deploy Invision into any meaningful live community with the current limitation the CKEditor imposes on mobile devices. I suppose if mobile was not such a required need, I would have done so two (2) years ago.

While I would certainly like to see it happen sooner, around the time of the end of support of CKEditor 4. I hope in the far future, around the time of Invision 5.0, the development will revisit the possibility of implementing an editor that does not hinder mobile browsing.

15 hours ago, Matt said:

This is probably what we'll do.

That would be disappointing. I have used CKEditor 4 and 5. It is irreconcilable, incompatible with our needs and not mobile web friendly in terms of usability and performance. I would see it as a missed opportunity to improve and better Invision’s future. While CKEditor may have once been the mainstream web editor of choice; I understand and sympathize with the reasoning on why many developments no longer use the editor.

It is, of course, your development and your vision, but I would urge you to reconsider and give it further thought.

Hello everyone. I hope and trust you are all doing well.

It has been a little more than a year since I initially made my inquiry. CKEditor 4 is still on track for the end of product life support this coming 2023. I initially made my inquiry and suggestion for the possibility of a new editor last year, while we were two (2) years away. Plenty of time to give some serious thought and consideration. It is 2022, and we still have until next year, so there is no rush. And even after CKEditor 4 reaches its end of life, I imagine the final patched release can hold us over for a little while after.

That said, the clock to that moment is still ticking away, so I thought I refresh the spirit of the discussion with a little reminder. Any alternative to CKEditor in the future would be most certainly welcomed. I have listed a few suggestions in my original post on page one. But I know there is a wide variety of alternative editors out there. If you know of one you believe would make an even better fit, please share with the community. It could be beneficial to the community and the development of Invsion’s future products and services.

As always, I thank you for your time and consideration. I wish you all the very best. 😊

Google and their wisdom are making it harder for people to leech off of them. I cannot say I blame. If you're setting up e-mails, you really should not depend on Google cache.

Another thing you should know. Gmail is testing a new "feature" concerning ad-blocking. If you see broken e-mails while using Gmail, have you tried to disable your ad-blocker?

Add the following to your .htaccess file

    # BEGIN GZIP COMPRESSION
    <IfModulemod_gzip.c>
    mod_gzip_onYes
    mod_gzip_dechunkYes
    mod_gzip_item_includefile.(html?|txt|css|js|php|pl)$
    mod_gzip_item_includehandler^cgi-script$
    mod_gzip_item_includemime^text/.*
    mod_gzip_item_includemime^application/x-javascript.*
    mod_gzip_item_excludemime^image/.*
    mod_gzip_item_excluderspheader^Content-Encoding:.*gzip.*
    </IfModule>
    # END GZIP COMPRESSION

Or if you were using Nginx (for future reference), you would add this to your config file (nothing you need to worry about, since you are using Apache).

    gzipon;
    gzip_comp_level2;
    gzip_http_version1.0;
    gzip_proxied any;
    gzip_min_length1100;
    gzip_buffers168k;
    gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_varyon;

1 hour ago, Nathan Explosion said:

OK

So no clues on what is causing it (or how to fix it)?

4 hours ago, Nathan Explosion said:

I'll ask the obvious question...are you using the correct dev tools for the installed version of software?

Also, I personally wouldn't do IN_DEV on what appears to be a live site, even though you have it as your own test site. Do development on a localhost installation: DEV -> TEST -> PRODUCTION

 

My test site will always be a live site, as it will be my intention in the future to purchase a 2nd license for actual production. Localhost is not a solution I'll be looking to use as I would want my development in a live working environment.

YES, I am using the 4.6 developer tools.

4 hours ago, Ryan Ashbrook said:

This - we were a bit busy, so we weren't able to update the Developer Tools immediately for 4.6. Try re-downloading them.

YES, I am using the 4.6 developer tools.

2 minutes ago, SUBRTX said:

how about third party plugins compatibility?

Since we are on the topic. I know that @Real Mythotical will soon have his 4.6 running on the latest PHP v8 setup and maybe available to hire.

 I was online this morning and noticed the upgrade page here on Invision. But I think my 1st clue that we were on the final release was the bug tracker soon vanished afterward. 😅

I am still waiting on the CKEditor v4 fix that will resolve Mozilla Firefox Mobile. I figure it will be a few months before CKEditor fixes that (that's not an Invision issue, but still).  I, of course, also need to figure out why IN_DEV does not work for me.  For now, 4.6 is something for me to play with and play with I shall.

The sytlesheet was not loaded because its MIME type, “text/html”, is not “text/css”.

 The obvious cause when viewing my browser's web tools (I use Mozilla Firefox) is that the correct stylesheet is not loading. However, it is not browser-specific, as I experience this when using Brave Browser too. Although, that does not explain why, and I am unsure how to resolve this issue (other than to disable IN_DEV).

The good folks of Invision's development team inform me this is not a bug with the current Invision Community 4.6 beta (still current in final release too). Nevertheless, I am currently experiencing an interesting issue that causes the page not to render, as shown in the screenshot. This only happens when IN_DEV is enabled.

You can see for yourself at my public testing site: https://domaintaken.org/d/

I am curious if anyone has any clues on how to resolve this issue. As always, thank you kindly for your time and consideration. 😀

5 hours ago, Arantor said:

Honestly, that's not what happens in practice. The majority will simply use and grow to work with whatever the default is set to, even if the default is a functionally inferior version, as long as the minimum feature set for creators is maintained.

My source for this is Moodle - which made a transition from TinyMCE to its own home-grown editor Atto a few years ago. While inferior functionally (objectively) compared to the legacy version of TinyMCE they were using, the reality is that Atto did enough to support most things that people needed, and the community plugged the remaining holes as they saw it.

My source for the other end of the scale is one of the Moodle derivatives, which followed the TinyMCE -> Atto route and in the last couple of versions introduced their own editor to replace Atto, called Weka. All three editors remain available, but Weka provides zero table support which is a deal-breaker for some content creators. (Their justification is that they intend content to be consumed by mobile and their mobile app does not support tables.)

Basically as long as whatever editor is not so broken that it's deemed unusable by the majority, whatever the vendor does will just be accepted because people will generally move with change.

A new editor, in whatever capacity, is a hefty undertaking to consider not only users' needs (all sets of users) but also to consider security of whatever formatting is being done, as well as side functionality such as uploaded/embedded media.

I will be perfectly content with nearly any editor outside of CKEditor.  It feels worth repeating, but both v4 and v5 I find inadequate for both the front end and back end, so nearly anything would be an improvement.  As you pointed out, and as others have noted, changing to v5 or any other editor will be a significant change regardless (either way).  While CKEditor would argue that v5 was a near rewrite or complete rewrite (I forget which), it's still more or less the same editor by the same development, making many of the same mistakes (and issues). That is too bad because I did buy into all the hype three (3) years ago (2018) when they release v5.

But I digress.  I do like your alternative viewpoint. The idea of making it so the system was "plug and play." If you could swap out the editor as nearly as easily as you could an add-on, that would indeed be impressive. While I did initially say, I have no particular personal preference beyond just replacing CKEditor. If I could have my pick, I would likely jump onto Redactor Editor.

14 hours ago, Matt said:

We have considered this and we would only make it so the member could request it, but not actually do it. There'd need to be a cooling off period, etc. Easy in the heat of the moment to delete everything and then ask for backups the next day.

 

A cooling period would be best if it did happen automatically, but only after "X" many days, and they had the option to cancel beforehand. That would give the members time to cool off and change their minds or commit to their choice. Ideally, not requiring staff involvement would be preferred (in my opinion).

15 hours ago, IP-Gamers said:

This can already be done using third-party modules.

The request was to include this into the core and away from 3rd party. 😉

It would be perfectly acceptable for this to be a feature that the admin could enable or disable, though—allowing you to decide what you believe is best for your community.

3 minutes ago, Stuart Silvester said:

This would be a permission not a group setting, click the padlock icon there

I assumed the permission would have been available when you clicked on to edit the group.  Little details, eh? lol 😉

Just now, Nathan Explosion said:

Look at the WHERE people post as opposed to the WHO...

Thank you both @Nathan Explosion and @Square Wheels for your help.

13 minutes ago, Square Wheels said:

While you wait?

🤔 That's worded in an odd way.  But OK.  -- Thank you.

But in the guest group, where is the option to allow you to post? I see no option in

/?app=core&module=members&controller=groups  > Guest

I wish for the option (in a future release) to allow members to delete their own accounts. As easy as it is for someone to join, they should also have the option to leave. When doing so, their content should be reassigned as "guest."

I wish for the option (in a future release) to allow guest posting. In our modern age, when I say 'forum,' many younger adults roll their eyes and envision a lengthy registration process so that they can post their thoughts and opinions.  I have the experience of growth and productivity by allowing guests to post, who often join after, having already enjoyed the experience of my community (risk-free).  I believe this option would benefit others.

I wish for the option (in a future release) to disable any and all IP address logging.  In 2021 folks change IP addresses as easily as opening a new browser window tab.  I see no point, and it only slows down the site to resolve addresses while adding more to the database. 

I wish for the option (in a future release) to disable any and all outgoing e-mails from the system. Have you lost your password? Make a new account. Want to be notified? Log in and check your notifications. The ideal setup would be for there to be no outgoing e-mail at all. I notice there is already the option not requiring e-mail confirmation when registering (that's a good start).

On 5/18/2021 at 1:54 PM, Arantor said:

the question is whether you care most about the creators and giving them all the options, or the commenters on content.

Yes (both). 😉

Generally, I envision something modern, updated regularly for both browser compatibility and fixes (including mobile use), and something that can be developed around reasonably effortlessly (both for Invision devs and 3rd party). CKEditor does not fit that bill.  There are many alternatives, and I hope when Invision Community 5.0 is on the table, a new editor will be considered.

On 5/18/2021 at 1:54 PM, Arantor said:

Tell you what I'd do at this point: I'd make it pluggable and let users decide what they want to use, since they all interchange raw HTML at this point, why not just let the site admins pick which one(s) they want to use - allow for CKEditor 5 for admins, and I dunno, QuillJS for regular users? (Quill has the advantage that it's deliberately set up to have a limited surface area and focus on what it offers rather than trying to be rich and detailed)

As cool as I think that would be, I question how easy that would be to support. The consumer (you and I) would love it. But I cannot imagine Invison support would feel too good every time someone changed editors and discovered an issue. I imagine they would spend countless time trying to determine whether the problem was with their code or one of several editors and how and where the issue lay.  But I do like the idea, even though I imagine it could be a nightmare for support. 🙃

On 5/18/2021 at 2:31 PM, Matt said:

I'd go back to plain text with Markdown.

 

One thing we do want to do is do something extra for Pages. The functions you need for most topics/replies is vastly different to what you will need for pages construction.

A markdown editor would be an acceptable alternative https://stackedit.io/ 

demo: https://stackedit.io/app

1 hour ago, Ryan Ashbrook said:

That's fair - however, I should note that the handling of banned members has not changed between the two versions.

I am sure the handling of the privacy settings has not changed either, but that hasn't stopped my online status from changing on its own. With respect, bugs happen. They are not intentional, and no one means for them to come to pass.

4.6 is currently a public alpha here on the live support site. Before it reaches a public beta, I intended to be helpful and perhaps a little useful in tracking down all that I can. It is something I generally love doing during my free time (test pre-release software). Everyone has to have a hobby, right? 

I had presumed to do so (here) would be welcomed as it could aid in releasing a more stable product once completed. But I am gathering you see my request as a bit unusual, and I do apologize. 

Thanks for the follow-up. And as always, for your time and consideration. 😀

1 hour ago, Ryan Ashbrook said:

I'd recommend using the demo instead: https://invisioncommunity.com/demo

 The demo is not using 4.6.  I checked before making my unusual request. 😉