Links

@sijad, @MatiasSaitam, @manifest does this extension work with 0.1.0-beta.5 ?

I'm using your convenient Links extension in relation to your static Pages extension. Combined they allow for significant enhancement of Flarum's header overall. My objective at the moment is to have this left-to-right order:

• Main page (this is actually Flarum's h1.Header-link block, but it will be styled to look like the first item in the menu list)
• Guidelines
• User groups
• Help

So the last three links are created with your extension (and point to three pages created with your Pages extension). You can see the idea in the image shared here.

Ordering

However, I'm having trouble getting the three links in the left-to-right order I want. I didn't foresee the fact there's no way to re-order the links after they're created — and I've tried deleting all the pages then recreating them again thinking maybe the page IDs had something to do with it, but nothing is working.

I would propose you provide some means for easily putting links in the l-to-r order people want after the link/page combos are created. That's definitely going to be needed.

Styling

Also, I'm having a very hard time getting the links styled to match the h1 link, which seems to be because the links are using the .Buttons classes. I don't know if that's Flarum forcing you to use those selectors, or the design of your extension, but it's a little annoying. I highly recommend you don't use those selectors so we can style those links as an actual menu. They're not supposed to be buttons, so no button rules should need to be overridden. When I try to override the links as needed, it screws up the other actual buttons (e.g. at right of search box and the back-button in top-left). There shouldn't be a need to fight that so much. It's overly complicated as is.

Combined Pages/Links extension

Finally, and I'm probably dreaming, but it would be great if you combined your Links and Pages extension into a single extension and it functioned like this. I'm modeling it here mostly after your Pages extension, which is a little out of context in this thread, sorry:

1. The default form provides fields for (mostly the same as you have now in your Pages extension):
   • Title (used as link label)
   • Slug (used as url-only title)
   • Content (of course)
   • Output location (radio buttons or a select menu for indicating where page link will appear)
   • List order (1, 2, 3... etc; the order in which the link should appear in the output location)
   • Existing pages (a table list that adds *Output location** to your existing Edit, View, Delete items)
2. Example Output location options:
   • Draft (not yet assigned; won't output anywhere)
   • Primary menu (i.e. .Header-primary ul.Header-controls)
   • Side menu (the core functional menu: All discussions, Following, Tags, etc.)
   • Footer menu (i.e. Footer ul.Footer-list1 — a hypothetical location in the future)
   • etc
3. When selecting an Output location (e.g., Primary menu), a link is added to that location automatically (no need to separately use the Links extension).

The advantages of this should be clear: automatic links, order control, etc.

You could then change the function of your Links extension to be External Links only and remove the need for indicating whether the link is Flarum or external.

sijad I prefer manage all Links in one place and a separated location (in Pages in your case) just complicate things IMO

If links are created automatically when creating/targeting static pages, as the model above defines, you're not managing those links separately, it's just happening automagically by fact of creating pages. It's not a separate "management" thing.

A Links extension would still be useful, for external links. Maybe you add the ability to create different external link lists, by category, for example.

I might be wrong, but maybe you're looking at it from the standpoint that the .Header-primary list would always have a combination of internal and external links. Speaking with my information architect hat on, that wouldn't be ideal. Those links would always be internal links, because that's what users would expect, to move within the site (thus nicely handled by the Pages model).

External looks would either be a global navigation bar (what I'm also hoping to add, per my aforementioned image) or Footer links, for example. Everything else in the div.container and main would be internal links. In short, I don't see why it would be confusing, in fact more logical, and less work on the admin side for the person managing pages.

there is some some plan to add links to home sidebar

Ah, I added "Side menu" to my earlier Output location list of options for completeness. ?
But, again, that would always be internal links, to not confuse the boards user, so a perfect fit for the Pages model described.

I like your Idea for ability to adding Links to footer

If you do that, or before you do that... Please do one for the global nav first. Looks like it would need a new element though to float right of the existing back-button thing:

<div class="Header-navigation">
 <div class="Navigation"> back button thing is currently in here </div>
<!-- new nav element needed for external global links -->
 <nav class="global-nav">
  <ul> </ul>
 </nav>
</div>

All external links, of course. ? Although one link in the global nav (in our case) would be a "non-linked" item for the discussion boards indicating active global view (again see image for concept). Not sure how that would be managed.

csf STYLING ... I'm having a very hard time getting the links styled to match the h1 link

I got this part worked out. It was just a matter of finding the right influencers and doing the math dance where needed.

@Kakifrucht, .LinksButton is good, yes, but I was having padding and other problems to counter too in order to get the .Header-title and .Header-primary elements to align correctly. Finally got it though.