Change the position

@june01, @imeson, @spaceling,

We needed to roll back the general priority level change because it broke other websites while v2.0.5 was available. This is the responsibility of the other plugins adding features in the wrong place. It is not the responsibility of Footnotes.

Just one easy example: In YARPP, wp-content/plugins/yet-another-related-posts-plugin/classes/YARPP_Core.php(80) we have this line:

add_filter('the_content', array($this, 'the_content'), $content_priority);

where $content_priority is:

$content_priority = apply_filters('yarpp_content_priority', 1200);

Footnotes has instead, in class/task.php(63, now 84):

add_filter('the_content', array($this, "the_content"), PHP_INT_MAX);

When we replace $content_priority in YARPP with PHP_INT_MAX like in Footnotes, the reference container displays next to the list, above the Related-Posts. If not, this order is turned upside down.

Turned out that default replacing PHP_INT_MAX with 10 in Footnotes messed up many users’ databases, and we don’t even know how to fix them, beside everybody painstakingly hand-editing their posts.

Lesson learnt. When another plugin is conflicting with Footnotes, there is a chance that the other plugin</span> is defect. Assuming the opposite, I actually broke v2.0.5. v2.0.4 is safe to use.

Best regards.

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

Aharon,

Thank you. The bug has been found.

Please don’t use v2.0.6, upgrade to 2.0.7 instead, that is like current v2.0.8 except for priority level set to 10.

The hook “the_post” MUST NEVER BE ENABLED. It was the cause. You are spared because presumably you saved at least once the Expert mode settings. All users who never saved that tab lived with the defaults.

Please let me explain: For 2.0.5 I enabled the_title because a user started a support thread about footnotes not being supported in the title, before finding out by himself that there is a setting in the expert mode, hidden by default. So I found it pretty pointless to disable a feature that you just don’t use if you don’t want to. Disabling it by default only makes believe it is broken when a user decides to use it. So I went on enabling widget_title too. And — the last one likewise, in the wake…

The last hook in the list is “the_post”. When that hook is enabled, the WordPress engine runs Footnotes in the Block editor!!!! Footnotes will not be bracketed with shortcodes any more. All footnotes are converted to fully-fledged HTML. When, then, the editor is saved, the user needs to disable the hook and edit the saved post manually or using regexes to restore the shortcodes. If tooltip truncation is enabled, longer notes’ ends are lost!

I was in such a hurry fixing bugs and catching up on the forum.

But that hook should never have made it into the software.

As of priority level, I assessed it as safe again when releasing 2.0.7, given the bug came from the post hook. But then, considering all the users reporting footnotes moving up or down with 2.0.5, I returned to an even higher safety level by setting priority to PHP_INT_MAX as it was before 2.0.5, and released 2.0.8.

Footnotes 2.0.8 is our current stable release. 2.0.8 fixes many things and has zero critical changes.

Once any code related to the post hook is deleted from the plugin, every hook shall have a priority level setting field in the dashboard, and expert mode will change its name and no longer be a default-hidden tab.

I’m extremely sorry about all these events, and apologize to all impacted users of Footnotes.

Now I’m going on to apologize in all related threads, and link to this post.

Best regards,
@pewgeuges

Thank you very much for your feedback. I’m thankful to see the plugin working as intended and meeting expectations and requirements. Hopefully it will continue on this trajectory.

First the problematic post hook shall disappear from this plugin. A warning should be posted on the hook’s code reference page https://developer.wordpress.org/reference/hooks/the_post/

I must refrain from changing any more things in the hooks. Given YARPP is more stable until we’re done bugfixing, I’d suggest replacing $content_priority with PHP_INT_MAX in wp-content/plugins/yet-another-related-posts-plugin/classes/YARPP_Core.php(80). That has the same effect on relative ordering: Footnotes references container first, Related posts next, tested in Atahualpa and 4 others: GeneratePress, 2020, 2019, 2017 for short.

Then a main goal will be to add more settings to the numerous yet incomplete existing ones. Thank you for hand-editing while we’re striving to fix all remaining and reported bugs and responding on the Forum.

Best regards.

1. I didn’t know a three-column layout for footnotes was even an option — I’ve been wishing for something like that for a while.

2. I’m not clear on what ‘overline’ is. If it’s the opposite of an underline, then that’s not something I’ve styled in our CSS or hacked anywhere else on the site, as far as I can remember.

3. I have no strong feelings re: the space character in the custom symbol text box elongating the underline on hover. I like the idea of disabling the backlink symbol so that there is nothing besides the footnote number anchoring the link. If a custom template is the only way to do this moving forward, I’d be glad for one.

4. For whatever it’s worth, aside from the backlink symbol and the shade of yellow in their tooltip, I really like the styling for the Arctic Institute’s footnotes.

Thank you!!

But I think that you are rather referring to a layout where the reference container is broken into three parts displayed side by side. Am I correct?…Do you wish for this?

Yes, yes and thank you!

As a brief follow-up, we can now report that YARPP uses priority 1200 for the_content. For Footnotes, this proved to be the threshold to display its reference container above YARPP’s related posts. Footnotes has now priority level settings and ships with 1000 for the_content as a default.

The overline disappeared after commenting out some style rules, namely:

/*
These rules when enabled cause the backlink to take an overline
when hovered in some themes, not in others:
.footnote_plugin_index:hover,
.footnote_plugin_index_combi:hover,
.footnote_plugin_index.pointer:hover,
.footnote_plugin_index_combi.pointer:hover,
*/

The overline was in fact a fallback for a nested element when its parent had an underline too.

The following rules remain valid:

.footnote_backlink:hover,
.footnote_plugin_link:hover,
.footnote_plugin_text a:hover {
    text-decoration: unset;
    text-decoration: underline; /*deprioritized to ease customization*/
}

(The comment means that !important has been deleted.)

For the rest: If used, the backlink symbol can now switch side too when identical footnotes are combined. But the footnotes list layout in 3 columns is not ready yet; it will hopefully be in an on-coming feature release.

2.1.4d8 is currently as a prerelease at https://downloads.wordpress.org/plugin/footnotes.zip

Meanwhile this thread will be marked as resolved.

Kind regards.

Hi Jay,

Thanks a lot for joining in! Just discovered your quick feedback. Thank you!

Surprisingly many issues arise from priority conflicts and are resolved by setting Footnotes’ level appropriately. At some point when Footnotes still lacked that setting and I was uneasy with it, I even suggested to edit classes/YARPP_Core.php:80 (line 76 more properly) until Footnotes was able to provide, setting it to lowest PHP_INT_MAX equal to Footnotes’ level (and probably letting alphabetical order do the rest). When later, priority level became a setting, the Expert mode dashboard tab where it’s been added next to the hook check boxes, was set to visible by default (it was hidden and required an action on a toggle). Some plugins when running first even prevent Footnotes from working at all.

To ensure a hassle-free UX with WordPress, I’d suggest teaming up to propose an official WordPress plugin priority pool assigning default priorities on the basis of average user expectations, or offering only a central dashboard with support from moderators. Yet the backend might look like a huge DB with PHP_INT_MAX == 9 223 372 036 854 775 807 rows. Could that scheme gain traction?

A possible alternative would consist in every content-editing plugin coming with prominent priority level settings, urging WordPress users to define the right mix by trial and error. That scheme would add a layer of complexity and get the blog engine a bit farther from working out of the box, but already spare its users lots of headache.

In upcoming 2.1.4, Footnotes shall describe the priority level setting feature like this:

The priority level determines whether Footnotes is executed timely before other plugins, and how the reference container is positioned relative to other features.

Default 9223372036854775807 is lowest priority, 0 is highest. To restore default priority, set to -1, interpreted as 9223372036854775807, the constant PHP_INT_MAX.

For the_content, this figure needs to be lower than 1200 to make sure that the reference container displays above features inserted by other plugins running at 1200 or a greater/lower level, later in the process.

If you would like to do something similar in YARPP, I think that all users would highly appreciate.

Please feel free to ask us anything needed to get the CMS running smoothly.

Looking forward,

Best regards,
@pewgeuges

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