Toggle wysiwyg / code view in Editor

Submitted by stopbit on Tue, 02/28/2017 - 11:21
stopbit's picture
Forums: 
Feature requests

Hi,

I would like to request an improvement feature to the text editor used in H5P activities.

This would we a Code View option, just like that found in the default Moodle Atto Text Editor. 

TinyMCE editor also has this option.

Having the ability to Toggle between wysiwyg and source code view is invaluable in my experience. I've used Moodle for more than 10 years and I've lost count of the number of times this capability has saved my bacon.

Having the ability to manipulate the code allows users to insert custom css styling, adjust Tables, add scripts, link to files outside of the activity, etc.

Being able to refine what is displayed will be a great benefit, giving H5P activities great flexibility and a host of inherent new features in almost every activity.

Thanks

Summary: 
Code view editor
Content types: 
Course Presentation
Issue Status: 
Open
1
0
Supporter votes Members of the Supporter Network can vote for feature requests. When the supporter network has generated sufficient funding for the top voted feature request it will normally be implemented and released. More about the H5P Supporter Network
tim's picture

tim

Wed, 03/01/2017 - 09:45

Great idea. The editor is currently extremely underpowered, especially for serious authors. Having a source code view would probably improve productivity immensely. Perhaps this will be part of a bigger overhaul as many other features are currently lacking such as math symbol support. I'll raise the issue with the core team and hopefully something can be implemented this year. 

- Tim

gregorybarile

Thu, 03/09/2017 - 15:58

I totally agree!

I'm completely stuck with not being able just to create a table in the "Fill in the blanks" module!

This would help a lot

tomaj's picture

tomaj

Fri, 03/10/2017 - 08:57

Hi Gregory,

This post might be of help to you. It's about how to alter the semantics of a content type, so that you might add more buttons .

- Tom

a11yOnline

Tue, 03/14/2017 - 16:21

I understand that having a source code editor could make these tools far more complicated than they are meant to be, but I do really miss having the ability to alter code to get the appearances I want.

fnoks's picture

fnoks

Wed, 03/15/2017 - 08:37

Hi,

We have been discussing suporting plugins for H5P content types. A plugin would have the ability to change the behaviour of an H5P content type. I am not sure when/if this will implemented, but I do see the need for it.

stopbit's picture

stopbit

Wed, 03/15/2017 - 10:59

Hi Fnoks,

Sounds interesting, I'm interested in how this concept works - What kind of behavioural changes and plugins have you discussed?

Is this an alternative approach to adding a code view in the editor?

Thanks

fnoks's picture

fnoks

Thu, 03/16/2017 - 10:25

Hi,

A plugin will be a separate component that e.g. will say "I am a plugin for H5P.Blanks 1.0". This will make the plugin beeing loaded when "Fill in the blanks" is loaded. How a plugin should interface a content type is not discussed much yet, but at least it should be possible to e.g:

  • Change style
  • Act on events/user interactions
  • Change behaviour

I don't think adding a code view in the editor is an approach that will work, since it probably will break when new versions of content types are released.

 

stopbit's picture

stopbit

Thu, 03/16/2017 - 12:39

Hi,

If I understand correctly, it seems the method you describe provides less flexibility than providing a code view in the html editor.

I really would insist a code view editor should not be written-off as there are many benefits. Without a code view editor it can feel like your hands are tied as a content creator.

I don't think the approach you're suggesting could replace a code view editor. Although both concepts would work very nicely with oneanother (as I say, if I understand the concept correctly).

Would the flexibility of the plugin allow for individual customisations for H5P activities or (as it appears to me) the plugin can only customise ALL H5P acitivity types with the same customisations?

Many Thanks

fnoks's picture

fnoks

Wed, 03/22/2017 - 08:56

I see your points, and when I read your first post, I think I really didn't answer your question. Enabling more of the options in the WYSIWYG editor could be done. The most problematic thing is allowing JavaScript to be added because that could lead to security problems.

Another problem with allowing more options in the WYSIWYG is unwanted side-effects. It will certainly make the job testing the different H5P content types a lot more time-consuming.

papi Jo's picture

papi Jo

Wed, 03/22/2017 - 14:25

+1

stopbit's picture

stopbit

Wed, 03/22/2017 - 14:42

Hi Fnoks,

That's right, there are potential issues, however all of these can be overcome. For example who would put a malicious script in their own content? I certainly wouldn't; perhaps some user of my site may do this - well in that case simply deal with it on a role basis - Admins can add scripts, non-admins can't. It's not been a problem using a code view in Moodle in my 10 years experience, it's certainly solved a lot of problems having the capability to tweak style and content/code. Testing needn't take a lot longer due to this code editor - it's really up to the end user/creator to ensure what they change in code works.

The ability to customise content is what we are really talking about, forgoing the obvious security implications, which can all be quite easily dealt with in order to protect a site from malicious use of code etc. Greater design flexibility is needed by many of us using H5P and this is a big restriction for web-savy content creators. Don't simply say it's not right for everyone to have a code editor - the point is, it would be excellent to have for those who want to expand on their content possibilities.

Thanks for listening

fnoks's picture

fnoks

Thu, 03/23/2017 - 22:15

I really do understand the wish for greater design flexibilities. 

H5P is made for sharing and reusing interactive content. Allowing javascript to be added by authors could potentially be exploited to spread malicious code to many sites. You write: "For example who would put a malicious script in their own content". The problem is more that people might add e.g. 3. party scripts without knowing if they contain any problems in terms of security.

You also say: "it's really up to the end user/creator to ensure what they change in code works." I wish you were right, but my experience suggests otherwise. Most authors expect every possible permutation to work - and that is what we are aiming for!

papi Jo's picture

papi Jo

Sat, 03/25/2017 - 09:41

fnoks writes "[stopbit] also say[s]: "it's really up to the end user/creator to ensure what they change in code works." I wish you were right, but my experience suggests otherwise."

Murphy's law applies here. "Anything that can possibly go wrong, does."