Sidebar items always point to the page tab

[ale]

I'm trying to define plugin wide settings and I'd like to add the setting to the... Settings tab.

Fine: there is the settings-sidebar add-action.

But: the entry in the settings sidebar, then, points to the pages tab.

By reading the the I18N Special Pages's code I've found a workaround:

PHP Code:

// hack to get the link from the settings sidebar to go to the settings tab
$lists_admin_tab = 'pages';
if (basename($_SERVER['PHP_SELF']) == 'load.php' && @$_GET['id'] == $lists_plugin_id) {
  if (array_key_exists('lists_settings', $_REQUEST)) {
      $lists_admin_tab = 'settings';
  }
}

# register plugin
register_plugin(
  ...
  $lists_admin_tab, //page type - on which admin tab to display
  ...
); 


But, hey, shouldn't automatically an entry in one of the sidebars point to the tab where it shows up?
I don't see a user case where it should not be that way...

I can try to write and propose a patch, if there is an agreement about this being a useful feature.

Ciao
a.l.e

[mvlcek]

But, hey, shouldn't automatically an entry in one of the sidebars point to the tab where it shows up?
I don't see a user case where it should not be that way...

I can try to write and propose a patch, if there is an agreement about this being a useful feature.

But how else should GetSimple determine which tab to display?
You register a sidemenu item on the settings tab - or more precisely: you register a function to call (which incidentally draws the menu item using it's parameters) on the settings tab. The link is only known as parameter to the function call.
How can GetSimple determine that the current URL should display the settings tab?
And if list_settings saves the settings with a URL parameter "save_settings"?
Or what, if the plugin just adds a menu item "Switch to pages tab" (or "Create a page that contains the current settings and open it for edit")?

If you have an idea how to make this easier, you are welcome. But I fear, it would require a major change and not a patch.

[shawn_a]

Is this just an issue with settings? Since settings isn't really a tab ?

[mvlcek]

Is this just an issue with settings? Since settings isn't really a tab ?

No, it's an issue for plugins that add sidebar menu items in two or more tabs. When one of the sidebar menu items is clicked, GetSimple only knows that a function of the plugin was called (load.php?id=<plugin_name>&...), but it can't know, which tab to display. Thus the plugin itself has to analyze the request parameters and decide which tab is the current one and set this in the register_plugin(....) call.

It's just an inconvenience for these plugins (e.g. I18N Special pages), but I don't see any way to solve this easily with the current plugin/exec_action infrastructure.

[shawn_a]

ohh two or more, yes that makes sense.

That page_type nonsense.

[shawn_a]

This might be a little cleaner than messing with register plugin.
of course you would have to use multiple actions

PHP Code:

add_action('settings-sidebar','createSideMenu',array($plugin_id,'SideMenu','action1'));
add_action('header','settings_sidemenu');

function settings_sidemenu(){
  GLOBAL $plugin_info,$plugin_id;
  // if _GET['action1'];
  $plugin_info[$plugin_id]['page_type'] = 'settings'; //override page_type before include_nav loads.
} 


Same solution, of course we can edit core to possibly loop through the plugins hooks and find the matching action and use the pagetype from the hook name. Or add more arguments to the hook.

[shawn_a]

We really need to clean these hooks up, they are so confusing.

We should make sidemenus variable length arguments. There is no reason to have to always explicitly pass createSideMenu and plugin_id, overly complicated for new users.

ditto for nav-tab

[ale]

Hi,

thanks for the answers.

passing the function name and the arguments is ok. a dedicated function may even be better, but that part is somehow ok... once you have read the documentation.

back to the issue i've raised above...

in my eyes, the problem is that all the custom links go to "load.php", which defaults to "page" as the default.
in my eyes, there is no reason why the link should not go to the page having created the sidebar, in this specific case "settings.php". "settings.php", once it sees that "id" is set, should then forward the request to the concerned plugin, in the same way as load is currently doing.

implementing this should not be that disruptive...

ciao a.l.e

[shawn_a]

What point would that serve ?
Load.php IS for plugins.
That is the page for plugins.
That is its purpose.

yes we redirect to plugin, if there is no id, but that has nothing to do with plugins.
You want to redirect to load after hitting x.php ?
Why?

[mvlcek]

in my eyes, the problem is that all the custom links go to "load.php", which defaults to "page" as the default.
in my eyes, there is no reason why the link should not go to the page having created the sidebar, in this specific case "settings.php". "settings.php", once it sees that "id" is set, should then forward the request to the concerned plugin, in the same way as load is currently doing.

implementing this should not be that disruptive...

Except that you can add additional tabs - and there won't be a file <newtabname>.php in admin.

This could also - better - be solved by just adding an additional parameter (with the tab name) to createSideMenu, which uses it to add an additional URL parameter e.g. ...&tab=settings.
load.php could then set the tab based on this parameter.

Of course your other actions like save on your plugin's settings page would also need to add this parameter to their submit URLs.

[ale]

thanks shawn_a for the alternative way of routing to the page.

i still think that when submitting a form, GS should default to the current tab/page ... but, well, first i want to be able to finish my first plugin...

[shawn_a]

Maybe I will better understand this when I understand why you would need 2 sidemenus on different tabs.

[ale]

i'm managing the content of lists in the "pages" tab (where the content is...) and the creation the lists in the "settings" tab (where the real admin things are).

the list of lists goes in the pages sidebar, the "lists management" in the settings sidebar.