Externalize navigation?

[yellowled]

Working on something to try out the "new" child themes, a thought crossed my mind: Isn't it about time we put the feature to create a navigation (like in BP and other templates) into a plugin or maybe even the core?

Here's why this crossed my mind: What happens if I implement the navigation (the way we use it now) in an engine template, but not in a child template depending on that engine? I assume there would be some kind of "side effect". On the other hand, it would be a limitation denying engine templates the ability to have a navigation (the way we use it now) given the fact that any engine template might as well be used as a theme itself.

It would be great if template authors would be able to use some kind of statement like "if navigation plugin is active, insert navigation here" in .tpl files. That way, the navigation wouldn't even have to be a sidebar plugin -- template authors could just plug it into the index.tpl or sidebar.tpl. BTW, this functionality would also be great to have for the search form. Both navigation and search form are very common in blogs these days, but it's debatable whether either one of them should be limited to being emitted in a sidebar. (Of course, that's already possible for the search form, but it involves a lot of typing. )

While I'm at it, here's another cool idea (in my humble opinion at least): Of course, users should still be able to configure the number of links in a navigation and the link text. How about if they could also select for any given item which "type of link" it should be. Types of links I could think of so far would include:

1. home page
2. a blog category (selected from a select box listing all categories)
3. a static page (selected from a select box listing all pages)
4. the archives page
5. any page created by plugins (contact form, download manager etc.)
6. custom link (i.e. link to external URLs)

Unfortunately, I can only present the idea and help with the HTML/CSS for this, and I realize that it would probably be a lot of work to implement this, especially the "type of link" thing. Also, backwards compatibility remains an issue because of all the templates which already have a navigation implemented the way we use it now. But I think this would really rock.

YL

[garvinhicking]

Hi!

Hm, I'm more turned off by the idea of needing a plugin for this, so I'd opt for putting it inside the core.

It wouldn't be too hard to rip out the navigation code from bulletproof currently and implant it inside the basic template configuration page.

As for "type of link", I like the idea, but I don't really know how to implement it inside the interface. Are you thinking of an additional dropdown?

I just committed a patch to the s9y core and patched the config.inc.php of bulletproof to display this possible behavior. Inside config.inc.php I remove the current navlink code, and added this:

Code: Select all

$template_global_config = array('navigation' => true);
$template_loaded_config = serendipity_loadThemeOptions($template_config, $serendipity['smarty_vars']['template_option']);
serendipity_loadGlobalThemeOptions($template_config, $template_loaded_config, $template_global_config);

This simply sets an array that tells the "Manage Styles" page, that this template supports the global navigation. As a benefit, the name of the config keys stay the same, so we [hopefulle] don't need people to reconfigure their options as a result of our implementation.

Now the s9y core uses the serendipity_loadGlobalThemeOptions function to emit the navlink config items that previously came from the templates.

Inside the database, these global config items are not stored with a okey of "t_bulletproof" but instead "t_global". So those keys can be fetched for any future template that uses $template_global_config and the same variables.

Regards,
Garvin

[yellowled]

Hm, I'm more turned off by the idea of needing a plugin for this, so I'd opt for putting it inside the core.

Same here, especially because I think it is a core functionality.

As for "type of link", I like the idea, but I don't really know how to implement it inside the interface. Are you thinking of an additional dropdown?

Yes. We'd probably have to add some javascript/jQuery stuff to conditionally display a second select box or fill a second select box with the appropriate values. I know we can "gather" available categories since I have used it in various templates, so we're probably able to do the same thing for static pages etc. Then again, custom link would require a text input, so it's probably a good idea to add a seperate input element for each possible option and hide them using Javascript.

I'd also advocate in general to add a framework like jQuery to the admin backend -- it will make spicing up the admin area much easier, and some of our developers are already familiar/working with it.

I just committed a patch to the s9y core and patched the config.inc.php of bulletproof to display this possible behavior.

I'll have to check this out, but I can't say when I'll get to it. I'll report back here.

YL

[yellowled]

I just committed a patch to the s9y core and patched the config.inc.php of bulletproof to display this possible behavior.

I'll have to check this out, but I can't say when I'll get to it. I'll report back here.

Just gave it a quick test run -- I literally didn't notice any difference at all in the template options using the modified BP, but I guess that's the way it's supposed to work, right? If so, it works fine and even keeps the old navigation settings.

YL

[yellowled]

Hmmm. I just now created a basic config.inc.php for my "working template" which I'm using to test this stuff:

Code: Select all

<?php

if (IN_serendipity !== true) {

  die ("Don't hack!");

}



$probelang = dirname(__FILE__) . '/' . $serendipity['charset'] . 'lang_' . $serendipity['lang'] . '.inc.php';



if (file_exists($probelang)) {

    include $probelang;

}



include dirname(__FILE__) . '/lang_en.inc.php';



$serendipity['smarty']->assign(array('currpage'=> "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']));

$serendipity['smarty']->assign(array('currpage2'=> $_SERVER['REQUEST_URI']));



function serendipity_plugin_api_event_hook($event, &$bag, &$eventData, $addData = null) {

    global $serendipity;

    switch($event) {

        case 'frontend_footer':

            echo '<!--PLUGIN API-->';

    }

    return true;

}



$template_config = array();



$template_global_config = array('navigation' => true);

$template_loaded_config = serendipity_loadThemeOptions($template_config, $serendipity['smarty_vars']['template_option']);

serendipity_loadGlobalThemeOptions($template_config, $template_loaded_config, $template_global_config);

Unfortunately, even after a reload of "Manage styles", s9y tells me the template doesn't have any options ..? lang files are present.

YL

[garvinhicking]

Hi!

Yeah, you need at least one item on your $template_config array...

Regards,
Garvin

[yellowled]

Yeah, you need at least one item on your $template_config array...

Okay, that works, even with just a stupid dummy item:

Code: Select all

$template_config = array(
    array(
        'var'           => 'dummy',
        'name'          => 'dummy',
        'type'          => 'custom',
        'custom'        => '',
    ),
);

I'm testing this along with a working template for the engine template stuff, and if there's a config.inc.php present in the parent template, but not the child template, the options are not used in the child theme, so any child theme would require a seperate config.inc.php to make use of the theme options -- but I guess that's the way it's supposed to work, right?

Also, it would be kind of sexy if we had some simple variable to use in .tpl files to emit the navigation. Right now, I'd have to use something like this:

Code: Select all

<ul>
{foreach from=$navlinks item="navlink" name=navbar}
    <li>{if $currpage==$navlink.href or $currpage2==$navlink.href}<strong>{else}<a href="{$navlink.href}">{/if}{$navlink.title}{if $currpage==$navlink.href or $currpage2==$navlink.href}</strong>{else}</a>{/if}</li>
{/foreach}
</ul>

in my index.tpl. It would be awesome if one could instead just write:

Code: Select all

{$template_option.navigation}

or something. Then again, that would seriously limit the flexibility of this.

For instance, one might want to add titles to the links in this navigation bar. (Personally, I think it's stupid, but some people do this for SEO reasons. ) We should maybe add that option to the core -- unfortunately, we'd have to rename $navlink.title to $navlink.text to use $navlink.title for the actual title attribute (which on the upside could be different from the link text, which currently is not possible). And that would probably screw up the option to keep existing navigations. So we're gonna have to keep $navlink.title as it is and call the new variable $navlink.something. Not ideal, but never mind.

(Jeez, this is more complicated than I thought, and we haven't even gotten to the complicated part yet ... )

Anyway, my "sexy" way of doing this probably doesn't make sense, right?

YL

[Don Chambers]

Does this new "core" navigation support subnavigation?

[yellowled]

Does this new "core" navigation support subnavigation?

I assume by "subnavigation" you mean nested unordered lists which could be turned into dropdown menus using some kind of suckerfish mutation? Garvin, please correct me if I'm wrong, but: No.

(Personally, I don't think that's a bad thing.)

YL

[Don Chambers]

I assume by "subnavigation" you mean nested unordered lists which could be turned into dropdown menus using some kind of suckerfish mutation? Garvin, please correct me if I'm wrong, but: No.

(Personally, I don't think that's a bad thing.)

YL

Yes, by subnavigation I meant depth, as in suckerfish. I hate to say it, but I am not that thrilled with putting navigation into the core. I just do not think it is a big deal to add navigation if someone changes their template. If subnavigation is desired, the core navigation cannot be used.

I think I just need to play with it for a bit before jumping to conclusions!

[yellowled]

I hate to say it, but I am not that thrilled with putting navigation into the core. I just do not think it is a big deal to add navigation if someone changes their template. If subnavigation is desired, the core navigation cannot be used.

I am not a fan of dropdown menus in web sites. Usability experts usually recommend to avoid dropdown menus if possible, and I agree. Most of the solutions out there need JS support, are not very accessible, lack keyboard support etc. Also, an average blog should not need multi-level navigation -- and a site which needs it should probably use a "real" CMS anyway.

YL

[yellowled]

Yay, weird behaviour!

I'm using the exact same code for this navigation in another template as the one use in BP's config.inc.php. However, I can not change the link text (title) for some of the links in that template's theme options, meaning the third and fourth link added (later). I can, however, change the first and second link. I can also change all the links in BP, but when I switch back to the other template, the theme options reload the default values for these link texts ('Link #2' and 'Link #3'). This affects only the link text, not the URLs.

Weird. Hope this makes any sense at all.

YL

[garvinhicking]

Hi!

Check the serendipity_config DB table and see what your variable names/values look like, and if changing them in the DB works?

Regards,
Garvin

[yellowled]

Check the serendipity_config DB table and see what your variable names/values look like, and if changing them in the DB works?

Erm. You meant the serendipity_options table, right? Because that's where the values are stored. (This is still the latest S9y svn snapshot, BTW.)

Okay, so the values in question exist 2 times in that table -- with "okey: t_global", they have the correct value, with "okay: t_TEMPLATE" they don't. Also, there are no values with "okey: t_bulletproof", although BP uses these, so BP probably fetches them from the "okey: t_global" ones.

I'm not sure which ones to change manually now?

YL

[garvinhicking]

Hi!

Hm, I don't properly remember why they get stored twice. Usually the config keys should only be there as t_TEMPLATE...maybe the global navigation saves it because those should be available for every template, and something gets mixed up.

Seems as if it needs more work.

Regards,
Garvin