Support » Plugin: footnotes » Converting exiting footnotes to work with block editor

  • Resolved Earl_D

    (@earl_d)


    Hello I know you are working on eliminating bugs in the plug-in as a priority. However running into more issues with using the plug-in in the block editor. Currently using [ref] [/ref] for footnotes. When an existing page with that is edited in the block editor it converts to shortcodes that do not connect with the text being referenced. If I change to another format like <fn> all my footnotes and I have a ton are lost.

    I can just copy the footnote from the shortcode block and paste into the text as this creates a host of other html in the block editor. Can you suggest the best format to use going forward that doesn’t conflict with the block editor and a way to convert existing footnotes?

    Thanks in advance

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Contributor pewgeuges

    (@pewgeuges)

    @earl_d,

    The Footnotes “shortcodes” mustn’t be used in shortcode blocks, but typed inline, like so:

    Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt, ut labore et dolore magnam aliquam quaerat voluptatem.[ref]Cicero.[/ref]

    Thread Starter Earl_D

    (@earl_d)

    Yes I realize that but with existing posts that doesn’t work because when the converted for the block editor the footnotes get converted to shortcodes. With all the existing posts with footnotes that means retyping every single footnote some posts have as many as ten or twelve.

    So what I am asking is this is. Is there a footnote format that doesn’t get read as shortcode by the block editor and can existing footnote format be converted to that without needing to retype every single one?

    That seems like the only way to work with the block editor and existing posts.

    • This reply was modified 4 months, 2 weeks ago by Earl_D.
    Plugin Contributor pewgeuges

    (@pewgeuges)

    I’ve never had this bug, and I didn’t know that posts are converted for the Block Editor. I always thought that posts are opened as-is in an editor, not converted to that editor. Consistently, when using the Classic Editor WordPress plugin configured to let writers choose their editor, I can switch back and forth, and never posts get converted or noticeably altered, except with respect to inconsistent pointy bracket escapement schemas, properly addressed by the Footnotes plugin since v2.5.14 and the 2.6.0 release. Never was I aware of any problem with square brackets.

    For me to get a chance to reproduce this bug, may you please share the source code of an example post by switching to Code editor, copying all and pasting in a shareable place like the recommended Gist or https://pastebin.com

    • This reply was modified 4 months, 2 weeks ago by pewgeuges.
    Plugin Contributor pewgeuges

    (@pewgeuges)

    @earl_d,

    I’ve made a new post in the Classic Editor, then closed it and opened it in the Block Editor. This is the post’s code, unchanged:

    
    Text.[ref]Footnote.[/ref] (To see conversion.)
    

    The paired shortcode is not converted to a shortcode block. All I see from the Classic Editor in the Block Editor is the mention “Classic Editor” and the missing block markup.

    There is indeed a conversion feature. To use it, I clicked “Convert to blocks”. But it does nothing more than adding the block markup, and leaves the Footnotes shortcodes alone:

    
    <!-- wp:paragraph -->
    <p>Text.[ref]Footnote.[/ref] (To see conversion.)</p>
    <!-- /wp:paragraph -->
    

    Trying to figure the issue out, we’d need some additional information, like the era when the disturbed posts were created, the footnotes plugin you were using back then if not Footnotes, eventually a screenshot of how it looks in the editor. Some sample post source might also be helpful.

    Some footnotes plugins register the shortcodes as WordPress shortcodes and rely on the shortcode API (that does not work everywhere). If you converted the posts while using a plugin relying on registered shortcodes, the Block Editor might eventually convert these indeed to shortcode blocks. But why does it happen today, as you are hinting?

    Is there a footnote format that doesn’t get read as shortcode by the block editor

    Basically none of the footnote formats gets read as shortcodes, as demonstrated. The reason why is that Footnotes does not register any shortcodes, so WordPress cannot assume any of them are shortcodes. The WordPress shortcode API explicitly leaves as-is any strings bracketed with square brackets that were not added as shortcodes.

    can existing footnote format be converted to that without needing to retype every single one?

    No, the Footnotes plugin is lacking any conversion feature, as it addresses this issue the other way around, allowing to configure the shortcodes used. Browsing the Forum proves that up to now, all known users of other footnotes plugins who changed for Footnotes were able to simply configure the shortcodes to match those used previously, to keep all footnotes up and running.

    I’m sorry that you are having trouble. But at this point I still fail to see the cause.

    Thread Starter Earl_D

    (@earl_d)

    Basically none of the footnote formats gets read as shortcodes, as demonstrated. The reason why is that Footnotes does not register any shortcodes, so WordPress cannot assume any of them are shortcodes. The WordPress shortcode API explicitly leaves as-is any strings bracketed with square brackets that were not added as shortcodes.

    That isn’t accurate in the block editor if text of a post is converted to blocks the footnotes are converted to shortcodes and are displaced from the item being footnoted.
    I have a ton of posts with sometimes upwards a a dozen footnotes which means if I want to keep footnotes as desired I have to go to every single Footnote converted to shortcodes and copy the links and only the link otherwise all kinds of added WP code is copied then recreate the footnotes again. I will post a before and after example screenshots soon.

    If one of the other formats like parentheses () or brackets <> would be left alone by the WP bock editor and conversion I would switch to that for all new footnotes. But I was trying to figure out if there was a way to switch existing footnotes as well what I hear you saying is not there is not.

    There just doesn’t seem like that is a is a simple user experience going forward with the current way the plug-in is implemented with the block editor. My concern is was the classic editor is supposed to be depreciated at the end of this year what does that mean for all the existing footnotes I have when I update posts.

    • This reply was modified 4 months, 1 week ago by Earl_D.
    Plugin Contributor pewgeuges

    (@pewgeuges)

    @earl_d

    In a new attempt to reproduce the reported bug, I’ve reinstalled Easy Footnotes and made a new post in the Classic Editor. Then reopened this as an existing post in the Block Editor, and converted to blocks. This is how it looks in Visual mode:

    
    A new post.[efn_note]A footnote in registered shortcodes.[/efn_note] End of post.
    

    This is the result in Code editor:

    
    <!-- wp:paragraph -->
    <p>A new post.[efn_note]A footnote in registered shortcodes.[/efn_note] End of post.</p>
    <!-- /wp:paragraph -->
    

    The difference this time was that the conversion was run on registered shortcodes, as Easy Footnotes is activated, and Footnotes deactivated.

    That was meant to be a remake of the worst-case scenario. Nevertheless, the Block Editor did not move the shortcode into a shortcode block. Instead, it left it inline, so that the footnote stays fully operational and will keep working properly even after Easy Footnotes is deactivated, and Footnotes is activated.

    Looking forward to your screenshots.

    Thread Starter Earl_D

    (@earl_d)

    Here are the screenshots of my current UX with footnotes plugin and block editor.
    In the first image you can see the footnotes from the footnotes plug-in and easy footnotes both open in the block editor with the appropriate markup inside the classic editor block. If other text is in the post which is my situation the only way to keep the formatting is to keep editing in the classic editor. If I want to take advantage of the paragraph or other features of the block editor I have to convert the text in the classic editor using the button pictured. If I do that all the footnote markup is converted to shortcodes as you can see in the second image.

    Before convert to blocks
    Existing post with footnotes opened with block editor

    After convert to blocks
    After suing the convert to blocks option in the block editor

    • This reply was modified 4 months ago by Earl_D.
    Plugin Contributor pewgeuges

    (@pewgeuges)

    Thanks for the screenshots, I get the same result when a footnotes are on a line of their own, but didn’t think at testing that use case.

    The best fix is to append each footnote somewhere, the way footnotes are.

    Even without any footnotes plugin active the Block Editor uses a heuristics to determine that on their line of their own, bracketed codes are shortcodes, because footnotes are always appended to something.

    Also in this case of isolated footnotes I cannot see any inconvenience in how it displays in the editor provided that on the public pages everything gets processed as usual, except that these are lone referrers.

    Would you like to post a screenshot of an actual post with footnotes in shortcode blocks how it renders on the web, or feel free to share a URL that you are having issues with so we can check and try to get the problem solved.

    Thread Starter Earl_D

    (@earl_d)

    I just used that example typically the footnotes are inline with sentence or paragraph but the same thing happens in block editor which is the problem been trying to resolve. I will post screen shot of the what happens and how it screws up the whole footnote display.

    • This reply was modified 4 months ago by Earl_D.
    Plugin Contributor pewgeuges

    (@pewgeuges)

    Indeed that is the bug that I assumed you are reporting, but that is also the setup I used to reproduce it yet failed, as in my configuration the bug only happens when a footnote is on a line of its own, not when it’s inline.

    I will look at the screenshot you are preparing and based on this, try to figure out where the problem comes from. Still that will be hard, since I figured it out all the time how it looks, I understand the problem that such a behavior of the Block Editor represents, and the way it destroys your posts by ripping all the footnotes out of context and dumping each one into an extra block, splitting all affected paragraphs into n+1 fragment paragraphs.

    The challenge is to reproduce the bug at my end (at our end). That is likely the precondition of fixing it, as else we don’t know if, nor when, any change to the existing codebase does fix this bug.

    Plugin Contributor pewgeuges

    (@pewgeuges)

    @earl_d,

    A similar issue was reported last year in https://wordpress.org/support/topic/how-to-avoid-new-paragraph-tags-before-and-after-shortcode/, and no solution has come up. The linked page having the issue seems however to have been fixed meanwhile.

    Screenshots are useful but most importantly, we need to look at the page source. So if your blog is live, and you are comfortable with sharing a URL, please go ahead.

    If there is a unique repetitive pattern, a last-resort solution could consist in opening an output buffer and editing the final HTML just before PHP shuts down.

    I’m sorry for being so clueless, basically.

    Thread Starter Earl_D

    (@earl_d)

    Found a work around that isn’t elegant but it works. When the footnotes are converted to shortcodes copy the reference without the opening or ending short code [ref] reference [/ref] and paste where it should be then add the closing or opening code back. This avoids the extraneous text being copied

    Plugin Contributor pewgeuges

    (@pewgeuges)

    Thanks for sharing the method.

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.