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/plugins/encapsulated_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,

$blockmail = DIR_FS_CATALOG . $emailfile; 

New path works but is hard coded,

$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 ?

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.

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).

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

$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

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/function.override-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;

 $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.

wilt:

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

$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 
> ```
https://mdomain.com/index.php?cmd=someplugincode
``` which will resolve to code within the plugin directory
That change is going to have a negative affect on the various URL manglers (e.g. USU/Ceon) since they're not going to 'understand' the ***&cmd=*** variable.

Just a quick note to say thanks for all the work on this one.

It is a vast improvement - even if only for admin at the moment.

Thanks to all ...

What additional code is needed to support stepping through the upgrade option?

I was working on an admin only plugin and wanted to keep the software unchanged in the original version, so I created a new version folder. I am using the installer class (don't recall the exact name) which has an install and deinstall method in it. (again specific name not recalled). I am able to uninstall the older/lower version and install the upper/higher version, but while the lower version is installed I am notified that a higher version is available. When I select the upgrade button, I am then presented with a radio button showing just the next higher version. As I step through that, there is no change in the installed version.

Now, any work done/to be done on such an upgrade also calls into question how existing settings (if present) might be expected to be retained. E.g. Is there a plan to store the settings that were in place with the plugin being upgraded to be able to restore said settings upon return or in event of a problem during upgrade? Not expecting that all of that would necessarily be internally "pre-"handled, but some sort of helper/consistent method to support something like that when/if coded or found necessary. Otherwise it seems that in an upgrade failure one would have to try to remove and then reinstall and manually make adjustments to "restore" settings associated with the plugin...

I have not reviewed the code progress associated with 1.5.8 yet.

Does anyone confirmed this plugin manager works? I have 2 issues with it, maybe somenone have some solution,
Issue #1
Blank page in Plugin Manager, logs show following error:
--> PHP Parse error: syntax error, unexpected '?' in /home/xxxx/public_html/zen_new/includes/classes/TableViewControllers/BaseController.php on line 232.
this happens at live server with PHP Version: 5.6.40 (Zend: 2.6.0)
Is there possibility I missed some info about php version needed to use it? (somehow I feel it may be the cause)
The same website on localhost works, plugin manager loads and let install items (almost)

Issue #2 (maybe Daveallen can help)
Tried install/remove testimonials manager using plugin manager but even thou it claims it is installed, database entries (tm status > on) are not added. Dont know if this is some issue with sql queries in installation script or plugin manager issue itself.

If this is not the place for these bug reports please move message in proper tread.

Thanks
Tomek

store-support:

Does anyone confirmed this plugin manager works? I have 2 issues with it, maybe somenone have some solution,
Issue #1
Blank page in Plugin Manager, logs show following error:
--> PHP Parse error: syntax error, unexpected '?' in /home/xxxx/public_html/zen_new/includes/classes/TableViewControllers/BaseController.php on line 232.
this happens at live server with PHP Version: 5.6.40 (Zend: 2.6.0)
Is there possibility I missed some info about php version needed to use it? (somehow I feel it may be the cause)
The same website on localhost works, plugin manager loads and let install items (almost)

Issue #2 (maybe Daveallen can help)
Tried install/remove testimonials manager using plugin manager but even thou it claims it is installed, database entries (tm status > on) are not added. Dont know if this is some issue with sql queries in installation script or plugin manager issue itself.

If this is not the place for these bug reports please move message in proper tread.

Thanks
Tomek

line 232 on 1.5.7a makes use of the coalesce operator, ie a double question mark, ??. support for that operator started in php7.0.
You could use the updated version from https://github.com/zencart/zencart/blob/v157/includes/classes/TableViewControllers/BaseController.php until you upgrade your PHP.

best.

carlwhat:

line 232 on 1.5.7a makes use of the coalesce operator, ie a double question mark, ??. support for that operator started in php7.0.
You could use the updated version from https://github.com/zencart/zencart/blob/v157/includes/classes/TableViewControllers/BaseController.php until you upgrade your PHP.

best.
Hmm, the docs (https://docs.zen-cart.com/user/first_steps/server_requirements/) that identify the requirements for various Zen Cart versions indicate that the zc157 series ***should ***work on PHP 5.6.

Update: Never mind, I see that the issue's been corrected for the forthcoming zc157c.

lat9:

Hmm, the docs (https://docs.zen-cart.com/user/first_steps/server_requirements/) that identify the requirements for various Zen Cart versions indicate that the zc157 series ***should ***work on PHP 5.6.

Update: Never mind, I see that the issue's been corrected for the forthcoming zc157c.
As I said in this commit: https://github.com/zencart/zencart/commit/289ede7a27375e9039323a7861bcb9daf8092310#r45515165
I had introduced PHP 7.x centric code as I had seen other similar use within the code at that time, then with consideration that the move should be to go to 7.x where 5.6 was active from more of a "highest available to support upgrading from some of the older systems", my (incorrect) independent evaluation that the plugins manager wouldn't necessarily cause a problem in routine operation as the "same" software could be installed manually as well, and any number of other incorrect tidbits about why it wasn't implemented with more "older system" readiness/compatibility.

So yeah, hi, I introduced that problem and as identified above it is written out in "long form" :smile: for zc 1.5.7c.

Great, thanks for info, got sorted my issues there and awaiting next release.

Is it OK to create a mixed admin/ store-front plug-in that uses plug-in manager for the admin side and leaves the store-front side as is?
Or is 1.5.8 nearly there and i am better waiting?

This would be amazingly confusing. If your plugin has front end and back end elements, just do it the old way for 1.5.7 and below.