Support » Plugin: footnotes » Change the position

  • Resolved june01

    (@june01)


    Hello,

    I am using different plugins to display something after a post content but the footnotes are displayed after all of them. I want to display the footnotes before the other plugins. How can I do that?

Viewing 15 replies - 1 through 15 (of 29 total)
  • Plugin Author Lol Zimmerli

    (@lolzim)

    Hello june01,

    We *may* have a solution later. We are in teh process of finishing other things for next release, but this should come just after.

    Best regards

    @lolzim this would be super helpful to be able to control where this goes after the post content. Like setting the priority as there are other plugins like social sharing, related posts, etc. that in our case all show above this.

    Close to having this capability?

    Plugin Contributor pewgeuges

    (@pewgeuges)

    Hi all,

    This is now being fixed and will be part of the next bugfix release v2.0.5. It didn’t make it into v2.0.4 released today shortly after midnight, but the next should follow soon. Sorry for the inconvenience and the delay.

    Footnotes should always go with the content, so a setting is probably not needed. Priority is defined in class/task.php from line 60 on. It is now set to highest. It was lowest as “PHP_INT_MAX” since priority levels are numbered the other way around.

    E.g. now, Yet Another Related Posts Plugin 5.10.1 displays the Related posts section below the Footnotes references container (before, it displayed it above).

    Please let us know if a plugin does not display in the right place WRT Footnotes. That may be due to conflicting priority levels since ordering plugins with the same priority relies on less meaningful mechanisms such as alphabetical order. In such a case, the other plugin should be deprioritized, given footnotes will be top priority.

    Best regards.

    Plugin Contributor Aharon

    (@spaceling)

    So glad to hear this is getting worked on. I’ve been hand editing the plugin code after every update to replace “PHP_INT_MAX” with “10”.

    Plugin Contributor pewgeuges

    (@pewgeuges)

    Hi @spaceling,

    Thanks for your feedback. Sorry for the trouble.

    Since 10 is default priority, I went on replacing PHP_INT_MAX with 1 from the 3ʳᵈ instance on, to make sure footnotes get appended the closest possible, afraid that 10 would catch less cases.

    But given 10 works for you and for me but only when set explicitly, not when coming in as default, that’s the better option leaving opportunities to top priority features.

    Best regards.

    Plugin Contributor Aharon

    (@spaceling)

    I don’t know why this happened, but after updating, footnotes moved up… way up to the top of my post (above the post body). Definitely not the behavior I saw in previous releases after replacing “PHP_INT_MAX” with “10”. Alas, rolling back to 2.0.4 for the time being. (Thank you so much for your work in any case!)

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

    (@pewgeuges)

    v2.0.4 is current. Before committing I checked everything in 2020 and it is OK, Which theme are you using so I can test footnotes in it?

    Which instances of PHP_INT_MAX did you replace, in case that matters? I could replace it with a big number and the refs container still stuck with the post, just not PHP_INT_MAX nor empty.

    Or would you mind sharing a screenshot?

    Thanks a lot for your valuable feedback!

    Plugin Contributor Aharon

    (@spaceling)

    Thank you @pewgeuges. I’m using Atahualpa (Version: 3.7.24 by BytesForAll).

    In footnotes 2.0.4, I had replaced all instances of PHP_INT_MAX in task.php with 10. Here is the code:

        /**
         * Register WordPress Hooks to replace Footnotes in the content of a public page.
         *
         * @author Stefan Herndler
         * @since 1.5.0
         */
        public function registerHooks() {
            // append custom css to the header
            add_filter('wp_head', array($this, "wp_head"), 10);
    
            // append the love and share me slug to the footer
            add_filter('wp_footer', array($this, "wp_footer"), 10);
    
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_TITLE))) {
                add_filter('the_title', array($this, "the_title"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_CONTENT))) {
                add_filter('the_content', array($this, "the_content"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_EXCERPT))) {
                 add_filter('the_excerpt', array($this, "the_excerpt"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_WIDGET_TITLE))) {
                add_filter('widget_title', array($this, "widget_title"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_WIDGET_TEXT))) {
                add_filter('widget_text', array($this, "widget_text"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_POST))) {
                add_filter('the_post', array($this, "the_post"), 10);
            }
            // reset stored footnotes when displaying the header
            self::$a_arr_Footnotes = array();
            self::$a_bool_AllowLoveMe = true;
        }

    SCREENSHOTS

    https://opensiddur.org/wp-content/uploads/2016/11/footnotes-2.0.4-example.png

    https://opensiddur.org/wp-content/uploads/2016/11/footnotes-2.0.5-example.png

    Here’s the actual post from which the screenshots are derived (running footnotes 2.0.4):
    https://opensiddur.org/?p=14653

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

    (@pewgeuges)

    Thank you Aharon @spaceling for this documentation.

    I’ve tested footnotes v2.0.5 in Atahualpa v3.7.24, and the bug moving the reference container at the top has not been reproduced so this is not a theme incompatibility issue.

    Also the code you posted is the exact same as what we’ve released in the current stable v2.0.5, because we aligned on your experience, i.e.:

    
        /**
         * Register WordPress Hooks to replace Footnotes in the content of a public page.
         *
         * @author Stefan Herndler
         * @since 1.5.0
    	 * 
    	 * Edited for v2.0.5   2020-11-02T0330+0100
    	 * Edited for v2.0.6   2020-11-03T1322+0100
    	 * 
    	 * Explicitly setting all priority to default "10" instead of lowest "PHP_INT_MAX", 
    	 * especially for the_content, or footnotes won’t display beneath the content but 
    	 * below other features added by other plugins.
    	 * Although the default, 10 seems to suffice.
    	 * Requested by users: <https://wordpress.org/support/topic/change-the-position-5/>
    	 * Documentation: <https://codex.wordpress.org/Plugin_API/#Hook_in_your_Filter>
         */
        public function registerHooks() {
            // append custom css to the header
            add_filter('wp_head', array($this, "wp_head"), 10);
    
            // append the love and share me slug to the footer
            add_filter('wp_footer', array($this, "wp_footer"), 10);
    
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_TITLE))) {
                add_filter('the_title', array($this, "the_title"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_CONTENT))) {
                add_filter('the_content', array($this, "the_content"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_EXCERPT))) {
                 add_filter('the_excerpt', array($this, "the_excerpt"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_WIDGET_TITLE))) {
                add_filter('widget_title', array($this, "widget_title"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_WIDGET_TEXT))) {
                add_filter('widget_text', array($this, "widget_text"), 10);
            }
            if (MCI_Footnotes_Convert::toBool(MCI_Footnotes_Settings::instance()->get(MCI_Footnotes_Settings::C_BOOL_EXPERT_LOOKUP_THE_POST))) {
                add_filter('the_post', array($this, "the_post"), 10);
            }
            // reset stored footnotes when displaying the header
            self::$a_arr_Footnotes = array();
            self::$a_bool_AllowLoveMe = true;
        }
    

    If that does work well for you, and that is the main difference between our v2.0.4 and v2.0.5, I don’t understand why the container moved up in this page with v2.0.5 but not with modified v2.0.4. I’m thoroughly puzzled and cannot understand at all. I’ve re-checked line diffs between v2.0.4 and v2.0.5, and also between v2.0.3 and v2.0.4, and am unable to locate the reported display issue if it is not about priorities amongst plugins lining up to run for page generation.

    However there is another issue, with the reference container layout. I see on screenshot 2 running footnotes 2.0.5 that the ID column is too wide. That will be fixed in oncoming v2.0.6.

    What I’ve also found in Atahualpa v3.7.24 is a vertical align issue with the footnote referrers, that @mmallett pointed out in https://wordpress.org/support/topic/mouse-over-broken/#post-13593037 and that will be fixed in next v2.0.6 by deleting the rules quoted in https://wordpress.org/support/topic/mouse-over-broken/#post-13593519

    Thank you very much for contributing.

    Would you like to test upcoming v2.0.6 and share again how it will work out on your website? We much appreciate your feedback, it already has helped a lot to improve footnotes.

    Best regards,
    @pewgeuges

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

    (@spaceling)

    I will absolutely test 2.0.6.

    I should have mentioned that I also make the following changes to the templates. (So possibly I’ve screwed something up?)

    reference-container-body.html

    <tr>
    	<td class="footnote_plugin_index" width="50" style="vertical-align:top !important;"><span class="footnote_plugin_link" onclick="footnote_moveToAnchor('footnote_plugin_tooltip_id');"><span id="footnote_plugin_reference_id">index.</span>arrow</span></td>
    	<td class="footnote_plugin_text" style="vertical-align:top !important;">text</td>
    </tr>

    footnote.html

    <sup id="footnote_plugin_tooltip_id" class="footnote_plugin_tooltip_text" onclick="footnote_moveToAnchor('footnote_plugin_reference_id');">beforeindexafter</sup>
    <span class="footnote_tooltip" id="footnote_plugin_tooltip_text_id">text</span>

    Thank you for these updates!

    Plugin Contributor pewgeuges

    (@pewgeuges)

    @mmallett,

    You are welcome!

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

    (@pewgeuges)

    @spaceling,

    Thank you for testing and for sharing this code!

    No, by these changes the page layout cannot be affected the way it is. But a close look brings a need to comment on them.

    The first template, reference-container-body.html, confirms what I noticed when checking the prayer: While the plugin’s public style sheet gives the mouse cursor the pointer shape all over the table cells in the reference container where the numbers are in, in this code the backlink functionality has been restricted to the numbers. That is probably unintended and came in from the legacy, pre-v2.0.0 template, that indeed restricted it to the very backlink symbol.

    My mea culpa is that I forgot to take the class footnote_plugin_link over and to add it to footnote_plugin_index.

    Thanks to your feedback that will be in v2.0.6, though late. Sadly I broke user-defined CSS rules! I apologize to all users of footnotes.

    The backlink functionality is now intended to span over the whole table cell so that visitors can click everywhere to the left of the note to get back where they left off.

    The arrow: I see that you switched [‌[arrow]‌] to the other side of the number. We should indeed add support for reordering symbol and number when the table flows from right to left. In the old style table with an extra column for the symbol, that was automatic.

    Also you blanked the arrow out, which is the currently recommended way to disable it, so what I need to note here is only for completeness’ sake:

    In print, the backlink symbol should be hidden. For that purpose a new class, footnote_plugin_index_arrow, has been assigned to a span bracketing the [‌[arrow]‌] when symbols were brought back and prepended since v2.0.3. This span is the only one that is really needed. The span containing the ID is useless as the ID goes well with the table cell, whereas the span calling the backscrolling function is bad for user experience as noted.

    By the way, when printing the page via the button: You’ll notice that the footnotes’ tooltip contents shows up in the prayers’ text because the external tool is missing out on media queries. Since v2.0.0,footnotes public style sheet has a rule for hiding the tooltip text when printing. While the tooltip is hidden on screen until mouse-over, it is printed out unless otherwise specified. This bug is now fixed the most interoperably on footnotes side, but we can’t do anything about third parties to conform to the standards of the Web.

    Taking it all together, with the symbol switching side I’d strongly recommend using this code instead, for reference-container-body.html. The <‌a> element is added for styling so it can get the hyperlink color for semantics on screen, while in print it inherits text color as likewise specified. Regarding the style rule vertical-align: top, it was already included but not priority. Thanks to your feedback it will be vertical-align: top !important from v2.0.6 on. That’s why it’s safely removed here (code prettified for maintainability, altered to prevent the forum engine from interpreting it, will be delivered in upcoming v2.0.6):

    
    <tr>
        <td 
            class="footnote_plugin_index footnote_plugin_link"
            width="50"
            id="footnote_plugin_reference_[‌[id]‌]"
            onclick="footnote_moveToAnchor('footnote_plugin_tooltip_[‌[id]‌]');"
        ><‌a 
        >[‌[index]‌].<span
            class="footnote_plugin_index_arrow"
        >[‌[arrow]‌]</span
        ></a
        ></td>
        <td
            class="footnote_plugin_text" 
        >[‌[text]‌]</td>
    </tr>
    

    The second template, footnote.html, appears to me as a good fit on Open Siddur, because by removing the <‌a> element, you removed (from the footnote referrers) the theme-specific default link color, used also in the footnote texts in the Notes section. Alternatively its color can be set to ‘inherit’, but at plugin level that raised criticism because the theme-specific link color is preferred also for footnote referrers, I learned. Adding this and other settings is in project.

    It’s the opposite than in the other template: In the Notes section it is more intuitive to color the backlinks as links, it helps click on them. When removing the arrows from the list (temporarily, turned out), we first made sure that these numbers were colored as links.

    Still, all that doesn’t solve the footnote container’s positioning. If we could only reproduce the bug, we were already in a better position to try and find out what it takes to fix it—

    Best regards,

    @pewgeuges

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

    (@spaceling)

    oof, your response (including your revised code) appears to have been mangled!

    Plugin Contributor pewgeuges

    (@pewgeuges)

    Many thanks for letting me know before it’s too late to edit, and sorry. It took me until now to get it right. All instances of “[‌[” and “&‌‌lt;a&‌gt;” need to be altered by enclosed ZWNJ or some other invisible to prevent them from being interpreted, as HTML entities are converted to literals and then handled as HTML A tag. We can type “<‌a>” as well with “<”[ZWNJ]“a>”.

    In code blocks too, “[‌[” must be “[”[ZWNJ]“[” (did the same for closing double brackets), because these are handled as shortcodes and converted to wikilinks to the Codex. Escaping: \[[

    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
    • This reply was modified 10 months, 2 weeks ago by pewgeuges.
Viewing 15 replies - 1 through 15 (of 29 total)
  • The topic ‘Change the position’ is closed to new replies.