Plugin Manager (in Zen Cart 1.5.7+)

To learn more about the Plugin Manager (a new 1.5.7 feature), and how to create plugins that work with it, please see

https://docs.zen-cart.com/dev/plugin...lated_plugins/

Remember, in v1.5.7 it only supports Admin plugins, not Catalog.

What's the best way to set a file path within the zc_plugins directory pathways!

This the old path,

Code:

---

$blockmail = DIR_FS_CATALOG . $emailfile;

---

New path works but is hard coded,

Code:

---

$blockmail = DIR_FS_CATALOG . '/zc_plugins/BlockEmailManager/v1.2.0/catalog/' . $emailfile;

---

The more I look at it, I think soft coding the version folder is all I need to fix...

What happens when you use the old path ?

Quote:

---

Originally Posted by swguy

What happens when you use the old path ?

---

The file was stored at the site root. If I place it there, all works. I was trying to use the catalog of the plugin manager,,, Thinking now of just having the installer move them to the root. The main idea was to have them accessible by bots same as the robot text file.

Quote:

---

Originally Posted by davewest

The file was stored at the site root. If I place it there, all works. I was trying to use the catalog of the plugin manager,,, Thinking now of just having the installer move them to the root. The main idea was to have them accessible by bots same as the robot text file.

---

At this point the catalog-side functionality isn't fully implemented. But your use-case certainly raises an important feature. While rare, there is definitely a need to support files whose purpose is intended to be an actual endpoint for site visitors to hit. It doesn't do that yet. So in the meantime you can put the file there manually by hand or by some script.
If possible it may be beneficial to make it a .php file that acts as a handler (see other handlers in the webroot of zc core already, although I recommend much briefer, merely a proxy) to call the "actual" script located in the plugin's proper directory, which might be locatable using a global var/constant defined in the bootstrapping process (eg perhaps an extra_datafile for the plugin).

Quote:

---

Originally Posted by DrByte

... While rare, there is definitely a need to support files whose purpose is intended to be an actual endpoint for site visitors to hit. It doesn't do that yet.

---

I have never known Ian to back down from a challenge! :)

Hi,

As mentioned already, for v157 there is not that much support for plugins are used catalog side, that will come in v158.

Note also that code within the zc_plugin directory is protected by an .htaccess file so, can never be run directly anyway.

That said...

You can get the path to a plugin using

Code:

---

$path = $pluginManager->getPluginVersionDirectory('myPluginKey', $installedPlugins)

---

$pluginManager and $installedPlugins are available in the global scope, so if you want to use them in a function/class method you will need to bring them into scope.

For v158 (and we have this working already) you will be able to have URI's like

Code:

---

https://mdomain.com/index.php?cmd=someplugincode

---

which will resolve to code within the plugin directory

Thanks, I figured there would be a easy way to format the path way into the folder. The files in question are simple text files storing spammer email addresses and domains. The text is created/maintained by the mod and placed at the site root for access by others seeking spam lists.

I was hoping we could override include. No such luck. :(

https://www.php.net/manual/en/functi...e-function.php

Here's another bit... Will the catalog side be fully disabled when the admin side is! Or can we control some of it..

Disabling the mod in admin plugin manager hides all the admin pages for the mod but leaves it all active on the catalog side!

As an example, Testimonials manager has a submit page and of course testimonials.. Submit page is still active with no abilities to manage them on the admin side if its disabled. I added on this version a switch to disable the submit process. This also allows for testing admin for a disabled condition turning off the submit process. Leaving testimonials visible while disabling the submitting of new ones is what I was after.

page header_php.php file;

Code:

---

$tm_plugin = $db->Execute("SELECT status FROM " . TABLE_PLUGIN_CONTROL . " WHERE unique_key = 'TestimonialManager'");
 $tmStatus = ($tm_plugin->fields['status'] == '2') ? 'off' : TM_DISPLAY_SUBMIT;

---

Then $tmStatus is acted on if the switch is off or admin is disabled.