self._editor is null, Cannot read property 'html' of null, Cannot read property 'set' of undefined

[JackTheRyder]

Just wanted to consolidate all the issues as it is the same issue plaguing many of us for a year now. Wouldn't be an issue if we didn't pay for support...

#87

#98

#107

#111

#116

froala/wysiwyg-editor#3719

@imuller @pochocho @gabaum10 @nevaan9 @jyyan @wangjacsi @rcheung9 @yellow1912 @nghialamngoc @t0milee @VAUNT @Centrallatice @Crx4 @jaesung2061

[mcanvar]

I will send this issue link to the support.

[jyyan]

+1

have send this issue link to the support team

[rcheung9]

Will send this link to the support team. Completely unacceptable.

[mcanvar]

Using a single config object on several froala elements cause the exception. The bug added by them to fix in the next editor release and they suggest using separate config objects for each editor.

[rcheung9]

@Crx4 What if you clone the object?

[mcanvar]

@rcheung9 I've tried didn't help then I wrapped froala element with a component(gist). Its property returns a single config object.

[juliarosales]

@Crx4 didn't work for me :(
Waiting for a solution for this issue too

[mcanvar]

@juliarosales I use "vue-froala-wysiwyg": "^3.1.1-1" version, please check your version.

Another workaround:
If you are ok with using different config objects for each of your froala editors, you pass directly as an attribute value:
<froala tag="textarea" :config="{ key: 'your_key', attribution: false }" v-model="froalaValue"></froala>

[juliarosales]

yes I have
"froala-editor": "^3.1.1-2",
and
"vue-froala-wysiwyg": "^3.1.1-1",
<editor :tag="'textarea'" :config=froalaOptions :value="form.primary_concerns" :id="'primary_concerns'" :name="'primary_concerns'"> </editor>

froalaOptions comes from the backend
$froalaOptions = [ 'key' => 'license_key', 'inlineMode' => false, 'charCounterCount' => false, 'immediateVueModelUpdate' => true, 'fileUploadToS3' => $s3Hash, 'imageUploadToS3' => $s3Hash, ];

[mcanvar]

@juliarosales Based on repo README, I only use "vue-froala-wysiwyg" dependency, you can try removing the other and use the gist I provided.

Or, I guess you have PHP backend, you can try passing your string config json as value with JSON.parse().

[arwinvdv]

Same problem here. I created an example:
https://codesandbox.io/s/vue-froala-jqddo
And see here the output: https://jqddo.csb.app/

[t0milee]

The support team got back to me, they are aware of the issue and will resolve it in the next update 3.2 that should go out towards the end of June.

Also in the meantime, I bypassed the issue by not using the Bootstrap modal.

As for the @arwinvdv problem I had a similar issue as well, again related to the same html stuff, not sure what you are trying to do, but when I needed to show/hide the editor based on v-if it was crashing the same for me, so I resorted to dynamically add and remove a CSS class that would do display: none;

[arwinvdv]

@t0milee Thank you for the update.

In my example I try to update custom buttons (see line 37 in App.vue).

[juliarosales]

I followed the recommendation from @Crx4 and I'm passing the config string as json.

<froala :tag="'textarea'" ref="notes" :config={!! json_encode($froalaOptions) !!} v-model="notes" id="notes" name="notes"> </froala>

Also when we are using it inside a vue component in a v-for loop for dynamic elements we are cloning the config.
<froala :tag="'textarea'" :ref="page.template" :config=finalConfig[index] v-model="page.html_content" id="content" name="content" ></froala>

and Inside the mounted hook:

for(let i = 0; i < this.pages.length; i++) { this.finalConfig.push(_.clone(this.froalaOptions)); }

and with this solution we could finally get rid off the annoying error on the console.

[fribbler27]

Similar to @Crx4 and @juliarosales , this worked for me:

<froala :config="JSON.parse(JSON.stringify(editor_config))" v-model="edited_response"></froala>

With this schema editor_config can be in the data or computed portion of the vue module.

[rcheung9]

Still not fixed yet. The workaround is good but this is just sad that we have to resort to this to get a functioning product.

[demianh]

Problem still exists for me with 3.2.3. The JSON.parse/JSON.stringify workaround does not work.

I can only reproduce it with Firefox, when using multiple editors on the same page and the Devtools are closed.

[rhanzak]

Still having this problem in 3.2.6 in Firefox.

JSON.parse/JSON.stringify does not work and not seeing this issue in Chrome.

[IsabelGraciano]

Still not working, any news about this issue?

[dnavamosler]

same problem here

[martinapitakova]

Same problem here.

[maxt91]

Dude, years later and the problem still exists, this license is such a waste of money

[jennysol]

I'm having the same issue in the latest version ( 4.1 ). :(

[mcanvar]

Really, unbelievable.

[maxt91]

The workaround I did was basically using the is mounted pattern. Delay the initialization till after you have mounted the the component. Still ridiculous that I had to do this at all

[fb-sean]

Reading this at the 1.10.2024 really makes me sad how can this be a issue sooo long already and still havnt bean fixed? I have this issue too JSON.parse(JSON.stringify(config)) does not help in any way.

// Edit:
The solution of maxt91 with the mounted delay works fine.