[wp-trac] [WordPress Trac] #40907: Introduce widget dedicated for HTML code
WordPress Trac
noreply at wordpress.org
Tue Jun 27 17:30:15 UTC 2017
#40907: Introduce widget dedicated for HTML code
-------------------------------------------------+-------------------------
Reporter: westonruter | Owner:
Type: feature request | westonruter
Priority: normal | Status: reopened
Component: Widgets | Milestone: 4.8.1
Severity: normal | Version: 4.8
Keywords: has-patch has-unit-tests commit | Resolution:
fixed-major | Focuses:
-------------------------------------------------+-------------------------
Comment (by slewisma):
+1 this explanation and position. Anything other than a solution that
allows editing existing text widgets that contain arbitrary html, css and
js is going to leave a lot of sites waiting to break and no admin
accessible way to reliably recover the widget content to move it
elsewhere.
I've got three client sites mid-development that cannot continue right now
because the "improved" text widget breaks the ability to edit a text
widget at all if it is in a Toolset Layout as a single widget and regular
use of the text widget in a widget area "eats" existing content when
opening the widget for editing. Yes I can go find the widget contents in
MySQL to try to salvage it and re-introduce it another way but that is not
practical.
Kudos to the many who are introducing work-arounds in the form of forked
classic text widgets and import export tools but most of those mean
wandering away from the out of the box Wordpress way and not easily coming
back. It'd be far better to fix this fast by reverting to the prior
version then work out the best way to introduce rich text widgets while
all our sites are once again manageable and reliable.
I have no issue with renaming the old text widget to something like html
widget '''as long as it doesn't break existing sites!'''
Replying to [comment:35 FolioVision]:
> There are three related open tickets about the issues which the forced
upgrade of existing text widgets has caused:
>
> * [ticket:40907 Introduce widget dedicated for HTML code]
> * [ticket:40951 New Text Widget - Switching Between Visual/Text Editor
Strips Out Code]
> * [ticket:40960 Widgets: The Text widget should respect the “Disable the
visual editor when writing” setting]
>
> I'm not expert enough in WordPress Trac to be able to etiquette to merge
all three but perhaps someone else is.
>
> Apparently the reason we are breaking millions of WordPress sites is
[comment:5:ticket:40907 fairly arbitrary decision by Matt made in Slack]
(hardly seem a very earnest way of running an open source project, taking
breaking decisions in a real time chat environment with no opportunity for
input by those not present at the specific meeting).
>
> > Matt wants to move forward with the upgraded Text widget as-is, with
there not being a great enough concern for some users potentially having
to adjust their usage to align with the new behavior (which aligns with
longstanding post editor behavior).
>
> Consensus among developers is [comment:37:ticket:40951 synavista's
suggestion]:
>
> > The best course of action at this point, it would seem, would be to
admit the error, convert the text editor back to the way it was, and
simultaneously release the updated HTML Code widget along with a new Rich
Text Editor. If that is completely impossible, at least figure out a way
for the TinyMCE Text Editor to both default to the text editor AND
remember the selected editor type (which I would hope would stop the
system from stripping out existing content).
>
> Advocates of that point of view include many experienced developers and
contributors such as [comment:3:ticket:40907 sami.keijonen],
[comment:4:ticket:40907 Kopepash], [comment:12:ticket:40907 carasmo],
[comment:30:ticket:40907 pipdig], [comment:33:ticket:40907
piggybanktechnology], [comment:34:ticket:40907 theMikeD],
[comment:5:ticket:40960 Cynderella], [comment:6:ticket:40960 dfterry],
[comment:7:ticket:40960 skoen], [comment:8:ticket:40960 j893],
[comment:4:ticket:40951 dwrippe], [comment:31:ticket:40951 And_or],
[comment:40:ticket:40951 philclothier], [comment:42:ticket:40951 majick],
[comment:43:ticket:40951 gitlost], [comment:52:ticket:40951 gekkocorp].
>
> The current fix strategy will not solve unnecessary breaking issues, as
[comment:10:ticket:40960 TheMikeD notes]:
>
> > That's great, but it still means that every site that has ever used to
code in the text widget now has to be manually updated. Backwards
compatibility wise, this decision was not well thought out. I would like
to see the rich text parts of the text widget reverted and a new rich text
editor in trunk. In other words, don't replace the one that's already
there, add a new one.
>
> The update burden for those of us who actually manage WordPress websites
in the real world (and don't have 500 developers on staff to do it for us)
is [comment:31:ticket:40951 substantial]:
>
> > Usually I am fast with updating websites, but this 'handy' Text Widget
is a game-changer. Basically I feel punished for knowing and using html
now....So I have convinced my clients to update their sites, and now I can
not until I have manually checked and fixed a 100+ Genesis
websites...which is going to take me days.(Who is the genius that wanted
this new widget?)
>
> There's nothing wrong with making mistakes, Matt. There's something
really wrong in not acknowledging one's mistakes and correcting them.
>
> All we have to do here is make the HTML widget a separate widget and not
auto-convert the existing widgets to an HTML widget. There's no problem
even making the default widget going forward the HTML one. But force
converting and breaking sites is not fair. I'm left pretty speechless by
this deliberate sabotage of millions of sites.
>
> Nonsense like this makes me very glad we created
[https://wordpress.org/plugins/businesspress/ BusinessPress] to block
forced or inadvertent updates for WordPress until we're satisfied those
updates no longer compromise security or functionality.
>
> Millions of personal and business sites should not be a playground for
beta software, whether that software is free or not. WordPress is not free
to its users: they pay in spades for choosing WordPress in either money
(management) or time (lots of their own free time). Honestly we should
keep WordPress users' costs to a minimum and strive to keep the trust
high.
>
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40907#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list