Merge branch 'dev' of https://github.com/artf/grapesjs into dev

docs/modules/Commands.md

@@ -164,7 +164,7 @@ run(editor) {
 
 To disable the command use `editor.stopCommand` method, so in our case it'll be `editor.stopCommand('my-command-state')`. As for the `runCommand` you can pass an options object as a second argument and use them in your `stop` method.
 
-Once the command is active, if you try to run `editor.runCommand('my-command-state')` again you'll notice that that the `run` is not triggering. This behavior is useful to prevent executing multiple times the activation process which might lead to an inconsistent state (think about, for instance, having a counter, which should be increased on `run` and decreased on `stop`). If you need to run a command multiple times probably you're dealing with a not stateful command, so try to use it without the `stop` method, but in case you're aware of your application state you can actually force the execution with `editor.runCommand('my-command-state', { force: true })`. The same logic applies to the `stopCommand` method.
+Once the command is active, if you try to run `editor.runCommand('my-command-state')` again you'll notice that the `run` is not triggering. This behavior is useful to prevent executing multiple times the activation process which might lead to an inconsistent state (think about, for instance, having a counter, which should be increased on `run` and decreased on `stop`). If you need to run a command multiple times probably you're dealing with a not stateful command, so try to use it without the `stop` method, but in case you're aware of your application state you can actually force the execution with `editor.runCommand('my-command-state', { force: true })`. The same logic applies to the `stopCommand` method.
 
 <br/>
 
@@ -317,4 +317,4 @@ editor.on('run:my-command-modal:before', options => {
 
 ## Conclusion
 
-The Commands module is quite simple but, at the same time, really powerful if used correctly. So, if you're creating a plugin for GrapesJS, use commands as much as possible, this will allow higher reusability and control over your logic.
+The Commands module is quite simple but, at the same time, really powerful if used correctly. So, if you're creating a plugin for GrapesJS, use commands as much as possible, this will allow higher reusability and control over your logic.

docs/modules/Components.md

@@ -684,10 +684,10 @@ use of them for a more generic use case or also listen to them inside other comp
 
 Let's see below the flow of all hooks:
 
-* **Local hook**: `model.init()` method, executed once the model of the component is initiliazed
+* **Local hook**: `model.init()` method, executed once the model of the component is initialized
 * **Global hook**: `component:create` event, called right after `model.init()`. The model is passed as an argument to the callback function.
   Es. `editor.on('component:create', model => console.log('created', model))`
-* **Local hook**: `view.init()` method, executed once the view of the component is initiliazed
+* **Local hook**: `view.init()` method, executed once the view of the component is initialized
 * **Local hook**: `view.onRender()` method, executed once the component is rendered on the canvas
 * **Global hook**: `component:mount` event, called right after `view.onRender()`. The model is passed as an argument to the callback function.
 * **Local hook**: `model.updated()` method, executes when some property of the model is updated.

docs/modules/Storage.md

@@ -83,6 +83,8 @@ const LandingPage = {
 // ...
 const editor = grapesjs.init({
   ...
+  // If set to true, then the content within the wrapper element overrides the following config,
+  fromElement: false,
   // The `components` accepts HTML string or a JSON of components
   // Here, at first, we check and use components if are already defined, otherwise
   // the HTML string gonna be used