My editors want to have an ability to edit raw html within editor.
For example, we can have simple list markup:
<ul>
<li>Some text<li>
</ul>
Or with custom classes and event tags:
<ul>
<li class="my_class">Some text
<span class="special">Some additional info</span>
<li>
</ul>
And so on.
I know that built-in Draftail doesnt support html editing.
But using third-party editor comes with problem:
Losing integration with system. For example, i cant just put image like with draftail. Or, preview mode cant handle all functionality of third-party editor.
So, maybe someone has working solution for this situation.
I thought about using special StreamField panels, but it seems to be overhead of blocks. Dont like this idea of having lots of blocks with little differences
Wagtail does not support raw HTML editing within the page editor out of the box intentionally. The philosophy (zen) of Wagtail is to help editors and developers 'wear the right hat' when working in Wagtail.
HTML editing is usually best provided to developers, where there is an expected knowledge of what is required for things like accessibility, security and the benefit of tooling (like git).
However, if HTML editing is a must, you will probably need to build your own editor field for that purpose or find a suitable package that works with HTML markup such as django-markupfield. Adding image/snippet/page chooser functionality however will have to be built for whatever you end up using. You may also want to look at the Wagtail markdown package either as an alternative to HTML or a starting point, it allows for a syntax of linking to pages/images.
Wagtail lets you use any kind of Django field or widget with the FieldPanel.
Please ensure you consider all the risks when implementing this feature, such as accessible HTML (e.g. heading levels), security (disallow some tags such as script tags), malformed HTML leaking into the rendered template and of course the end user experience.
At the end i made my own solution
Simple rewrite some methods in wagtail`s Html DbWhiteLister and HtmlConverter.
This gives me an opportunity to allow any tags with any attributes.
https://github.com/Chenger1/wagtailtinymce.-Full-Rich-Text-Editor
Related
I'm using the free JS plugin from tinymce and interested in preventing an HTML injection with the tinymce text editor.
I've added this property to the INIT:
invalid_elements: 'script' (just for this example)
However nothing happens. The editor still "accepts" the script tag and pass it on.
I looked at https://www.tiny.cloud/docs/tinymce/6/content-filtering/#invalid_elements and it should work but I don't see any change once it's added.
Am I doing something wrong?
Is there a way to limit some HTML elements with this editor?
Any other tips on how to use that editor and prevent the malicious HTML..?
TinyMCE certainly has a variety of configuration options to help you control what content is created in the editor but you can never assume that data provided to you client side is "clean" or "safe". Nefarious people can bypass your front end and all of its validation if their goal is to cause harm to your system.
You should always configure your front end appropriately. TinyMCE has a variety of configuration options to assist with content filtering/validation (https://www.tiny.cloud/docs/configure/content-filtering/) to only allow those types of tags you want created, etc including:
https://www.tiny.cloud/docs/configure/content-filtering/#valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#extended_valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#valid_children
https://www.tiny.cloud/docs/configure/content-filtering/#schema
https://www.tiny.cloud/docs/configure/content-filtering/#invalid_elements
However, regardless of the front end design, you should always re-check submitted content on the server to ensure it is safe. There is simply no way around that need. What constitutes "safe" is likely a business decision based on what your application does and who uses it.
There are many different libraries you can use server side to do this sort of validation/cleansing so depending on your specific server side setup you can find libraries that allow you to "sanitize/purify" the submitted HTML.
I would note that TinyMCE (by default) should not allow <script> tags in your content so it is likely that such behavior could be due to your current configuration.
Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.
I am thinking of converting my forum input textarea exclusively to TinyMCE HTML editor. I already have both options but it is a pain maintaining both and inserting images in textarea needs preview etc...
This is more of a general question. Do you think it is safe to include HTML editor (with all the safety measures like paste only text, filter for html not allowed etc...) as the only kind of editor on a forum? It's 2011 and machines are generally fast, connection are better.
What are the downsides of using HTMl editor instead of text field? I can not imagine a blog CMS to have "normal" textarea for input.
But for some reason on forums I do not see many html editors... Even the TinyMCE site has a textarea for their editor. So is there really something to watch out for and a no go...?
I know it is more of a phylosophical question, but I guess you have experience with forums, blogs, etc...
My site is about cooking and beeing able to insert pictures (and upload them) the easy way seems to be a big plus for our home cooks ;-)
If you don't consider security (you'll need to filter the HTML input on the server side so it won't contain anything dangerous), there's only the user experience left for consideration. On a forum you write text most of the time. There's seldom any use for more functionality than bold, italics and images. The solution used here on Stack Overflow addresses this by having a very limited set of functions, and applying it in the textarea with a sane markup language.
Other forums either use old software or didn't think the improved user experience was worth the effort. The textarea-only solution fits most forums well enough since most of the input is text-only anyway.
I do think you would benefit from HTML input. Make sure that only allowed HTML can be sent though, since the user can circumvent everything on the client side.
TinyMCE uses Javascript to add functionality to an existing textarea. If Javascript is disabled, then the user will be presented with a normal textarea anyway.
I would say it's relatively safe, as long as all input from the user is validated on the server before it's used for anything.
I have been looking into why WYSIWYG editors are bad for content creation. The most common reason given is that they output incorrect html. But what if I use editors with reduced functionality?
My requirements are only the ability to italicize, make text bold, create ordered/unordered lists and (maybe at a later date) add inline images.
My users will hopefully be 'persistent' users (small numbers of laypersons using the app frequently)
In this context how do I choose between Markdown (WMD editor) & a stripped down WYSIWYG editor. How would page performance be affected with each? I consider fidelity & reproduciblity of data to be important.
You choose by considering your audience. Wiki markup and markdown is for geeks. Your customers sound like they're probably not geeks so I would suggest CKEditor or Twiki-style editor (good, simple Wysiwyg UI) for non-geek users.
Basic concern: Why force lay-people to learn a markup language when solid alternatives exist?
See the Custom Toolbar editor in this CKEditor demo. Or check out TinyMCE.
OK, I tested both.
Even for my basic formatting requirements, CKEditor generated quite ghastly html
Now this is the input
This actually appears to be better
I hope users understand what we are doing
Lets see
But in the meantime
CKEditor Output
<p> This actually appears to be better</p>
<p> I hope users understand what we are doing</p>
<p> Lets see</p>
<p> </p>
<p> But in the meantime</p>
And Markdown Output
<p>This actually appears to be better <br>
I hope users understand what we are doing <br>
Lets see</p>
<p>But in the meantime</p>
Now if this is the difference between these two for the most basic formatting (linebreaks and paragraphs), what will it be like in a 200 word submission. I think most users will need to know only this
For line breaks, two SPACES and hit ENTER.
For new paragraphs, hit ENTER twice
The rest of the stuff could be learnt incrementally
Is it that hard to engineer a 'basic' WYSIWYG editor?
EDIT
After adding these to config.js above problem is solved
config.enterMode = CKEDITOR.ENTER_BR;
config.shiftEnterMode = CKEDITOR.ENTER_P;
I've currently got TinyMCE incorporated into the backend editor of a simple blogging/page-editing app, but I'm extremely unhappy with the HTML code it creates. It does all sorts of messy things like:
Adding inline style information to span tags that you can't ever find to get rid of without editing the HTML directly.
Nesting tags in nonsense ways (e.g. <p><strong><p><span>some text</span></p><strong></p> just to make something bold.)
Adding empty <p> </p> lines where they don't belong and I'm not trying to create blank lines.
EDIT: I've looked at lists of the other editors out there (including on SO), but I want to know if people firsthand have had better luck getting clean code out of their wysiwyg editors.
Any recommendations for one that outputs better code behind the scenes?
How about a rather drastic alternative, and using a WYMIWYG (What You Mean is What You Get) editor rather that another WYSIWYG editor. That way the author is in full control of the schematic markup as well as the content he/she is entering.
Unfortunately I haven't found one that is as feature rich and usable as tinyMCE, but it seems to have come a long way - see http://www.wymeditor.org/demo/
Use HTML purifier before saving the content into the database.
HTML Purifier
I found JoomlaFCK to be a very good alternative to Tiny MCE.
Hope you like it.
bye
BTW I know it is an old thread but someone might use it. ;)