-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gutenberg block plugin fix #666
Conversation
… nesting of block spans
Been able to repro the same issue as described in @daniloercoli 's comment here on different OS versions. Furthermore and to narrow down, this issue seems to happen only when you add an image at the end of the last paragraph. It doesn't fail like that when there’s more content and you try to insert at the end of the first paragraph. For example, using this code:
if you place the cursor at the end of the first sentence and insert an image, checking the HTML editor shows this: Then, inserting an image at the end of the last (second) paragraph makes it duplicate the image when converting to HTML: Just inserting an image at the end of the last paragraph makes it duplicate. Another thing observed is that placing the cursor there at the end is not remembered well when switching to/from HTML mode:
|
Explanation of the double image issuesee description here above FixI managed to patch that by looking into the nesting level and only considering a match when the same Example 1Putting the cursor at the beginning of the example text (if you switch to HTML you'll see the cursor is at the beginning of the text but after both the GB delimiter and the (the image is inserted after the starting GB delimiter, but before the opening Example 2Inserting an image in the last paragraph, then switching to HTML, then deleting all traces of that image, leaving the HTML code "as it was originally". Then back to visual mode and insert the image again, produces the following output: As you can see, the GB delimiter is now gone. ThoughtsI think we should go with the "pre/post process and tie tags" approach Danilo made (#665), here's why: Therefore, I think hiding the GB delimiters in the known last opening / closing HTML tag and then bloating them again once converting back from visual to html is IMO way safer. |
I noticed that the double-image issue mentioned by @daniloercoli (and @mzorz ) is actually an "issue" present on develop too. What happens is that when adding the image at text buffer end, the code appends the I think that we need tackle this root cause first, by making sure the |
That's weird, because today I wrote a test for this and there wasn't a problem running it on develop. |
Opened a PR with a couple of fixes. Not sure if more issues are still existing though. |
…-insertion-fix Keep media inside BlockSpan when at buffer end
…bile/AztecEditor-Android into add/tests-for-gb-integration
…l the time. Added a test about list deletion
…ation Add some tests for basic GB integration
…-aztecparser-constructor overloaded AztecParser constructor for optional params
I've been performing tests integrating with WPAndroid - we at least don’t seem to be breaking Gutenberg posts now, which is great! 🎉 Interesting findings here:
While this is not the best UX, I think it's "compatible enough" for now. A note on this, once the post goes through Aztec once, it doesn't seem to update itself unpurposedly if you open and edit on Gutenberg web afterwards (and open back in WPAndroid again). So I think this is OK to bear with. Some of the differences found: That is, a space is trimmed (first case), and a special character is added in the second case. This latter case might be worth looking into and further follow up, but I don't think (as per my tests) it's going to happen on every post, I'd say it's probably not the highest priority. Attaching the files with content before / after processing here so you can diff locally and see. post-afterAztec.html.txt (renamed to Looking forward to merge if you agree @daniloercoli @hypest |
Merging this one then Mario, when you have the time would you mind to open new tickets for the issues you're reported above? |
Was going to track this one but @daniloercoli found the mother issue already tracked in #136 🙇 |
Fixes #659.
I was curious how difficult it would be to parse GB comments as a block. I had to add a new plugin type
IBlockSpanHandler
because we only had one for inline spans.There were a couple of issues along the way, like broken nesting because of extra
<html>
and<body>
being inserted by the TagSoup parser. But it seems like this could be the right approach and the result looks promising.