Azragh

@andreasmuench would make it a little more specific:

.lazyblocks-component-icon-picker-content .components-popover__content {
  width: 300px;
}

• This reply was modified 4 years ago by Azragh.

But if I have only activated the Classic Editor, the line breaks remain? As far as I understand, the functions “fix_post_content” and “fix_wysiwyg_content” in the PHP file also deal with the preservation of line breaks…

But anyway, since the problem only occurs locally after several tests, I can live with it, although I wonder what the difference is to a normal server environment (XAMPP / PHP is up to date).

The only thing that still worries me a bit is this error message: “Deprecated TinyMCE API call: <target>.onNodeChange.add(..)”, since this function also occurs in the plugin code.

I was told by my programmer that the error description must have been misunderstood due to my poor English. By “markup gone” I mean that the “structuring” in the markup is lost. All linebreaks and indents in the HTML text are removed. The HTML tags themselves remain.

As it looks, however, this is only the case in local development environments (XAMPP). I’ll take a closer look when I find the time.

The only other plugin activated is Classic Editor. I’ve tested it on a local, blank WP installation with the twentytwentyone theme so I think you should be able to reproduce that. The problem is, I’m not really a programmer – I am only a full stack developer with basic knowledge of PHP and JS – my last PR was kind of a stroke of luck..

I would really appreciate it if you could take a look at this.

Edit: Just recognized something new: It only happens, when you don’t edit something in the visual tab – you have to edit something in text view, change to visual and save. If you then switch back to the text tab markup is gone. Weird thing is, if you then press F5 the markup is there again ..

• This reply was modified 4 years ago by Azragh.

Yes. At least if there’s a wrapper with data-align=”full”, “wide” or “center”. I don’t know how left and right behave in this context or if there are any default blocks which rely on these classes in backend, but this shouldn’t be an issue for custom blocks.

Nope, has nothing to do with editor styles. If I enable Gutenberg, I get these inline styles on .lazyblocks-component-icon-picker-list-wrap:

    box-sizing: border-box;
    direction: ltr;
    height: 961px;
    position: relative;
    width: 24px;
    will-change: transform;
    overflow: auto;

• This reply was modified 4 years, 1 month ago by Azragh.

I get the same error (Chrome), but only if the Gutenberg plugin is enabled. I think it has something to do with my own editor styles – looking further into it.

I just recognized that embeds don’t work proberly in gutenberg 9.7.0 too (if I allow to switch editors). Youtube videos work but Twitter, Spotify, Issuu, .. just don’t. Those links result in an empty preview box. If I omit the “s” in “https” embed links create a preview, but this cannot be selected by mouse (you’ve got to use the block navigation or push some content arount the embed, then you can select it).

If I disable Classic Editor everything is fine, apart from the fact that I would actually like to continue using it ..

Yes, removing the classes from .wpcf7-response-output forced me to update all of my individual themes (about 150 or so), cause I included the styles with SCSS – in my case this caused only visual issues but fixing this was a litte bit annoying anyway. ??

I meant without filling in a search term.. Strangely I’m not able to reproduce it atm, maybe I just misconfigured something ??

Ich nahm auch an, dass Updates hier nichts ?ndern dürften, war aber die einzige Erkl?rung die mir auf Anhieb in den Sinn gekommen ist. Nein, wir haben das Plugin in seinem Ursprungszustand gelassen / nur mit den vorhandenen Einstellungen im Backend gearbeitet. Mit “Beitr?ge werden nicht mehr angezeigt” meinte ich nicht die regul?ren Beitr?ge, sondern die (als nicht besonders markierten) Einsatzberichte – hab’s etwas ungünstig formuliert.

Bis jetzt ist’s aber auch nicht mehr passiert – wir beobachten das Ganze mal weiter.

Thank you too! I’m glad that I could help. =)

So I did. =]

I simply replaced $('body') on line 249 in admin.js to $('body:not(.widgets-php)'), which prevents the whole formatting stuff from running over widgets. I know it’s kind of a dirty fix, but I think there shouldn’t be any issues with it. Developers should use the HTML widget anyway, and clients are not likely the ones to switch from visual to text tab to edit code (in fact that’s why I didn’t notice the issue earlier). Oh btw – in the customizer screen the plugin doesn’t run over the widgets content anyway.

Thanks a lot, would be great to see this in the next update. ??

I just stumbled over this problem too. I recognized that you don’t have to resize the entire browser – a resize of the gallery’s container works too.

I came up with the solution to set the gallery’s width to 101%, wait until the DOM’s ready, and then switch it back to 100.

.justified-gallery {
	width: 101% !important;
}
.justified-gallery.loaded{
	width: 100% !important;
}

• This reply was modified 7 years, 11 months ago by Azragh.