Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+2 votes
1.9k views
in Q2A Core by
I am using my own control panel for some specific plugins. From this panel, the plugins get linked so the admin does only have to click on "plugin x" which links to the plugin x's options.

Problem is that I do not have static links to the options. They change on other system. E. g. admin/plugins?show=07ca2e012f15a6730a289445a74b659e#07ca2e012f15a6730a289445a74b6512 does work on server A but not server B.

If I am using this "control panel" on another page, all links are dead links because the q2a software does not have static links to the plugin options.

How to solve this?
Q2A version: 1.7.4

1 Answer

+2 votes
by
edited by
 
Best answer

Edit file

/question2answer/qa-include/app/admin.php

Find and alter

function qa_admin_plugin_directory_hash($directory)
{
  //return md5($directory);
  return basename($directory);
}

function qa_admin_plugin_options_path($directory)
{
  //$hash = qa_admin_plugin_directory_hash($directory);
  $hash = basename($directory);
  return qa_path_html('admin/plugins', array('show' => $hash), null, null, $hash);
}

Result

You will now have static human-readable links for each plugin http://www.example.com/question2answer/admin/plugins?show=event-logger#event-logger 

http://www.example.com/question2answer/admin/plugins?show=recaptcha-captcha#recaptcha-captcha
 

Each plugin will save options normally with no issues.
At this time, I am not aware of any side effects other than that the links do not expire and the links can be predicted.

Enjoy

UPDATE!

For v 1.8.0

function qa_admin_plugin_directory_hash($directory)
{
	//$pluginManager = new Q2A_Plugin_PluginManager();
	//$hashes = $pluginManager->getHashesForPlugins(array($directory));
	//return reset($hashes);
   return md5($directory);
}

Or to simply link from anywhere (Updated)

qa_path('admin/plugins', array('show' => md5("pluginName"))).'#'.md5("pluginName")
by
An override is not possible, this needs indeed a hack. Hope it will be changed in the core. I wonder why we use a hash anyways. Securtiy?
by
Yeah, dunno!
I have been using this for a while now ... have not noticed any disadvantages...
by
edited by
Seems this does not work in 1.8.0 ... okay see updated answer, no need to touch core files :)
by
Regarding the need to build those URLs, I can't really figure out if there is a security improvement. I mean, everything is already protected by the /admin "middleware" so to speak.

However, the underlying reason I would do that is case-sensitiveness. In *nix-based systems, directory "Event-logger" is different from "event-logger" while in Windows-based systems it isn't. So if you happen to have those two directories in your qa-plugin directory, you are using Linux and the web server is configured to ignore case sensitiveness in URLs (I'm pretty sure there is a setting for that) then the web server will find two matches and one will be inaccessible.

BTW, note I was the one who has rewritten that part of the code and added the plugin manager class but I haven't actually modified the underlying logic from 1.7.x, just the structure. So hashes are still being used.

Regarding building the URLs in 1.8.0, check this function: qa_admin_plugin_options_path()

As a side note, concatenating strings is not the right approach to build URLs. Check the qa_path() function.
by
Excellent point on that qa_path ... I ran into a hole as I turned on furl. Updated answer to:
qa_path('admin/plugins', array('show' => md5("pluginName"))).'#'.md5("pluginName")
...