Improvement: Configurable "Documentation for this page" link in footer, resolves #649.

[lucaboesch]

On behalf of the Boost Union Team: 🎉 Thank you for contributing! 🎉

Please note: There must be a GitHub issue for every pull request (PR)

We kindly ask you to create a github issue now if you haven't already done so.

Please make sure to follow these steps to ease the review process for the peer review team:

[ ] link your issue in the PR title, using the keyword 'resolves #ISSUE-NUMBER', e.g. 'Feature: Provide the ultimate user experience, resolves #42'
[ ] provide any further information that is relevant for peer review and not yet mentioned in the linked issue as a comment in the PR
[ ] make sure that the 'Allow edits by maintainers' checkbox is checked when creating the PR. Otherwise, the peer reviewer would not be able to push any review changes to the PR and the communication overhead increases
[ ] submit your PR in draft status to run the automated checks and review the results
[ ] in case any checks fail solve the mentioned errors by pushing the corrected code to your PR-branch
[ ] if all checks pass (or if you are unable to resolve the failing steps without any help of the review team), mark the PR as 'ready for review'

Thank you again for your contribution, we will start reviewing your PR as soon as we are able to.

In the meantime, please check our wiki page for creating pull requests and our wiki page for reviewing pull requests for further infomation about our contribution and review process.

[abias]

Hi @lucaboesch ,

many thanks for proposing this improvement!

I had a brief look at your PR and have some general change requests as a start:

• Please hide the new footerhelp setting with hide_if() if the existing footersuppresshelp is set to Yes as the new setting would not make sense in this case.
• Add a version bump in version.php
• Document the new setting in README.md
• Add an entry to CHANGES.md

Having said that, I think we have to split the PR and its new setting into two goals:

1. Do not show an icon before the link:
   From my point of view, this request is valid and might deserve a setting. On the other hand - as you show already in your screenshot and explain in your comment in Improvement: Make the footer "Documentation for this page" link more configurable #649, limiting this setting just on the documentation link feels incomplete as the other links in the footer would still have icons.
   What do you think of rebuilding the patch with a general setting "Show / hide icons before links in the footer"? This way, you could easily cover all (auto-generated) links in the footer, including the documentation link, the support link and the contact link plus the links for Boost Union's static pages which get icons currently as well.

2. Opening the link in a new window or not.
   I have to admit that I do not get the difference between your new setting and the existing $CFG->doctonewwindow setting yet. Both set a _blank target if enabled. Can you please explain the difference and your intention? Maybe I am simply missing something.

Many thanks in advance!

Cheers,
Alex

[lucaboesch]

Thanks for your review, @abias.
I'm puzzeled. Now, I can't reproduce the "New window" thing.
In fact, until last week (I was able to prove this), with doctonewwindow set, the documentation page opened like this and not in a tab.

[lucaboesch]

With this commit, @abias, I address the points you raised.

• Setting target (link in a new window or not) is not a feature any more.
• The setting disables and enables icons entirely for all footer items.

Note that I did not opt for the wording "Show / hide icons before links in the footer" but sticked to "Suppress icons in front of the footer links" with the following reasoning.
"Show / hide" isn't featured anywhere else yet. It is always "Suppress".
"Suppress" is more user friendly. An admin, when she or he goes through the settings and sees "Show / hide" it seems like a call for action to decide ("Hhmh, what am I supposed to choose here? What is better, show or hide?") and might be not so intuitive. With "suppress" the logic is clear: when leaving on default, everything is unchanged from core Boost.
(BTW, for consistency, 'Hide nodes in primary navigation' could also be renamed to 'Suppress nodes in primary navigation'. Do you want me to open an issue?)

Thanks for your great proposal!

New code has arrived

[abias]

Hey @lucaboesch ,

thanks for pushing this further!

I'm puzzeled. Now, I can't reproduce the "New window" thing.

After your recent live demo, I'm puzzled as well. But it's good that you removed this aspect from the patch for now.

Note that I did not opt for the wording "Show / hide icons before links in the footer" but sticked to "Suppress icons in front of the footer links" with the following reasoning.
"Show / hide" isn't featured anywhere else yet. It is always "Suppress".
"Suppress" is more user friendly. An admin, when she or he goes through the settings and sees "Show / hide" it seems like a call for action to decide ("Hhmh, what am I supposed to choose here? What is better, show or hide?") and might be not so intuitive. With "suppress" the logic is clear: when leaving on default, everything is unchanged from core Boost.

That's perfectly fine for me!

(BTW, for consistency, 'Hide nodes in primary navigation' could also be renamed to 'Suppress nodes in primary navigation'. Do you want me to open an issue?)

Sure! Please do ahead!

Review

Following https://github.com/moodle-an-hochschulen/moodle-plugin-maintaining/wiki/Check-list-for-peer-reviewing-patches-and-pull-requests

Documentation

• [Y] Commit Message understandable and issue referenced (via resolves keyword)
• [Y] Patch author correct
• [Y] CHANGES.md appended
• [Y] README.md appended
• [-] Credits appended
• [Y] Appropriate Comment quantity
• [Y] Successful Moodle PHPDoc check

version.php

• [N] Checked if $plugin->version increment necessary (and increment done if necessary)
• [Y] $plugin->release untouched

lib.php

• [Y] Only necessary functions

Languages

• [Y] Only english strings
• [-] Necessary magic strings added (e.g. capabilities)

Automated tests

• [Y] New functionality covered
• [Y] No failing steps or scenarios

Mustache templates

• [Y] Examle context exists

CSS and styles.css

• [-] Bootstrap styles used if possible

Duplicated code

• [-] Duplicated code is marked properly

Github action

• [Y] All green

Commit history and scope

• [Y] Already single commit
• [Y] Focus on single purpose
• [Y] No surplus files

Additional aspects for Boost Union

• [-] No usage of $theme->settings
• [-] Usage of isset() checks when processing plugin settings in renderer / output code
• [Y] Usage of admin_setting_configselect instead of admin_setting_configcheckbox
• [N] Modified mustache templates properly marked and .upstream template in place

Review result

Your changes look generally fine to me!
I just rebased your branch onto latest master and added some small refinements to improve the logic and to better align the code with the existing codebase.
I will merge the PR as soon as the tests are green again.