[wp-trac] [WordPress Trac] #59230: HUGE problems upgrading to WordPress 6.3

[WordPress Trac]

#59230: HUGE problems upgrading to WordPress 6.3
--------------------------+-----------------------------
 Reporter:  atutrabajo    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.3
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Hello. A few days ago I upgraded to WordPress 6.3 and it AUTOMATICALLY
 removed ALL my custom line break codes.
 That is to say, as opportunely (FOR +3 YEARS) since as you surely know,
 when you press enter 2 times, WP does NOT admit an "empty" paragraph (that
 is, it is NOT seen in the browser), I had to invent the following code…
 <p style="padding-top: 18px;"></p>
 AND FOR +3 YEARS (I repeat it just to be clear, heh:), this worked
 PERFECTLY.
 But, as of its update to 6.3, that code was NO LONGER seen (neither in my
 Editor nor, in the browsers).
 Okay. I "armed myself with patience" and, despite having generated 2 (two)
 "claims"...
 1) One in the "support" forums (which you can see by following this link);
 https://wordpress.org/support/topic/huge-error-for-my-site-when-upgrading-
 to-6-3/page/2/#post-16979369
 2) And a second in another section that "I guess" is used to report bugs;
 https://core.trac.wordpress.org/ticket/59117#comment:2

 But in NO case did they offer me solutions and in the end, I ended up
 solving it on my own.

 And what is the problem? Simple.
 That after being for +3 days! replacing ALL custom codes (<p style
 ="padding-top: 18px;"></p>) by a shortcode ([br]) which, by inserting in
 my function.php the corresponding code (/* - ------Shortcode Line Break
 --------*/ function line_break_shortcode() { return '<br />'; }
 add_shortcode( 'br', 'line_break_shortcode' ); “converts” those breaks
 line, in something "accepted" by WordPress (*)
 (*) That is, now it looks good, both in my Editor and in browsers.

 However. So far, everything Ok And what happened? Good that…
 I just upgraded to WordPress 6.3 and I find that when I want to Edit a
 part of my content (ONLY at the beginning), it looks like this…
 https://ibb.co/Jvv0dxX

 That is, with its corresponding editing block (or whatever it is called)
 that includes the basic tools that I use to edit (if it is a paragraph or
 an h, if I want to add bold, italics, etc.). But…
 When I continue to "scroll" through my content (just 4 lines to be exact),
 it looks like this;
 https://ibb.co/ZHPfGpy
 In other words, the bar (to add bold, italics, etc.) "mysteriously"
 DISAPPEARS.

 Note: I just “discovered” that said bar is called…
 Toolbar" of the Text module
 (Well. I didn't discover gunpowder either, right?:)

 Looking for information about this, I found that MANY users reported the
 same thing, in the following thread;
 https://wordpress.com/es/forums/topic/edit-in-classic/
 And that, unfortunately, the only "answer" they received SINCE JULY! The
 thing is…
 Hello!
 I know it can be a bit frustrating, but our developers are still reviewing
 this. Look, part of the bug report is public, so you can follow its
 development here:
 https://github.com/Automattic/wp-calypso/issues/74031
 I know it's not ideal, but at least I want you to see what's behind the
 error :)
 All the best!

 Note: This thread was opened in MAY! (But it affected me JUST now)
 Ergo, apparently, this is a problem that they are STILL “reviewing”, heh.

 By the way and only as an "anecdotal" data...
 In this article;
 https://astucesdivi.com/es/fixer-barre-outils-module-texte/
 The issue is discussed and possible "solutions" are provided.

 But I tried it and apparently, it ONLY works for DIVI (*)
 (*) And according to some comments within the article… It is NOT always
 like that!, heh.

 Note: Just in case someone is interested in this information, what I did
 (and it did NOT work) was…
 1) Add in Appearance/Customize/Additional CSS the following code;
 .mce-container-body mce-flow-layout {
 position: sticky !important;
 top: -30px;
 }

 2) I added in my function.php the following;
 /* sticky toolbar on scroll */
 add_action('admin_head', 'toolbar_sticky');
 function toolbar_sticky() {
 echo '<style>
 .mce-container-body mce-flow-layout {
 position: sticky !important;
 top: -30px;
 }
 </style>';
 }

 I am telling you about it because perhaps I am "mistaking" the class of
 the element in question.
 But hey.
 It is what I could see by going to Right Click on the bar / inspect / copy
 element;
 https://ibb.co/d0DRSjt
 Ergo. I assumed that the name of the class in question is the 1st. that
 appears to me

 In summary, the "solution" would be what they say in the 1st. mentioned
 item. In other words, the toolbar of the text module remains in view
 WHENEVER it is needed, regardless of the length of the content we are
 working on.

 Conclusion:
 I'm going back to my previous version (6.2) while I wait for some
 solution.

 However, the "problem" that this generates is that:
 1) It creates a security problem for me (both for me and for those who
 share my hosting)
 2) It could bring me problems with my hosting provider because, not
 keeping WordPress updated, it could cause me some type of sanction (For
 example: a SUSPENSION).

 I look forward to your comments.

 From already thank you very much.

 Greetings.

 P.d 1: To the people of WordPress.
 I reiterate the same thing that I mentioned in the previous thread;
 https://core.trac.wordpress.org/ticket/59117#comment:2
 This could be the WORST of all security flaws, because if they continue to
 "force" us NOT to update, and some of our site/s are affected by a virus,
 we can infect the rest!! !

 P.d 2: It is NOT worth saying that it is the browser
 I just tried in Firefox and it doesn't work either

 P.d 3: Neither are cookies
 BEFORE, DURING AND AFTER my tests, I deleted them ALL.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59230>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform