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 4 years ago by pewgeuges.

oof, what a nightmare.

I use YARRP on my site. Thankfully, I haven’t experienced any of the DB issues others have after replacing PHP_INT_MAX with 10. I don’t know why.

Do you think it might be dangerous for me to continue with this hack so long as I continue updating Footnotes while YARRP is activated?

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

I updated to 2.0.8 and deeply appreciate the changes you made… and with them, all the investment you made in troubleshooting all these issues — and crucially, explaining them to me and others here.

I understand the significance of these hooks now, something I hadn’t before.

There’s one plugin that I have which I need to place just after Footnotes, so I did need to replace PHP_INIT_MAX with 10 for THE_CONTENT — and that worked out without any trouble, thankfully.

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.www.ads-software.com/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.

@spaceling

Prior to releasing our 2.1.1 bugfix, the Footnotes reference container position relative to YARPP is now permanently fixed by a settings option next to the the_content hook checkbox. As a preview, our current development version?2.1.1d10 has just become available at https://downloads.www.ads-software.com/plugin/footnotes.zip

Also, an optional reference container layout using a template very close to the one you were maintaining, i.e. with an appended symbol instead of a prepended one, can be enabled, too, but for now only when combining identical footnotes is disabled, and the legacy three-column layout option is, too.

This has also an option to disable the backlink symbol rather than doing as I suggested by the means of a space character in the custom symbol text box, as a quick fix when I wasn’t ready yet. The space elongates the underline, that is set to show on hover.

Would you welcome support for a custom template, that could be used without being overwritten when updating?

However, when hovering the backlinks, I see them taking an overline. Switching theme from Atahualpa to Twenty?Twenty did fix it, but the string ‘overline’ is not found in the theme’s files. Nor does the inspector mention anything related other than underline. I’d be curious to know if that is limited to my computer. It’s so awkward, one cannot have that behavior on a website in the Footnotes references container.

I must confess that I’m fairly new to WordPress (really started this year). So I did ignore everything about those hooks, and not even suspected the engine to yield so harmful a function. But I was afraid to admit it, by fear of harming the project, and the plugin.

• This reply was modified 4 years ago by pewgeuges.

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!!

Thank you a lot for your feedback. I’m overwhelmed (and also dismayed that I didn’t get those things right). We’ll try our best to come closer to meeting expectations. Some points also remain unclear to me:

1. The three-column layout I referred to above was used by the plugin until v1.6.6. The second column was taken up by the backlink symbol. It was dropped when v2.0.0 was released (and that disruption was the reason to increment the major version number). But it turned out that part of our users keep maintaining a three-column custom layout. This is now becoming an option, and classes are added so that everything can be implemented using Custom?CSS and the plugin’s settings. (This layout is incompatible with combined identical footnotes.)

   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? That is indeed a very good option on desktop devices when footnotes are short and numerous, or to improve readability in large windows. Do you wish for this? If so, we shall look into how to implement it, probably using three divs that will automatically flow and stack on mobile, or using responsive CSS, and an algorithm to divide the container’s content.

2. I’m sorry not to have mentioned that I saw the overline only in v2.1.1d10 of the plugin (currently available for download under the advanced tab of the platform) and in Atahualpa, that I’ve added to my test panel to account for your use case. On opensiddur.org, currently using v2.1.0, the underline still works. I’m just committed to mention my new problem in case I’ve messed styles up somehow in an unprecedented and unknown manner, that is perhaps easy to parse for others, but not for me.
3. I’m relieved that disabling the backlink symbol is now state-of-the-art with an extra select box in the dashboard > Settings > Reference container > Display a backlink symbol -> No. That sets it to an empty string right in the script generating the reference container. No custom template is needed to disable the backlink.

   By contrast, if a site owner prefers a symbol switching side or otherwise specially placed. a custom template would be the only option. It shall be added as welcome, and we need to check if a renamed file is safe in the plugin’s folder. But given there are other bugs we need to fix, we can’t make it priority unless it is expected.

4. The Shalimar color https://www.htmlcsscolor.com/hex/FFF7A7 was the plugin’s default tooltip background color until it was set to white for our v2.0.7, because I don’t like it neither and am aware it should be avoided. Some newspapers did start opting for it in text boxes in color print since the early 2000s, at a time when individuals hadn’t started buying white cars yet. The organization considered trying white. I like the light blue tooltips on Open?Siddur too.

   But as you probably would say, the reference container has a problem in mobile view. https://ibb.co/G0RT6b1 shows the rendering in Chrome’s developer tools emulating a Nokia?Lumia. Comparing 3?websites’ reference containers in mobile view, each one has a different issue. HTML tables are somewhat outdated, yet Footnotes relies on them for the references container. We need to look into this. Please feel free to post details about how you would like things to change for the Footnotes plugin to improve usability.

Thank you again very much!

• This reply was modified 4 years ago by pewgeuges.
• This reply was modified 4 years ago by pewgeuges.
• This reply was modified 4 years ago by pewgeuges.
• This reply was modified 4 years ago by pewgeuges.

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!

Thank you for your message. That will definitely be the way to go for Footnotes default reference container layout, certainly using CSS’ autoflow grid layout algorithm.

Hopefully that shall be ready soon!

For now to release 2.1.1 we need to fix the bug switching underline to overline when the table cell is hovered (and backlink is active), before adding the underline to the index number when pointed precisely.

As of the priority levels, the setting is about to be extended to all supported hooks under the Expert?mode dashboard tab, and a value of -1 shall be interpreted as PHP_INT_MAX, that is also the default, although when using YARPP it should be set to 10 for the_content, as you are doing.

Sorry for the extra delays. We’ll do our best and I need to complete ASAP.

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.www.ads-software.com/plugin/footnotes.zip

Meanwhile this thread will be marked as resolved.

Kind regards.

Hi All,

It sounds like the issue is resolved, but if you’d like us to take care of anything on YARPP’s end, do let us know. Here for you.

Best,
Jay

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, 11 months ago by pewgeuges.
• This reply was modified 3 years, 11 months ago by pewgeuges.
• This reply was modified 3 years, 11 months ago by pewgeuges.

P.S. — The hook priority level description under Footnotes’ dashboard Expert mode tab was slightly edited for the post above; this version is now in our current development v2.1.4d9 available at https://downloads.www.ads-software.com/plugin/footnotes.zip and will probably be in our upcoming 2.1.4 release.

P.P.S. — The DB table mentioned above would of course only need a row per participating plugin, beside that the number of available priority levels is one more than PHP_INT_MAX.