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.
Printable View
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,
New path works but is hard coded,Code:$blockmail = DIR_FS_CATALOG . $emailfile;
The more I look at it, I think soft coding the version folder is all I need to fix...Code:$blockmail = DIR_FS_CATALOG . '/zc_plugins/BlockEmailManager/v1.2.0/catalog/' . $emailfile;
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 swguy
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.Quote:
Originally Posted by davewest
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).
I have never known Ian to back down from a challenge! :)Quote:
Originally Posted by DrByte
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
$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.Code:$path = $pluginManager->getPluginVersionDirectory('myPluginKey', $installedPlugins)
For v158 (and we have this working already) you will be able to have URI's like
which will resolve to code within the plugin directoryCode:https://mdomain.com/index.php?cmd=someplugincode
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;
Then $tmStatus is acted on if the switch is off or admin is disabled.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;
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.Quote:
Originally Posted by wilt
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
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.Quote:
Originally Posted by store-support
You could use the updated version from https://github.com/zencart/zencart/b...Controller.php until you upgrade your PHP.
best.
Hmm, the docs (https://docs.zen-cart.com/user/first..._requirements/) that identify the requirements for various Zen Cart versions indicate that the zc157 series should work on PHP 5.6.Quote:
Originally Posted by carlwhat
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/c...2310#r45515165Quote:
Originally Posted by lat9
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.
Yes also probably more difficult. I'll stick to old way roll on 1.5.8.Quote:
Originally Posted by swguy
I am trying to put my admin program into the zc_plugin folder and have hit a 3 day snag trying to figure out how to proceed.
Fresh install of 1.5.7c
Ubuntu 20.04 LAMP stack
DisplayLogs module installed
My module partially installed
PHP 7.4
Using the DisplayLogs file structure as an example, I successfully registered my plugin in admin and proceeded with setting up the installer. I have been able to interact with modifying the db but have came to a screeching halt.
I need to retrieve the configuration_group_id to do my inserts into the configuration table. Here is what worked in 1.5.6c:
Unfortunately, I have no experience with working with php classes. I have read tons of how to pages but nothing is sinking in or working for me.Code:$setup_gID = $db->execute("select `configuration_group_id`
from " . TABLE_CONFIGURATION_GROUP . "
where `configuration_group_title` = 'EZ-Feeds Settings' ");
if(isset($setup_gID->fields['configuration_group_id'])) {
$gID_setup = $setup_gID->fields['configuration_group_id'];
}
I have tried various forms of this (from configuration.php):
It returned 1, instead of 31, in one of my attempts...so I tried various forms of this:Code:$gID = (isset($_GET['gID'])) ? $_GET['gID'] : 1;
$_GET['gID'] = $gID;
$cfg_group = $db->Execute("SELECT configuration_group_title
FROM " . TABLE_CONFIGURATION_GROUP . "
WHERE configuration_group_id = " . (int)$gID);
NULL was returned in one instance and bool(true) in another.Code:$gID_setup =
"select `configuration_group_id` from " . TABLE_CONFIGURATION_GROUP . "
where `configuration_group_title` = 'EZ-Feeds Settings' ";
$this->executeInstallerSql($gID_setup);
var_dump($this->gID_setup);
exit;
I am blurry eyed and exhausted from trying to figure it out.
I would appreciate some insight on how to proceed.
BTW...great addition zc_plugin! It is going to be a huge time saver for developers after we figure out the ins and outs of it.
if this worked in v156c, i see no reason why it would not work in v157. perhaps i would do:Quote:
Originally Posted by mikeel100
PHP Code://from
if(isset($setup_gID->fields['configuration_group_id'])) {
//to
if(!($setup_gID->EOF) {
i am not sure what 'it' refers to.Quote:
Unfortunately, I have no experience with working with php classes. I have read tons of how to pages but nothing is sinking in or working for me.
I have tried various forms of this (from configuration.php):
It returned 1, instead of 31, in one of my attempts...Code:$gID = (isset($_GET['gID'])) ? $_GET['gID'] : 1;
$_GET['gID'] = $gID;
$cfg_group = $db->Execute("SELECT configuration_group_title
FROM " . TABLE_CONFIGURATION_GROUP . "
WHERE configuration_group_id = " . (int)$gID);
this code has little to do with classes. i would suggest studying a little more on php. your first line creates a var named $gID. if there is $_GET['gID'], $gID gets assigned that value, else it gets assigned 1. the second line assigns the $_GET['gID'] var to what $gID is. it makes no sense to me.
do you understand _GET vars? i would suggest reading about them. it is the way to pass data from a URL. reassigning it makes no sense (to me) in this context.
i normally use something called print_r as opposed to var_dump. but now we are into a class.... and executeInstallerSql will only return true or false. i have no idea what this might be: `$this->gID_setup`.Quote:
so I tried various forms of this:
NULL was returned in one instance and bool(true) in another.Code:$gID_setup =
"select `configuration_group_id` from " . TABLE_CONFIGURATION_GROUP . "
where `configuration_group_title` = 'EZ-Feeds Settings' ";
$this->executeInstallerSql($gID_setup);
var_dump($this->gID_setup);
exit;
i agree that the zc_plugins is a GREAT addition to ZC. but the problems that you are having are more related to your understanding of php than anything special about ZC. IMO.
not sure that helps.... but keep trying!
Carl, the code used in 1.5.6c was not buried in an extended class like it is in 1.5.7c zc_plugins.
Have you successfully added an admin plugin to the new structure? I seriously doubt it by the way you failed to answer my question...thanks for responding though.
You would know what "it" is if you read the query...
Yes, I know what GET and POST are...they did not work in my 1.5.6 version...thus the long code.
I will restate it again as plain as I can...
Within an extended class (ScriptedInstaller.php), how do I retrieve the configuration_group_id from the configuration group table while working in the zc_plugin file structure?
Below, is from ScriptedInstaller.php located in zc_plugins>MyPlugin>version>installer...this file is provided with the ZC distribution in the DisplayLogs folder under zc_plugins. I simply copied it and used as the basis for adding my plugin.
I will continue reading until I understand how to work with extended classes. I have been reading for 4 days now without figuring out how to get what I need.Code:use Zencart\PluginSupport\ScriptedInstaller as ScriptedInstallBase;
class ScriptedInstaller extends ScriptedInstallBase {
protected function executeInstall() {
HOW DO I RETURN THE configuration_group_id FROM THE configuration_group TABLE WITHIN THIS STRUCTURE?
$gID_setup = "select `configuration_group_id` from " . TABLE_CONFIGURATION_GROUP . " where `configuration_group_title` = 'EZ-Feeds Settings' ";
$this->executeInstallerSql($gID_setup); DO I HAVE TO MODIFY THIS executeInstallerSql FUNCTION?
.................
I was simply looking for a little help...anyone else?
I figured out something that will work...had to dig backwards through the functions.
Outside of zc_plugins, $db->execute precedes sql calls...inside of zc_plugins, $this->dbConn->execute($sql) precedes sql calls.
Code:$sql = "select `configuration_group_id` from " . TABLE_CONFIGURATION_GROUP . " where `configuration_group_title` = 'EZ-Feeds Settings' ";
$setup_gID = $this->dbConn->execute($sql);
if(isset($setup_gID->fields['configuration_group_id'])) {
$gID = $setup_gID->fields['configuration_group_id'];
}
For "reverse" compatibility, could also use either:Quote:
Originally Posted by mikeel100
orCode:global $db;
$db->Execute($sql);
Otherwise, and to piggy back on the some of the previous discussion, the thing with $this->executeInstallerSql is that it returns only true or false upon completion... It does not return anything from the query (other than success/failure)... That said and I still haven't tried it yet, but it may be possible to use MySQL temporary type variables within multiple queries to collect/use data without bringing the data back to the php space.Code:$GLOBALS['db']->Execute($sql);
Also, to potentially feed back about why the assignment of $_GET might be done would be to actually ensure that the value is assigned for follow on use, even though it would be better to just use the newly created $gID and if for some reason a link needed to be generated with that information, then just add it in as part of the link generation.
To also reiterate a previous suggestion, this:
should instead be written:Code:if(isset($setup_gID->fields['configuration_group_id'])) {
$gID = $setup_gID->fields['configuration_group_id'];
}
There are of course a few things that will need to be considered after this:Code:if(!$setup_gID->EOF) {
$gID = $setup_gID->fields['configuration_group_id'];
}
May need to test if $gID is set or not before attempting to use the value or perhaps assign a default value (which is what the previous code attempted by setting it to 1 if it didn't exist...
But as far as use of $_GET['gID'] within the installer of the plugins, well, at this point in accessing the admin, gID is not set because one is not navigating through the configuration menu.
seriously doubt no more. my plugin making use of the new zc_plugin structure:Quote:
Originally Posted by mikeel100
https://www.zen-cart.com/downloads.php?do=file&id=2279
zc_plugins getting uninstalled first reported by me:
https://github.com/zencart/zencart/issues/4014
a screenshot of one of my clients zc_plugins modules (most of which are not available for public download):
Attachment 19710
good luck resolving your issues and understanding extending classes. i would suggest not disparaging anyone on this board who makes a valiant attempt to help you with your problems.
PHP Code:use Zencart\PluginSupport\ScriptedInstaller as ScriptedInstallBase;
class ScriptedInstaller extends ScriptedInstallBase
{
protected function executeInstall()
{
// you need the next line:
global $db;
$sql = "select `configuration_group_id` from " . TABLE_CONFIGURATION_GROUP . "
where `configuration_group_title` = 'EZ-Feeds Settings' ";
$gidQuery = $db->Execute($sql);
if (!$gidQuery->EOF) {
$yourNUMBER = $gidQuery->fields['configuration_group_id'];
}
Thanks for all the replies and suggestions.
I ended up moving a protected function into the scripted installer from the plugin installer script...
Then retrieving what I needed with:Code:protected function executeEZFeedsSql($sql) {
$this->dbConn->dieOnErrors = false;
$data = $this->dbConn->Execute($sql);
if ($this->dbConn->error_number !== 0) {
$this->errorContainer->addError(0, $this->dbConn->error_text, true, PLUGIN_INSTALL_SQL_FAILURE);
return false;
}
$this->dbConn->dieOnErrors = true;
return $data;
}
My plugin is working fine now. It took several hours to figure out that I had to change my language file root folder path to point to the zc_plugins folder and I also had to move a few language file table, folder and file paths into the setup script.Code:$setup_gID = $this->executeEZFeedsSql($sql);
if(isset($setup_gID->fields['configuration_group_id'])) {
$gID = $setup_gID->fields['configuration_group_id'];
}
I will use compare both of your comments against what I have implemented and change as suggested where needed.
Carl, sorry for being so short. I was tired and frustrated from the lack of an answer from your (long and mostly unnecessary (first response)...will take it with a grain of salt the next time.