search

pkp / pkp-lib

The library used by PKP's applications OJS, OMP and OPS, open source software for scholarly publishing.
https://pkp.sfu.ca
GNU General Public License v3.0
304 stars 444 forks source link

New hook in footer or move the existing one? #3149

Closed lilients closed 2 years ago

lilients commented 6 years ago

Hi PKP (@NateWr I guess),

I adapted the shariff plugin for OJS 3 and OMP 3. The plugin adds buttons to the sidebar or to the footer. I am using this hook for the footer: Templates::Common::Footer::PageFooter. But because the hook is outside of the <div class="pkp_structure_footer"> the buttons are displayed below the page. As you can see here in the default and the manuscript theme:

shariff_footer_bottom shariff_footer_manuscript_bottom

It would be much prettier, if the buttons were displayed in the footer itself instead of below it. Like this:

shariff_footer_top shariff_footer_manuscript_top

I think the cleanest solution to this is to move the hook or create a new one.

Would you be ok with adding a new hook (e.g. Templates::Common::Footer::Content) to the inside of <div class="pkp_structure_footer"> or moving the existing one (Templates::Common::Footer::PageFooter) there? Maybe here: https://github.com/pkp/pkp-lib/blob/master/templates/frontend/components/footer.tpl#L31 🤔 If yes, I am happy to make a pull request. 🌞

NateWr commented 6 years ago

Hi @lilients! The Templates::Common::Footer::PageFooter is deliberately placed as the last thing on the page, just before the </body> tag. It was originally intended for plugins to load their JavaScript assets at the very bottom of the page.

This was before we added the {load_scripts} helper, and the ability to register JS assets for the frontend.

I'm tempted to keep the hook where it is in place for backwards compatibility. We could add an additional hook in the footer panel. However, I'd be more inclined to avoid adding new hooks. As with this one, each hook we add we need to keep around for backwards compatibility.

Instead, we've long talked about opening up our sidebar/block system. Ideally, a theme could register a block area, and any blocks could be added to that. The footer would be a great place for this, as people often want more non-technical tools for adjusting the footer.

I'd like to see this problem addressed in this way, rather than adding a hook, because it provides some more consistent standards for how content will be added into the footer. That will make it easier to style consistently as we build out more themes.

I know it's not a small project to refactor the block system. But would you have any energy to look into that?

lilients commented 6 years ago

@NateWr thanks for your reply. I see the problem with the hooks. I agree that a tool similar to the sidebar management - especially with the custom blocks plugin - would be very nice and useful. Unfortunatly I do have specified tasks in my project and currently no spare time for new ones. :(

NateWr commented 6 years ago

I understand. I presume you're already running a fork of OJS/OMP for the versioning? If so, you can just add a new hook in your fork and the plugin just won't support sharing in the footer except on your fork.

Another temporary solution would be to hook into ContextDAO::_fromRow and prepend the footer content with that block straight out of the database. It's ugly but would do the trick until we can get a block-based footer going. (ContextDAO::_fromRow is missing a hook, but it should be added anyway.)

NateWr commented 2 years ago

Closing as outdated.