images blurry and showing attachment details

@russianicons

Please disable URL wrap in the dashboard under General settings > Reference container > Allow URLs to line-wrap anywhere. This fixes the Footnotes related issue, but there are more problems in your page and I think Fusion should be able to fix them.

Meanwhile I’ll try to find out, but please already disable Footnotes URL wrap.

URL wrap is needed to fix Footnotes’ reference container and tooltip display in Unicode non conformant browsers like Chrome, but your website may not require this fix.

On your page the problem arises from the source set enumerating URLs separated by comma and by whitespace. I’m surprised that whitespace is used in comma-separated values consisting of URLs. I’m interested in correcting the regex so as to catch and exclude all possible cases of URLs as argument values. After several bug reports and related or proactive fixes — see https://www.ads-software.com/support/topic/broken-layout-starting-version-2-1-4/ and https://www.ads-software.com/support/topic/2-1-4-breaks-on-my-site-images-dont-show/ as well as https://www.ads-software.com/support/topic/footnotes-on-mobile-phones/ for the bug fixed by URL wrap — it is now:

#(?<![-\w\.!~\*\'\(\);]=[\'"])(?<![-\w\.!~\*\'\(\);]=)((ht|f)tps?://[^\\s<]+)#

You see that a srcset argument that contains space (\\s) in its value does not have its URLs handled correctly by Footnotes. But disabling URL wrap by default is likely to cause more issues.

My apologies for breaking your website and causing trouble to you and the Fusion support.

Hopefully you will timely get hold of all needed fixes!

@russianicons

Wondering why fully fledged responsive images — with srcset arguments, that indeed need whitespace in their value syntax — end up in footnotes in the first place, it turns out that several footnotes have unbalanced shortcode opening tags, not followed by a closing tag where the footnotes end. That is why several parts of the dissertation are mirrored in footnotes, prolongating the actual text of these footnotes. The same blurred images are there, too. Footnotes is not supposed to URL-wrap anything outside footnotes text; mistakenly not correctly ended footnotes are causing this. That is likely to be overlooked because the footnotes container is collapsed by default, hiding part of the issue and preventing from noticing that the issue is actually caused by syntax errors in the article source.

Trying to give you an example, I think that footnote #40 should end after the first period, because one sentence later, footnote #41 starts. Each unbalanced footnote opening tag is closed by the next found closing tag. Surprisingly this does not reflect in the tooltips, e.g. the tooltip text #40 ends in front of the next opening tag shortcode, while in the reference container, the footnote text goes until the end of footnote #41. That causes the article to be incomplete after some snippets are unduly moved to the references section.

I’ll already post this as an urgent complement so that you have enough time to fix the article while I’m looking into repeated nested inline CSS and div end tags highlighted in red by Firefox in the page source, that are likely to not come from Footnotes, that has only two closing div tags in public files, both in the reference container template (all others are for the dashboard). I don’t know yet whether these problems come all from wrongly dissecating the article based on unbalanced footnote shortcodes; I’ll post more if other findings come up.

@russianicons

All other issues mentionad above are due to the Fusion flex box ending up in footnotes because of missing closing tag short codes. Page builder boxes are probably never intentionally part of footnotes, so presumably we won’t need to address the related issues nor the srcset values not to be considered human readable URLs. That said, I’m still interested in a better regular expression.

The images are blurred because all but the first source URL are disabled by wrapping them in <?span class="footnote_url_wrap"?>…<?/span?> tags. As these URLs are enumerated in ascending resolution order, browsers only get the 200×133px size, missing out on up to 800×534px. These URL wrap spans were presumably spotted by Fusion Support team, that as a consequence directed you to request support from the plugin. Well done since we’re supposed to be in a better position to point you to the article source text as the culprit.

I’m sorry that you are still having trouble related to shortcodes after you requested a conversion tool from the DOCX format. As posted six days late there in https://www.ads-software.com/support/topic/counter-styles-not-working/page/2/#post-13800538 a tool does exist as a plugin for Word, I think it might already address the issue we need to solve as part of the Footnotes service.

Based on this, I also see that Footnotes must include a validation tool checking for balanced shortcodes and reporting all instances of two subsequent opening tag short codes without a closing short code in between, like PHP compilers do report syntax errors. Without that convenience I’d be stuck.

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

@russianicons

I mistook brands one for another, heading right into the page source. Sorry, you worked with the Avada page builder support from ThemeFusion (hence the “fusion-*” class names in the code).

The last paragraph issue I overlooked—I’m sorry for that—may be related to a missing closing tag short code. But as I can see it’s fixed now. I see a lone start tag short code in the copy I saved on the spot to track the issue down. As a side note I’d mention that while the copy-protecting plugin disables opening the source code and a couple more actions, it fails to do so for saving the page—fortunately for instance, as else it would have been hard for me to post anything helpful in response unless some hopefully accumulating experience enables extrapolating assumptions. Noticing the issue I just needed to suppress six images from the page in the saved files folder and empty the trash. Thankfully it’s the very page you reported the previous issue with; I’m happy about the success.

Eventually upcoming Footnotes v2.3.0 will include an option to validate the Footnotes short codes, but I can’t promise anything timely as I’m also struggling to debug the half-finished optional hard links scheduled for 2.3.0.

In the meantime to assist you with meeting the deadline I’d suggest to copy-paste the post text from the WP editor into a text editor, delete line ends and then run this regular expression:

\(\(((?!\)\)).)*?\(\(

It helps spot unmatched open tag (( short codes not accurately followed by )).

But as mentioned Footnotes should show a red warning right below the post title to help easily track the problem.

Thank you for the great work you are performing! Safe—and happy—Holidays.

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

@russianicons

The plugin had a design flaw causing it to silently process invalid shortcodes. We apologize for that defect. Current development version 2.3.1d0 does check the syntax and displays a warning below the post title in case of an unbalanced opening tag short code. Meanwhile it processes the shortcodes as-is but shows the exact location of the unbalanced shortcode by quoting the following text so that the publisher can easily fix it in the WordPress editor.

Also I see that the reported article is fixed and am glad that it’s meeting the deadline. Sorry for the trouble. Please feel free to already check out v2.3.1d0 for convenience, as we cannot do a release right now so shortly after yesterday’s overdue 2.3.0, although the syntax validation feature is considered a bugfix.

Healthy New Year.