Control for including Plug-in Pages in Menu

Developers
1

What’s the best way to provide a control on whether to include the page added by Plug-in to the menu or not? For normal pages, there’s a checkbox to enable/disable this. Such an option for all available pages would be a good option to have.

I haven’t been able to build a workaround either. Any thoughts on how to simplify this configuration?

2

When it comes to workarounds, you could add a boolean field to the plug-in, and when it is unchecked, apply the following CSS:

nav a[href='/stats/'] {
  display: none;
}

The link will still be there, but it will not be shown (or read to people using screen readers).

Another approach is to not include the page in menus and have the user of your plug-in add it manually.

2 Likes
3

I wasn’t aware we could get the site params in CSS too. I thought it would only work with SCSS. Any reference you have come across?

I don’t want to go with the manual option as it needs more steps than what I want users to carry out.

4

I don’t know about site params in CSS files, but you can take advantage of the fact that we are allowed to add Hugo partials to <head>. Something like this:

{{ if not $.Site.Params.show_stats_in_menu }}
  <style>
    nav a[href='/stats/'] {
      display: none;
    }
  </style>
{{ end }}

I would like to +1 your request to have built-in support for this. Would it be possible to list plug-in supplied pages along user created pages, @manton, and allow people to decide if they should show in the menu?

5

Thank you for that workaround. But again, that’s theme-specific, and I really do not want users to mess with their themes to decide whether to include a page in the menu. @manton It would be perfect if plug-in pages also had a custom option on whether to be included in the menu.

6

No, people should not have to mess with themes for this workaround. Just check (or uncheck) a checkbox. :blush:

Plug-ins can add partial includes to <head> via plugin.json:

{
  "version": "1.0",
  "title": "My plug-in",
  "description": "1-2 sentences about what this plug-in offers.",
  "includes": [
    "amits-awesome-menu-hack.html"
  ]
}

All the first-party themes support this. Sure, third-party theme developers can omit support as of now. But I think that might change in the future. That is to say, to be allowed in the official plug-in directory, themes must implement support for Micro.blog features like partial includes. (Correct me if I’m wrong here, @manton.)

So, I would say this is an excellent workaround. It will work for everyone using first-party themes and, I would guess, most people using third-party themes.

7

I had implemented this but as you may be aware, it is just hiding the display so you can clearly see a gap between menu items. So functionally good but aesthetically, not so much.

I agree that any plugin that adds a page should have a box to check/uncheck to enable seeing it or not in the menu. For e.g., the author may want to use Stats but not share it with their readers.

8

To be honest, I’m not super clear how micro.blog builds the nav list. The theme I’m working in right now is just grabbing data from config.json but I’d love a better understanding of where those links are stored and how to add custom pages to that places versus what I do now, which is hand code routes.

9

I guess that could happen, but it should be rare. display: none; turns off the display of an element:

Turns off the display of an element so that it has no effect on layout (the document is rendered as though the element did not exist).

– display - CSS: Cascading Style Sheets | MDN

On which site did you see that gap?

10

I’m going to update the documentation somewhere to better describe the features that themes should support so that plug-ins work. I’ve wondered if Micro.blog should automatically insert the required HTML in templates, but it’s probably better if themes have control over it, just in case they need to do something a little different. (Still on the fence about this a little.)

11

I’ve been thinking about making partials of any code that’s micro.blog specific. I think docs on plug-in support would go a long way to helping folks know what plug-ins are really meant to do. I also think a guide on what MB expects or will do would help a lot with theme conversions.

12

That’s a good idea. I’m thinking we should move some of the Micro.blog-specific HTML into shared partials like microblog_head.html and microblog_footer.html. That would be a little more self-documenting too for existing themes.

13

In a custom theme, you can template anything you would stick under static/assets by sticking it under assets instead and using resources.ExecuteAsTemplate. Doing this for CSS files would be identical to the way I do this for Javascript files. Doing this for Sass files is only different in that you need the additional toCSS call to compile the Sass.

Side note: you can even generate a resource from a string and then execute as a template, though I’ve yet to find the need.