Making WordPress.org

Opened 2 years ago

Closed 16 months ago

Last modified 8 months ago

#6608 closed defect (bug) (fixed)

Enable Blocks for the Support Forums editor

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: high
Component: Support Forums Keywords:
Cc:

Description (last modified by dd32)

As discussed during the #forums chat today, using the Automattic Blocks Everywhere plugin a few of us have been looking into the possibility of using it on the Support Forums to better the support experience.

I've set it up on https://test.wordpress.org/support/ which is showing good promise, however, there's a few things that need to be resolved before we can consider enabling it on Support Forums.

This is a tracking ticket for any issues experienced, some will be fixed upstream in the plugin itself: Automattic/blocks-everywhere and others may need to be done just for WordPress.org.

✅ Don't show the full Kitchen Sink in the TinyMCE editor when editing existing non-block posts. upstream issue.
✅ Don't show full Block HTML in email notifications from bbPress. upstream issue. Bonus: Less HTML in existing emails.
✅ Ensure that @mention work appropriately. Currently it lists Site Users, where it should pull from those who have interacted with the current Thread. This should NOT suggest moderators by default, or those whose replies are hidden (spammed, archived, awaiting moderation, etc).

  • ❌ Consider whether to always include the support reps for the current plugin/theme.

🔲 Ensure that fixes we've applied for <li> in the past continue to work. See #20. The fix currently in place via [9601] breaks/prevents nested lists in the Block Editor.
🔲 Ensure that blocks copy-pasted from other Block Editor Instances pastes correctly into the Support forum editor.
🔲 Evaluate if an option to disable the Block editor on a per-user profile option is practical. This might be an option, we still need to decide if we wish to support that though. upstream issue
🔲 Evaluate additional blocks to be enabled, or created, for the forums. This may include a "Pasted content" block as below, or other blocks such as pre-defined replies for members of the support team and/or plugin/theme support reps.
✅ Evaluate Upstream issues in Automattic/blocks-everywhere. (please report any major issues in the plugin upstream, if it doesn't seem WordPress.org-specific)
✅ Ensure that pasting logs works. The existing "wrap it in code tags" doesn't work well, and when pasting into the Block Editor it will split it into many blocks instead. This behaviour makes sense for most uses of the Block Editor, but creates a worse UX for the forums, especially when it comes to attempting to combine the logs into a singular block. Upstream Issue

Additional items to be edited in here as discovered, please comment below. Bug Gardeners: Please edit my ticket too!

For tracking..
✅ Enable it for test.wordpress.org/support/
🔲 Enable it for wordpress.org/support/
🔲 Enable it for all localised support forums, *.wordpress.org/support/

Attachments (1)

editor-screenshot.png (75.1 KB) - added by Chouby 16 months ago.

Download all attachments as: .zip

Change History (80)

#1 @dd32
2 years ago

  • Description modified (diff)

#2 follow-up: @alexstine
2 years ago

@dd32 It is very important to me to ensure our support forums experience remains open and accessible to everyone. I'd like to be involved in the early testing to catch bugs before this gets pushed out to production. Keep in mind that this very well could damage some deadlines if there should be any but preventing issues from going in to production will save us a lot of time in the future. Large upfront investment to get a better return at launch.

How can one use the test site above?

Thanks.

This ticket was mentioned in Slack in #accessibility by alexstine. View the logs.


2 years ago

#4 in reply to: ↑ 2 @dd32
2 years ago

Replying to alexstine:

How can one use the test site above?

Due to how the test site is configured, I believe users need to be added manually. Others: Please ping in #meta or #forums on the Making WordPress Slack.

I've added you to the site, that should allow you to create topics and replies.

support forums experience remains open and accessible to everyone.

This is something that we all agree with, and based on how the Block Editor currently works, this should not be detrimental compared to the current experience.

Last edited 2 years ago by dd32 (previous) (diff)

#5 @dd32
2 years ago

In 12292:

Support Forums: Add a user autocomplete handler that uses the support thread participants, rather than using the WordPress site users.

This will replace the 'wporg-bbp-user-mention-autocomplete' plugin.

See #6608.

#6 @dd32
2 years ago

  • Description modified (diff)

#7 @dd32
2 years ago

In 12293:

Support Forums: Add missing change in [12292].

See #6608.

#8 @dd32
2 years ago

I've been unable to spot how to add a filter on the pasted data. Perhaps someone with more Gutenberg experience will be able to.
My thought was that if the pasted content matched the existing rules to auto-wrap it into a wp:code block, or, to prompt the user with something like Select what to do with your paste: Insert a log (code block); Insert a code block (code block); Just insert (default Gutenberg behaviour)

However, I spotted https://github.com/WordPress/gutenberg/issues/38064 which is going to be an issue on the forums.

Pasting Add width and height attributes to <img> elements
results in Add width and height attributes to elements

#9 @alexstine
2 years ago

Just gave this a quick review. Initial thoughts.

  1. I think it would be better if there was some type of button to trigger a new post/reply accordion-like pop out. The reason being, the Gutenberg editor adds additional landmarks specific to the editor and those should not be confused with forum page content.
  2. This option is missing because the best I can tell, there are no options.

https://github.com/WordPress/gutenberg/issues/22190
This is important for accessibility. Even though it may go down as one of the most controversial issues ever discussed in Gutenberg.

  1. I think there should be an option to fill out a simple form. In my professional opinion, I think Gutenberg still requires a bit too much of a learning process to really get the hang of it as a keyboard user. Screen readers only further complicate this. Since there is also no options menu, there is no keyboard shortcuts list or any helpful guides for new users to WordPress. I am not sure this is the experience we should be giving users who are new to WP wanting to ask their questions.

I withheld my judgement until I saw it in action but those are my thoughts. I think 1 and 2 should be blockers for sure and 3 should be highly considered but maybe not required.

Thanks.

#10 follow-up: @dd32
2 years ago

Thanks for your feedback @alexstine! It seems that everything you've raised is something that can't be fixed specifically for the forums, and will have to be considered a change upstream (cc @johnny5).

The only way to diverge from the upstream behaviour would be to have a way to disable it entirely, which I'm still not convinced is a viable option due to how intertwined the editor and content filters are - It might be possible, but would likely loose some form of functionality in doing so.

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


2 years ago

#12 @dd32
2 years ago

  • Description modified (diff)

#13 @dd32
2 years ago

In 12294:

Support Forums: Customise the Blocks Everywhere plugin slightly, and shift enabling the plugin from constants to filters.

Props johnny5 for filters.
See #6608.

#14 @dd32
2 years ago

In 12296:

Support Forums: Code Expand/Contract: Allow for Block Editor Code sections that may have multiple <code>s within a single <pre>.

See #6608.

#15 @dd32
2 years ago

  • Description modified (diff)

#16 @nextend_ramona
2 years ago

Not sure if it's the best place, but the new block-based forum don't seem to like "HTML code paste".

What I mean is that we have a documentation which contains code that we sometimes copy to the forum for our users. Currently this fails. The codes are formatted like so:
https://imgur.com/hgTyiJ2
The HTML is:

<pre class="prettyprint prettyprinted" style=""><span class="pln">define</span><span class="pun">(</span><span class="pln"> </span><span class="str">'WP_DEBUG'</span><span class="pun">,</span><span class="pln"> </span><span class="kwd">true</span><span class="pln"> </span><span class="pun">);</span><span class="pln">
</span></pre>

When I attempt to copy the visual of this HTML to a block at the new forum:
https://test.wordpress.org/support/topic/testing-new-editor/
Nothing happens.

The console displays:
https://imgur.com/UcK7jxY

Received HTML:

 <pre class="prettyprint prettyprinted" style=""><span class="pln">define</span><span class="pun">(</span><span class="pln"> </span><span class="str">'WP_DEBUG'</span><span class="pun">,</span><span class="pln"> </span><span class="kwd">true</span><span class="pln"> </span><span class="pun">);</span><span class="pln"></span></pre>

Received plain text:

 define( 'WP_DEBUG', true );

Processed HTML piece:

 <pre>define( 'WP_DEBUG', true );</pre>

But nothing gets inserted: https://imgur.com/dgyWQ0m

#17 @sterndata
2 years ago

Embedding image fails

https://i.imgur.com/qat1ksp.png

Last edited 2 years ago by sterndata (previous) (diff)

#18 @alanfuller
2 years ago

Text on image needs filtering as only url is valid option

https://i.ibb.co/1R63Q9d/2022-12-06-16-34.png

#19 @sterndata
2 years ago

Strikeout not working (at least, on an edit)

https://i.imgur.com/xKKrTil.png

#20 follow-up: @alanfuller
2 years ago

Predefined responses don't appear to work even when paragraph block selected ( I know pre-defined responses is a tamper monkey thing but still it is a very useful tool if not replaced by an alternative / tweak ( or maybe there is a version that I don't know about ) ?

#21 @sterndata
2 years ago

testing predef from Magical Text Expander

Moderator note:

@alanfuller , if you need support then per the forum guidelines please start your own topic at someforumurl/new-post

https://wordpress.org/support/forum-user-guide/faq/#i-have-the-same-problem-can-i-just-reply-to-someone-elses-post-with-me-too

Last edited 2 years ago by sterndata (previous) (diff)

#22 in reply to: ↑ 20 @dd32
2 years ago

Replying to nextend_ramona:

Not sure if it's the best place, but the new block-based forum don't seem to like "HTML code paste".

Pasting is a pretty big known blocker at present, there's an overlap between Gutenberg, Blocks Everywhere, and potentially WordPress.org.

See https://github.com/WordPress/gutenberg/issues/38064, https://github.com/Automattic/blocks-everywhere/issues/60, and https://github.com/Automattic/blocks-everywhere/issues/54 for some related issues here.

None of these explicitly cover this scenario, but there's a big issue of Gutenberg treating everything as a a HTML paste that should be rendered, rather than inserted into the post as plain-text. I'm not sure how we'll overcome this, but I believe it's going to require a custom block and a Gutenberg enhancement to allow Paste filtering, see Issue 54.

Replying to sterndata:

Embedding image fails

This is being tracked via https://github.com/Automattic/blocks-everywhere/issues/69
That being said, I might see about making a change on WordPress.org to make these work, otherwise it's likely we'll need to disable the Embed blocks.

Replying to alanfuller:

Text on image needs filtering as only url is valid option

See https://github.com/Automattic/blocks-everywhere/issues/62 for some related things here.

This is likely something that will need to be fixed upstream in Gutenberg, unless we create a dedicated block in either Blocks Everywhere or WordPress.org Support Forums.

Replying to sterndata:

Strikeout not working (at least, on an edit)

Bug! Filed upstream as https://github.com/Automattic/blocks-everywhere/issues/72

Replying to alanfuller:

Predefined responses don't appear to work even when paragraph block selected

I suspect this is related to the pasting issues above, but also that the script needs updating to act as a "paste event" rather than "append content to the <textbox>" that it's likely currently doing.

#23 @dd32
2 years ago

In 12300:

Support Forums: Blocks: Allow any user who can publish a reply/topic to access the oEmbed proxy endpoint.

See #6608.

#24 @dd32
2 years ago

In 12301:

Support Forums: Blocks: Whitelist the core/image and core/embed blocks server-side in addition to in the editor.

See #6608.

#25 @dd32
2 years ago

In 12302:

Support Forums: Disable Screencast oEmbed and fix Imgur embeds.

See #6608.

#26 @dd32
2 years ago

In 12303:

Support Forums: Blocks: Fix loading of the editor interface after [12302].

If the array is missing a key ( Such as 6: [ .. 4 => .., 5 => .., 7 => .. ] ) things break.

See #6608.

#27 follow-up: @TobiasBg
2 years ago

I often post code in the forums and thus would use the Code block often.

For some reason, the markdown-inspired keyboard shortcut of typing ``` (three grave accent symbols, this will probably not show here as Trac also interprets these) to quickly get a Code block is not working though - while it is in the normal WordPress block editor.

Last edited 2 years ago by dd32 (previous) (diff)

#28 @dd32
2 years ago

In 12313:

Support Forums: Blocks: Remove the support-forum-specific mention autocompleter in preference for the one upstream in the Blocks Everywhere plugin.

See https://github.com/Automattic/blocks-everywhere/pull/78.
See #6608.

#29 in reply to: ↑ 27 @dd32
2 years ago

Replying to TobiasBg:

For some reason, the markdown-inspired keyboard shortcut of typing ``` to quickly get a Code block is not working though

I suspect this has been intentionally disabled in the BlocksEverything plugin or unintentionally so, as that's the Markdown Raw handling that also does ## => heading, which probably interferes with pasting.. Interestingly, you can't paste text that contains ```\n in either.. so maybe it's not intentionally and just the Raw Handling in Gutenberg bailing. More investigation is required.

#30 @dd32
2 years ago

In 12314:

Support Forums: Blocks: Add an experimental predefs functionality through the usage of Block Patterns.

Props johnny5.
See #6608.

#31 in reply to: ↑ 10 @alexstine
2 years ago

Replying to dd32:

Thanks for your feedback @alexstine! It seems that everything you've raised is something that can't be fixed specifically for the forums, and will have to be considered a change upstream (cc @johnny5).

The only way to diverge from the upstream behaviour would be to have a way to disable it entirely, which I'm still not convinced is a viable option due to how intertwined the editor and content filters are - It might be possible, but would likely loose some form of functionality in doing so.

How do things need to move forward from here? Does this ticket have watchers to take care of the issues I mentioned?

#32 @dd32
2 years ago

In 12326:

Support Forums: Blocks: Enable 'replaceParagraphCode'.

See #6608.

#33 @dd32
2 years ago

  • Description modified (diff)

Ensure that fixes we've applied for <li> in the past continue to work.

Our fix still prevents nested lists from the Editor working, but that's OK for now.

Ensure that blocks copy-pasted from other Block Editor Instances pastes correctly into the Support forum editor.

This mostly works, unless you copy a block that we don't support, instead of getting an error.. nothing happens.
This can be duplicated by copying a HTML block from wordpress.org/gutenberg.

Evaluate if an option to disable the Block editor on a per-user profile option is practical.

This appears to be an option now, however, is something we'd like to avoid if possible.

Evaluate additional blocks to be enabled, or created

Some upstream work has been done to create a custom Paragraph block which resolves some/most of our paste issues.
Blocks for Site Health and other related things would be beneficial, but isn't needed for an MVP here.

#34 @dd32
2 years ago

  • Description modified (diff)

Consider whether to always include the support reps for the current plugin/theme.

I'm going to close this one out. I don't think it's going to be beneficial.

#35 @Clorith
2 years ago

Pasting images is a common workflow pattern in the block editor, but throws an (expected) error where the image block fails to render.

We do not wish to host random images, as we may then be liable to content that is uploaded by unknown third parties (we're not an image hosting service, let them who know it well, deal with it, we all know this, but adding it for transparency reasons :) ); so a means of blocking image/document pastes within the editor should be added.

#36 @dd32
2 years ago

so a means of blocking image/document pastes within the editor should be added.

Curious as if this is any different from the existing flow? If the issue is the embedding of the image, the moderation team should be able to edit the problematic post.

If we can't trust anyone to embed, then we'd need to disable all embedding, or, limit it to accounts that have proved trustworthy.

#37 @dd32
2 years ago

In 12329:

Support Forums: Blocks: Fix the Block Editor toolbar floating over the top of the WordPress.org header.

See #6608.

#38 @dd32
2 years ago

In 12330:

Support Forums: Blocks: Add per-user/forum opt-in/out.

This is currently not exposed in user-profiles for regular users.

See #6608.

#39 @dd32
2 years ago

In 12331:

Support Forums: Blocks: Avoid a PHP Notice when no forum is known (such as a user edit page).

See #6608.

#40 follow-up: @mrfoxtalbot
2 years ago

I have done a few tests just now and it looks like list block is not working correctly, I see broken HTML:

https://user-images.githubusercontent.com/4452464/207793703-46828234-190a-44a8-a3dd-ce18622b2635.png

I opened an issue https://github.com/Automattic/blocks-everywhere/issues/100 but I am not sure wether this is a problem with the Blocks Everywhere plugin or a problem with its implementation in the w.org forums (cc @johnny5).

Version 3, edited 2 years ago by mrfoxtalbot (previous) (next) (diff)

#41 @dd32
2 years ago

In 12332:

Support Forums: Blocks: Allow for a user to opt-out of using the Block Editor on the support forums.

The opt-out option is present on the individual Support Profiles.

See #6608.

#42 in reply to: ↑ 40 @dd32
2 years ago

Replying to mrfoxtalbot:

I have done a few tests just now and it looks like list block is not working correctly, I see this broken HTML

This was fixed on dotorg, and upstreamed as PR101.

#43 @ryelle
2 years ago

In 12334:

Support Forums: Blocks: Prevent block editor from loading on articles.

The block editor was also being used for the feedback form on articles, but it's missing a dependency which causes the form to disappear. This fix simply disables the block editor on articles.

See #6608.

#44 @ryelle
2 years ago

I just pushed a quick fix in [12334] to disable the block editor on articles — the feedback form at the end of the page (for example, here) was trying to load the block editor, but was missing the postbox dependency, so instead it loaded no form. I don't have enough background on this project to know how to fix that specifically, but since the focus is forums, I've just disabled it here for now.

This doesn't change the editor on the forums themselves.

#45 @alexstine
2 years ago

@dd32 One final request. Is there a way to inject a message like this above the Your message field label?

"Need a basic text editor? Adjust this preference in your forum profile."

This setting should be a little more discoverable.

Thanks.

This ticket was mentioned in Slack in #forums by mrfoxtalbot. View the logs.


2 years ago

#47 follow-up: @tobifjellner
2 years ago

The fixes for marking long pasted text as code doesn't work well in block mode. See https://wordpress.org/support/topic/address-could-not-be-verified/?view=all#post-16294387

#48 in reply to: ↑ 47 @dd32
2 years ago

Replying to tobifjellner:

The fixes for marking long pasted text as code doesn't work well in block mode.

This is supposed to have been fixed, If you attempt to paste Site Health, it inserts as a Code block.. Or at least does for me in Chrome on OSX, the code is upstream in Blocks Everywhere.

Due to how Gutenberg handles pastes, and how inconsistent Browsers are, I suspect that the paste data that the code saw for that post was not complete so it didn't trigger the code.. Will need to find a way to duplicate it. The Browser in question for that post was FireFox/109 on OS X.

Last edited 2 years ago by dd32 (previous) (diff)

#49 @dd32
2 years ago

In 12340:

Support Forums: Blocks: Don't allow empty block replies.

See https://wordpress.slack.com/archives/C02RQC6RW/p1671157667631789.
See #6608.

#50 @dd32
2 years ago

In 12341:

Support Forums: Blocks: Store emoji's as emojis, not as img.emoji.

This allows emojis to be rendered by the viewer, rather than the conversions being based on the posters browser support.

See #6608.

#51 @dd32
2 years ago

[12342] from @dufresnesteven missed this ticket:

wporg-support: Patch some styles broken by embedded block editor.

See: https://github.com/Automattic/blocks-everywhere/issues/110

That fixes the broken header/footer.

#52 @Otto42
2 years ago

Had some trouble with list items this morning.

https://wordpress.org/support/topic/gutenberg-on-forums/

When editing that to put it back together, it showed the invalid block item. Recovery simply made a new blank list item. Attempting to resolve gave the option to convert to HTML or convert to blocks, neither of which the button did anything.

Attempting to recreate the list resulted in the same broken blocks. Eventually, just making not a list worked fine, but...

#53 @nextend_ramona
2 years ago

Are we aware of lists being displayed as "pure" HTML? See:
https://wordpress.org/support/topic/slider-disappears-7/
Same happens in the sent email.

#54 @Otto42
2 years ago

Yeah, lists don't work on save. And I believe that they get escaped, probably by some older bbPress code. It happens regardless of the way the list is entered. Even pasting a list item from elsewhere pastes alright, but doesn't work after save. Editing this results in a broken block, as mentioned above. Easy to reproduce.

Last edited 2 years ago by Otto42 (previous) (diff)

#55 follow-ups: @Otto42
2 years ago

#6634 was marked as a duplicate.

#56 @Otto42
2 years ago

#6636 was marked as a duplicate.

#57 @Cybr
2 years ago

I prefer to write in plain HTML, also for the reasons listed in comment:9 (3.) -- please give power users the option to switch between blocks and HTML.

#58 @dd32
2 years ago

In 12344:

Support Forum: Blocks: Remove custom empty-blocks-content filter added in [12340].

See https://github.com/Automattic/blocks-everywhere/pull/113.
See #6608.

#59 @dd32
2 years ago

Lists were fixed in https://github.com/Automattic/blocks-everywhere/commit/d0967e0d4632249d39505dfe12fd661898225d06 I typo'd the patch I upstreamed to whitelist li.class 🤦

please give power users the option to switch between blocks and HTML.

This isn't something we can add/resolve for WordPress.org forums specifically, would you mind filing an enhancement upstream in https://github.com/Automattic/blocks-everywhere/issues @Cybr?

#60 in reply to: ↑ 55 @dd32
2 years ago

Replying to Otto42:

#6634 was marked as a duplicate.

tl;dr: Valid HTML (such as <a href...> within a code block is not remaining escaped, bbPress is converting it to literal HTML.

I've upstreamed this to https://github.com/Automattic/blocks-everywhere/issues/119

#61 @dd32
2 years ago

In 12345:

Support Forums: Blocks: Don't treat a non-block post as a block post during edit.

During the bbPress edit topic/reply POST submission, bbp_is_reply_edit() and bbp_is_topic_edit() are not truthful.

See https://github.com/Automattic/blocks-everywhere/pull/120.
See #6608.

#62 @dd32
2 years ago

In 12347:

Support Forums: Plugin/Theme/Review "forums": Make bbp_get_forum_id() work in the plugin/theme/review "forums".

These forums are not forums, but rather, are views of a forum. As a result of this, bbPress doesn't return a forum object even through it's seen as a single forum.

This caused the Block Editor to be enabled for these views due to a misconfiguration of the Blocks integration, where in the event it couldn't find a forum for the current page, defaulted to being enabled.

This code aims to remove similar faults in the future, by allowing bbp_get_forum_id() to return the true forum_id for these forums, while at the same time being a view.

This should not be removed without verifying that [12348] works as expected.

See #6608.

#63 @dd32
2 years ago

In 12348:

Support Forums: Blocks: Don't fallback to having the Block Editor enabled, if forums are not enabled by default.

This is reliant upon [12347], which allows this code to know which forum is being viewed for the views (plugins/themes/reviews).

See #6608.

#64 in reply to: ↑ 55 @Otto42
2 years ago

Replying to Otto42:

#6634 was marked as a duplicate.

This appears to have been fixed by the upstream changes.

#65 @mrfoxtalbot
2 years ago

I am seeing that "Ensure that pasting logs works." is marked as solved but it is still being worked on upstream, here https://github.com/WordPress/gutenberg/pull/38183

While this gets fixed, I have opened https://meta.trac.wordpress.org/ticket/6645 to alleviate some of the friction created by this gap.

#66 @Otto42
2 years ago

#6645 was marked as a duplicate.

#67 @zoonini
2 years ago

BUG: After publishing a comment on a review, I went back to edit a link, but was initially unable to do so, since the formatting toolbar overlaps the link pop-up. Could we perhaps make the z-index on the link pop-up higher than the formatting toolbar? (I eventually managed to work around the glitch by scrolling the window up and down a bit, and the overlap finally went away)

https://cldup.com/_oH5WFD2iG.png

#68 @nextend_ramona
23 months ago

Seems like "inline" links are not in the sent email. The following inline link was added:

As per forum rules, commercial products are <a href="https://wordpress.org/support/guidelines/#do-not-post-about-commercial-products" target="_blank">not supported in these forums</a>.

and in the email, it displays in "plain text":

As per forum rules, commercial products are not supported in these forums. 

When the URL itself is a link, that worked well.

This ticket was mentioned in Slack in #forums by zoonini. View the logs.


23 months ago

#70 @dd32
23 months ago

In 12366:

Support Forums: Blocks: Enable Blocks by default for all forums, unless opt'd out.

This will make it easier to rollout to Rosetta sites.

See #6608.

#71 @mrfoxtalbot
22 months ago

In 6811: "Microsoft Edge translation feature appears to be adding superfluous HTML code."

This ticket was mentioned in Slack in #forums by mrfoxtalbot. View the logs.


19 months ago

This ticket was mentioned in Slack in #forums by mrfoxtalbot. View the logs.


18 months ago

#74 @Chouby
16 months ago

In the above screenshot, typing a long url with special characters extends the editor on the right and moves the submit button to the right too. It's impossible to click on the submit button.

#75 @dd32
16 months ago

Hi @Chouby, that's being tracked via #6833

#76 @dd32
16 months ago

  • Resolution set to fixed
  • Status changed from new to closed

I'm closing this ticket as resolved, as it's been enabled for a while now.

Please open new tickets for new issues.

This ticket was mentioned in Slack in #forums by mrfoxtalbot. View the logs.


15 months ago

#78 @dd32
8 months ago

In 13548:

Support Forums: Blocks: When editing a reply/thread that was created pre-block editor, but now has a block editor, load the block editor upon save.

This fixes edits of old reviews showing block HTML, as old reviews can be edited in the new block editor.

See #6608, #7593.

#79 @dd32
8 months ago

In 13572:

Support Forums: Blocks: Remove broken predef support.

This pre-def support has been broken so long that it appears no-one knew it was supposed to exist.
While predefs would be useful, this requires more work to make it work properly, so just removing it for now.

See #6608.

Note: See TracTickets for help on using tickets.