Problem since footnotes.2.5.14

Hello @docteurfitness

Thank you for reporting as I didn’t see this, none of us did see the bug where every second reference remains unprocessed. What 2.5.14 was about is a numbering disorder that happened when escaped and unescaped shortcodes with pointy brackets are mixed. The algorithm has been redesigned to improve the handling of these shortcodes as listed in the changeset difference view on SVN:

https://plugins.trac.www.ads-software.com/changeset/2502988/footnotes#file23

Previously, the search was repeated twice (then thrice because in 2.5.13 I fixed wrongly the unbalanced pointy bracket escapement by adding a third run). Since 2.5.14 the plugin harmonizes all pointy bracket shortcodes to begin with, then processes all footnotes in order.

I much appreciate your help pointing the exact version. Thank you also for going to the trouble to keep up with the unreleased bugfix versions by downloading individually. Sadly we must mitigate release frequency while trying to keep timely delivering all bugfixes as we get solutions. It would be of help to know if this happens only with the [ref][/ref] shortcodes, but I can’t figure out the reason why. I’m clueless and don’t see how to investigate, but I’ll stop trying to fix the excerpt bug and run some checks instead, to see if anything comes up at my end.

Thanks for your patience.

@docteurfitness,

I’ve tried to reproduce the same use case using [ref][/ref] delimiter shortcodes in my local sandbox:

2.5.14:
https://ibb.co/Wp8tXMB

2.6.1:
https://ibb.co/NSsXQbf

With 2.5.14 I’ve expanded the reference container for the screenshot; all 4 citations are the same because to speed up I copy-pasted a single one in 4?instances. (The images are auto-deleted after 1?week.)

The 2.6.1 test is because I started with what I’m on, but then I switched to 2.5.14. These tests show all four references as footnotes, no [ref][/ref] tags anymore, and all citations in the container.

Since 2.5.14 Footnotes stopped searching for &?lt;ref&?gt;(footnote)&?lt;/ref&?gt; first, then for <?ref>(footnote)<?/ref> and appending these at the bottom of the list, with out-of-sequence footnote numbers in the text, as @gova reported lastly. Sadly I didn’t notice the problem sooner, not even when @gova reported it did I see the problem. Fortunately the solution came up and the fix was implemented, but now it appears that I introduced a new bug in the process.

Please help me understand.

Thank you!

I’m really sorry, I don’t have enough skills to solve this problem.

I hope @gova will find a solution ??

@docteurfitness,

Thanks for your advice. Basically it’s up to us to help @gova and other users to get rid of bugs. I could see the numbering disorder diappear because I’d been able to make it happen in my sandbox, and once fixed I posted an account in @gova’s support topic, crediting also preceding reporters @patrick_here and @alifarahani8000 in whose threads I need yet to acknowledge while in the meantime they get a notice from the Forum engine so I can limit the number of posts. Even saw a topic from over one year ago about the same disorder, topic that cannot receive updates any more (nor does the linked website get any, else it’d be fixed now).

What I need is the ability to reproduce the bug you’re reporting, or there’s no chance for me to get it fixed. To assist me please could you share the page source as it is in your editor: in the Block Editor switch to Code Editor; in the Classic Editor switch to Text mode; and please copy-paste what’s in, sorry to ask for that; it would also be helpful to produce some dummy text like I often do for test purposes. You see that I rewrote your four short paragraphs and one complete reference, used the same shortcodes, and modeled your use case to test the outcome on my end, but I didn’t succeed in reproducing the bug.

As looking into the finished web page is not helpful in this case, we need to know how it was generated. Also please may I ask you to copy-paste the content of the footnotes_storage settings container in the wp_options DB table into a code snippet bracketed with backticks like this:

Your footnotes_storage

Alternatively you may wish to share the information online as you already did in other issues beside the screenshots hosted on ImgBB.

Hopefully these two documents will help us investigate the bug further and eventually fix it.

Thanks in advance!

[Large code excerpt removed by moderator per our FAQ. Please use Pastebin or a Gist for all large code excerpts, they work better anyway.]

• This reply was modified 3 years, 12 months ago by Yui.
• This reply was modified 3 years, 12 months ago by Yui.

sorry,

maybe this will be more clearer:

<p>En effet, des études ont mis en évidence le r?le anti-inflammatoire du lycopène vis-à-vis de certains types de maladies et cancers, notamment ceux du foie, des poumons et du c?lon<span class="footnote_referrer"><span role="button" tabindex="0" onclick="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_7');" onkeypress="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_7');"><sup id="footnote_plugin_tooltip_17867_1_7" class="footnote_plugin_tooltip_text">(7)</sup></span><span id="footnote_plugin_tooltip_text_17867_1_7" class="footnote_tooltip"></span></span>[ref]Palozza, P., et al. ? <a aria-label="Tomato Lycopene and Inflammatory Cascade: Basic Interactions and Clinical Implications (opens in a new tab)" href="https://pubmed.ncbi.nlm.nih.gov/20491642/" target="_blank" rel="noreferrer noopener" class="rank-math-link">Tomato Lycopene and Inflammatory Cascade: Basic Interactions and Clinical Implications</a> ?. Current Medicinal Chemistry, vol. 17, no 23, 2010, p. 2547?63. PubMed, doi:10.2174/092986710791556041.[/ref].</p>

without bug (2.5.13) :

<p>En effet, des études ont mis en évidence le r?le anti-inflammatoire du lycopène vis-à-vis de certains types de maladies et cancers, notamment ceux du foie, des poumons et du c?lon<span class="footnote_referrer"><span role="button" tabindex="0" onclick="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_7');" onkeypress="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_7');"><sup id="footnote_plugin_tooltip_17867_1_7" class="footnote_plugin_tooltip_text">(7)</sup></span><span id="footnote_plugin_tooltip_text_17867_1_7" class="footnote_tooltip"></span></span><span class="footnote_referrer"><span role="button" tabindex="0" onclick="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_12');" onkeypress="footnote_moveToReference_17867_1('footnote_plugin_reference_17867_1_12');"><sup id="footnote_plugin_tooltip_17867_1_12" class="footnote_plugin_tooltip_text">(12)</sup></span><span id="footnote_plugin_tooltip_text_17867_1_12" class="footnote_tooltip"></span></span>.</p>

where can I have the “Your footnotes_storage” ? ??

Best regards

Sorry to see that your code has been removed by moderation.

The footnotes_storage is found under the options key in the DB of your WordPress instances.

But lets look at your other two code snippets. The first one is a concatenation of a sentence, a processed footnote and an unprocessed one, while the second snippet is the sentence followed by a sequence of two processed footnote referrers.

The screenshot however shows four short paragraphs, each one with a footnote, one out of two processed, the other two unprocessed.

So I’ve tested the new use case, appending two footnotes one immediately after the other, still using [ref][/ref] delimiter shortcodes. The outcome is the expected sequence of two referrers.

As WordPress recommends Pastebin, I’ve just created a free account, we can set expiration to 1?day, make it private, and get links like https://pastebin.com/B9MgS8UM to share our code.

Sorry that you’d need to go to the trouble to share your editor and settings, as otherwise I see no way to get anything closer to an investigation. The page source snippets have been useful in that they draw my attention to the idle code only used for tooltips and included even when tooltips are disabled, in a legacy attempt to keep the template number minimal by streamlining the library. Since the number has increased from 4 to 17, we could as well add extra templates for instances not using tooltips, and shorten the fragment IDs a bit in the process. But as long as there are pending bugs, missing features and other high-priority tasks (on my end), we shouldn’t spend time on low-priority refactoring as we did in February. (BTW we should stop issuing unreleased bugfixes, because it appears that appears that SVN publicity is not enough as a warranty. Not releasing bugfixes seems so stupid.)

@docteurfitness,

One thing you may wish to do on your end to debug the page that you shared a screenshot and page source snippets of is to check for the presence of hidden characters in those footnote delimiter shortcodes that remain unprocessed. Unicode has a number of characters designed to assist rendering engines in making a better sense of textual data. One of them is a character that typists can insert to prevent a ligature, called (in Unicode character name uppercase) ZERO WIDTH NON-JOINER, commonly abbreviated ZWNJ. Since it’s needed in current writing and digital typesetting, this character may be easily keyed in and may be repurposed to prevent a forum engine from mistaking [?[shortcodes]] as keywords — this has been converted to a link despite it is bracketed with backticks to be formatted as code and rendered verbatim — as well as from parsing <?a><?/a> outside of code.

You may check that easily using a regex like (\[.+?r.*?e.*?f.*?\]|\[.*?r.+?e.*?f.*?\]|\[.*?r.*?e.+?f.*?\]|\[.*?r.*?e.*?f.+?\]) because the problem must be in at least one start tag, else you’d get a warning about unbalanced shortcodes; and also swiftly fix all delimiters by replacing \[.*?(/?).*?r.*?e.*?f.*?\] with [$1ref].

Still I’d not understand why the outcome differs between versions. If there is a change it must be visible in https://plugins.trac.www.ads-software.com/changeset/2502988/footnotes#file1 but I’m failing to find the error.

Best regards.

• This reply was modified 3 years, 12 months ago by pewgeuges. Reason: Note about link conversion inside of backticks
• This reply was modified 3 years, 12 months ago by pewgeuges.

@docteurfitness

Teammate @lolzim has noticed a bug occurring when clicking the backlink arrow while link elements are enabled, but both arrow and number when not. That bug is in 2.5.13 too and requires you to either revert to 2.5.10 (or update to new 2.6.3 where the bug gots fixed), or to delete this code in footnotes/templates/public/reference-container.html:

jQuery( 'span' ).click( function( event ) {
	event.stopPropagation();
});

That was added while I tried to prevent a click on a footnote referrer in a checkbox label in a WPForms form from checking the box.

Thanks to @lolzim, we’re shipping the fix as your website is severely affected, using span elements instead of the usually preferred link elements, also for the backlink numbers, so visitors can hardly scroll up again.

Related changelog item:
– Bugfix: Reference container: debug span elements in backlinks by removing ‘event.stopPropagation()’ from jQuery scroll down function, thanks to @lolzim bug report.

Also added the corresponding item in the 2.5.11 changelog a posteriori:
– Bugfix: Forms: try to prevent the adverse effect of clicking footnote referrers in labels of input elements by ‘event.stopPropagation()’ in jQuery scroll down function.

As I understand it now, the click event needs to be propagated from the span to the table header cell where the function is called. But this being a jQuery method, it’s ineffective to prevent HTML click handling, hence its ineffectiveness to prevent a click on a footnote referrer handled by jQuery from being processed as an HTML event in the parent label element from whence it’s linked to the input element of checkbox type to check the box while the visitor only intended to look up a footnote in the reference container.

I remember that I wasn’t careful when leaving that code as it proved ineffective, thinking only it would serve later but forgot to comment it out, then moved on in a hurry.

Also for you I’ve diffed v2.6.2 against v2.5.13, and in the changed files list I’ve picked class/task.php as containing the most sensitive changes. I’ve checked all changed instances one by one and can guarantee there’s nothing that would cause you the issue you’re currently experiencing. I’ve vainly attempted to reproduce the bug you reported, and we didn’t get hold of the most useful data that would enable us to reproduce the exact configuration that you’re seeing the bug in.

So I think you can safely test the newly released v2.6.3 on your staging site. But I do feel with you because while all PHP files in the plugin’s codebase were refactored with the initial goal of making it comply to WordPress PHP Coding Standards (https://developer.www.ads-software.com/coding-standards/wordpress-coding-standards/php/), the plugin was broken by deferring jQuery Tools to the footer so the tooltips didn’t display any more, and by escaping all output. When noticing that the plugin was broken, the escapement function calls were totally removed, including the preexisting one so the plugin was still broken. Because the search used to make sure no escapement function was left, was not run on the preexisting codebase to see the one instance that needs escapement.

Right now we mustn’t simply revert to the preexisting codebase and redo the whole reformatting without the oversteppings. I always advised to not reformat anything before all bugs have been fixed;?and frankly: Working in the WPCS compliant codebase vs Footnotes’ previous codebase is not that much different.

Luckily since we know about the flaws and bugs mentioned above, they’ve hopefully been fixed altogether.

You see how I’ve introduced a brandnew bug in 2.5.11 that I didn’t know anything about until @lolzim found it out. I’m thanking @lolzim and apologizing to all who have been impacted. Fortunately the backlink arrows are often so tiny they hardly get a clicked. But your website is particular in that the link elements are disabled and spans are used instead via the related setting at the bottom of the Reference container metabox. My special apologies to you!

Best regards,

@pewgeuges

• This reply was modified 3 years, 12 months ago by pewgeuges.
• This reply was modified 3 years, 12 months ago by pewgeuges.

Hello,

It still doesn’t work for me despite the updates.

I attach a video to illustrate this, sorry for the sound, I did not think it would be recorded.

https://streamable.com/1076c3

Thank for support

Hello,

No problem, thanks for the screenrecord. Now the third and fifth footnotes are processed and the fourth remains unprocessed instead, compared to the screenshot. Is this change due to the change in plugin version? The backlinks are fully working so what we see is probably current v2.6.3. Does that happen on other pages too?

What we see was version 2.6.3. It’s the same thing with version 2.6.4.

So for now I stay with version 2.5.13 with which everything works fine.

What did you change between version 2.5.13 and 2.5.14?

The answer is here ??

Thanks for the support

@docteurfitness,

Please don’t keep using 2.5.13, it disables your backlinks due to that leftover in the jQuery part of the reference container template. That’s my fault, and @lolzim found the bug, fixed in 2.6.3. So you should use either 2.5.10 or 2.6.4.

The changes between 2.5.13 and 2.5.14 are listed in two diffs:

https://plugins.trac.www.ads-software.com/changeset/2502990/footnotes

That is only about the dashboard, that I’d forgot to update and exceptionally corrected immediately both in trunk and in the new tag because 2.5.14 was not released, only tagged.

The important changes are listed in this changeset, linked from the previous one in the “Previous Change” button in the upper right corner:

https://plugins.trac.www.ads-software.com/changeset/2502988/footnotes

The changelog items of 2.5.14 are:

• Bugfix: Footnote delimiter short codes: fix numbering bug by cross-editor HTML escapement schema harmonization, thanks to @patrick_here @alifarahani8000 @gova bug reports.
• Update: Dashboard: General settings: Footnote start and end short codes: delete comment on pointy brackets.

Later I’ve replaced “harmonization” with “unification”. The plugin searched separately for escaped and unescaped shortcodes, so that numbers got easily out of sequence. In 2.5.13 I made it worse by adding a third run, for semi-escaped shortcodes as generated in the Block Editor viaual mode.

The right way consists in first unifying the different shortcode presentation forms, then doing a single search to list the footnotes one by one in an ordered list.

That however does not affect the square bracketed shortcodes you’re using. The unification process is run only if the shortcodes contain any HTML escapable characters.

Hope that makes sense and clears up the situation. I’d love being able to reproduce the bug. Don’t mind sharing the text (https://pastebin.com/) that you can copy-paste in code editor mode when editing the problem page in the Block Editor, or in text mode in the Classic Editor.

Hoping we’ll get closer to a solution when we have a chance to reproduce the bug and try out what could fix it.

@docteurfitness,

While releasing urgent bugfix v2.6.5 now I’ve also added a temporary v2.5.13.1 available for your convenience. Please download it from https://downloads.www.ads-software.com/plugin/footnotes.2.5.13.1.zip for your production website because it fixes the backlink outage (only).

You may wish to track the change looking up the related file diff in the changeset:

https://plugins.trac.www.ads-software.com/changeset/2507205/footnotes#file3

This temporary tag shall be removed once you had a chance to assess another version as safe, but it shall remain until you are effectively ready to upgrade.

To investigate the problem you are raising, I’ve looked up again each changed instance in https://plugins.trac.www.ads-software.com/changeset/2502988/footnotes#file1 but failed to find any problem.

When facing a bug, best practice is to investigate the bug as it happens. That’s why you’re always asked to help reproducing the bug by listing the steps needed, since this bug is not present by default. If you cannot easily identify those steps, you would help us a lot by providing us with the means to reproduce the bug. I’m sorry to ask for so much.

And above all I’m sorry for causing the backlink outage while failing to fix an unrelated bug by the means of this jQuery method.

Thank you!