Make AdminThemeUikit renderPrimaryNavItem and other render methods hookable

[jlahijani]

It would be nice if the render methods in AdminThemeUikit.module were hookable.

[ryancramerdesign]

@jlahijani This would likely break any classes that extend AdminThemeUikit and happen to implement those methods. So if you can describe more specifically what you are wanting to change in the nav, maybe I could find another way to make it hookable.

[jlahijani]

My use case is to be able to manage classes on the <li> of the menu items. So for example instead of just having page-3- as a class for the Pages admin menu item, I may want to add foo to it.

[BernhardBaumrock]

@ryancramerdesign the backend and especially the nav are very limited when it comes to backend development in general. For example in RockSettings I only wanted to add an icon besides the right navbar that shows the username and search:

  public function ready(): void
  {
    $this->addSettingsIcon();
  }

  private function addSettingsIcon(): void
  {
    if ($this->wire->page->template != 'admin') return;
    if ($this->wire->config->ajax) return;
    if ($this->wire->external) return;
    $settingsPage = $this->wire->pages->get("/rocksettings");
    if (!$settingsPage->id) return;
    if (!$settingsPage->editable()) return;
    $this->addHookAfter("Page::render", function (HookEvent $event) use ($settingsPage) {
      $html = $event->return;
      $icon = "<a
          href='{$settingsPage->editUrl()}'
          class='uk-link-reset'
          title='Settings' uk-tooltip='pos:bottom'
        >
        <i class='fa fa-cogs'></i>
        </a>";
      $html = str_replace(
        '<div class="uk-navbar-right">',
        '<div class="uk-navbar-right">' . $icon,
        $html
      );
      $event->return = $html;
    });
  }

This is obviously very hacky.

Another problem with the menu is that everything is cached quite aggressively. So doing things like showing items based on the users role etc. get quite complicated.

I know we have the renderNavJson, but that is very complicated to use (if you are used to simple PW API magic :) ) and it only works in the dropdowns...

I'd also love to see PW provide better/easier ways to really customize the backend just like everything else is so easy customizable and extendable :)

PS: Not sure how much benefit that aggressive caching really brings compared to no cache or partial caching? If you have any insight's I'm very happy to learn :)

[jlahijani]

@BernhardBaumrock you said "PS: Not sure how much benefit that aggressive caching really brings compared to no cache or partial caching? If you have any insight's I'm very happy to learn :)" - I agree here. In my module I am disabling admin cache. I believe there was a comment on the forum a while ago where its usefulness was questioned and demonstrated with or without it, the admin is still just as fast.

I agree with the sentiment that the admin should be more convenient to customize. Like Bernard, I've had to resort to using hooks to modify rendered output which is not ideal.

[adrianbj]

I would also vote for no / reduced menu caching - I would like to be able to add dynamic data to custom menus and never been able to because of the caching. @jlahijani - how do you disable the admin cache?

[jlahijani]

@adrianbj I should have said I have a convenient way of easily clearing it, which involves running this bit of code: wire('session')->removeFor('AdminThemeUikit', 'prnav');

However if I were to add that to the init method of my module (which I may do), that effectively disables it although a bit hacky.

[BernhardBaumrock]

@adrianbj see https://github.com/Toutouwai/CustomAdminMenus/blob/04568b274e287ba2d372208c9a93f3f788b2849a/CustomAdminMenus.module#L35

@ryancramerdesign you see that's an issue for everybody modifying the PW backend :)