Replies: 8 comments 1 reply
-
I have been using the Radzen html editor in my Membership module and it works great it would be good to investigate this I can upload a POC and share with you @sbwalker |
Beta Was this translation helpful? Give feedback.
-
The QuillJS editor has been problematic for me since day one. I've found that even some basic changes in the raw HTML editor mode make the rich html editor mode useless. e.g. After some edits in RAW mode, the preview won't render in rich mode. This then forces me to perform all future edits for that module in raw mode. |
Beta Was this translation helpful? Give feedback.
-
I have been using Radzen html editor for years.... it works good for me! |
Beta Was this translation helpful? Give feedback.
-
From the point of view that the content editor is a different person than a content designer or a web developer. Imagine she/he writes a blog post containing - along with some text - e. g. one or two images, or even a gallery and maybe a table or wants to embed a video or a map. Whatever rich text / Html editor available, his experience trying to add such content will likely not be very good. However it would also be difficult to produce a form (instead of the rich text field) offering the flexibility needed when the content structure isn't that predictable. What would make Oqtane outstanding as a CMS in my eyes would be something like a StreamField in Wagtail. |
Beta Was this translation helpful? Give feedback.
-
I think the HTML editor component should be as simple and lightweight as possible, I like the actual editor based on Quill. |
Beta Was this translation helpful? Give feedback.
-
I haven't had much experience or trouble using the current Html editor (yet). However, in general terms, I am in favour of replacing a JS-based editor with a Blazor native one, therefore avoiding some race conditions I do have encountered when loading the current version. Also, Radzen editor seems to have a richer feature set, more easily customizable and especially, with better image inserting support. |
Beta Was this translation helpful? Give feedback.
-
The raw editor is all I can use currently and have to test/save changes and the WYSIWYG editor is bugged, don't even show. Another issue I have is with CSS loading, I have to enter styles into the RAW editor when working on a project from the Oqtane CMS to update some page content. I like the Radzen approach due to the following:
The issue I have which is related sort of, is the CSS. There is no place in Oqtane to enter custom CSS for the SITE as a whole so I have to edit each page individually if I do not edit the theme files directly. To do this I need to use the RAW editor with An enhancement to go with this new HTML editor would be to create the following features:
Otherwise this is has real pain in the rear for some simple updates/changes. I believe the Radzen HTML editor would probably handle this the best with the RAW Html editor as it would be formatted and with syntax color. I believe this is the best solution going forward. I am also wondering if the two HTML modules should be packages and maybe move the HTML Quill version and the new Radzen version to repo's as a package that is installable if desired and uninstall the default one not being used if you have your own custom one built. |
Beta Was this translation helpful? Give feedback.
-
I agree that the current situation with the HTML editor. The current HTML Editor, based on QuillJS, has served us well, but its text-based approach and limited feature set have become constraints. The sanitization process and conversion to a text-based format, while unique, do not align with the need for a more dynamic and native HTML handling experience. As we consider upgrading to QuillJS 2.0 or exploring other options, it's crucial to weigh the benefits and limitations. Michael Washington's suggestion of the Radzen HTML Editor, especially the standalone component available at HtmlEditorBlazor, seems promising. This component is more feature-rich and aligns well with our need for a native Blazor solution, which could enhance both user experience and developer integration. In addition to exploring specific HTML editors, I believe we should also consider implementing a more flexible HTML/Text provider solution. Here's why: Benefits of an HTML/Text Provider Solution 1. Decoupling and Flexibility: Framework Independence: By using an HTML/Text provider solution, we can decouple the content management system from a specific HTML editor framework. This allows us to swap out or upgrade the editor without significant changes to the overall system. 2. Enhanced Integration: Modular Approach: An HTML/Text provider can serve as a bridge between the core system and various editors. This modular approach simplifies the integration process, making it easier to incorporate new editors as they emerge. 3. Improved User Experience: Feature Richness: Users can benefit from advanced features provided by modern editors that support HTML natively and offer robust text manipulation capabilities. 4. Future-Proofing: Scalability: As our needs grow and new technologies emerge, an HTML/Text provider solution can be extended to support additional functionalities without a complete overhaul. Key Considerations for Implementation
Conclusion I encourage everyone to share their experiences and suggestions regarding alternative HTML editors and the concept of an HTML/Text provider. Understanding the specific pain points and desired features will help us make an informed decision that benefits both the end-users and developers. |
Beta Was this translation helpful? Give feedback.
-
In the last monthly Development Meeting there was a discussion about the Rich Text (HTML) Editor...
The current HTML Editor is based on QuillJS, an open source JavaScript component which was fairly popular 3-4 years ago. QuillJS has a different philosophy than most HTML Editors - it uses a text-based approach rather than a DOM-based approach. This is means it does not support HTML as natively as other HTML Editors... in fact, it "sanitizes" HTML and converts it into a text-based format which it can interpret. By default it does not have as many features as some other HTML editors. QuillJS recently released a 2.0 version and there was a suggestion that Oqtane should upgrade... however there was also a discussion that there may be other HTML Editors which may be a better choice for the future.
Michael Washington made a suggestion about using the HTML Editor from Radzen. It is a native Blazor component that someone extracted as a standalone component here: https://github.com/Behrouz-Goudarzi/HtmlEditorBlazor. It is certainly more feature-rich than QuillJS.
Before moving forward, I would like to get some feedback from the community on the topic of HTML Editors... specifically what are the pain points with the current QuillJS editor, what alternative HTML Editors should be considered and why, etc...
Ultimately, an HTML Editor is a critical component for managing content, so it is important for Oqtane to provide a powerful and consistent experience for end users... and a simple integration story for developers.
Beta Was this translation helpful? Give feedback.
All reactions