encapsulated plugins require question....
using a v157 base install.... i'm working on new admin plugin...
lets say there i have a class file, that is in:
zc_plugins/myplugin/1.0.0/admin/includes/classes/class.php
i now want to require() a new script in this class file. previously i might do something like
PHP Code:
require_once DIR_FS_ADMIN . 'includes/classes/other_class.php';
when i look at the $_SERVER vars, available to me, nothing pinpoints where i am in the file system to refer to new files that ideally i would like to keep in my encapsulated plugin.
is there an easy way to accomplish this goal? i'm guessing there is a ZC var that knows where i am. as i do not...
thanks in advance.
Re: encapsulated plugins require question....
There isn't any special function or variable for that as far as I recall.
But if the file is in the same or nearby directory structure, you could explore using relative paths with ../.. etc.
However, your post raises a question, and understanding context would help:
WHY are you requiring another file from within a class? Perhaps it's better to put your other desired file code into a class of its own and then simply refer to the class?
Re: encapsulated plugins require question....
Quote:
Originally Posted by
DrByte
There isn't any special function or variable for that as far as I recall.
But if the file is in the same or nearby directory structure, you could explore using relative paths with ../.. etc.
However, your post raises a question, and understanding context would help:
WHY are you requiring another file from within a class? Perhaps it's better to put your other desired file code into a class of its own and then simply refer to the class?
drByte, thanks for the input. it seems:
PHP Code:
$path_info = pathinfo(__FILE__)['dirname'];
works.
as far as why... whole other can of worms...
using api wrappers for some of the heavy lifting on common carrier codes rather than hand coding seems to make much more sense to me. and it is actually not within the class, but extending the class prior to the class declaration. ie:
PHP Code:
<?php
$path_info = pathinfo(__FILE__)['dirname'];
if (!file_exists($sdk_loader = $path_info . '/prose/vendor/autoload.php')) {
return false;
}
require $sdk_loader;
require_once $path_info . '/prose/shipping.php';
class ups extends shipping
{
does that make sense?
Re: encapsulated plugins require question....
i suppose my next question is whether observers work within the encapsulated plugin?
my initial testing suggests they do not. or perhaps it is just the auto loading observers that do not work?
i will try to manually load it.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
i suppose my next question is whether observers work within the encapsulated plugin?
my initial testing suggests they do not. or perhaps it is just the auto loading observers that do not work?
i will try to manually load it.
i can not get any observers to load from within an observers directory structure. which i suppose is why it is not listed here:
https://docs.zen-cart.com/dev/plugin...ory_structure/
it seems that the auto_loaders operates a little differently from within the zc_plugins directory that outside of it.
it seems that i can make do using a few hacks, but i think being able to load an observer from within the encapsulated directory structure would be a good idea.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
i suppose my next question is whether observers work within the encapsulated plugin?
my initial testing suggests they do not. or perhaps it is just the auto loading observers that do not work?
i will try to manually load it.
In observing did you both load the observer class and instantiate it as well as ensure that the observer is loaded/instantiated before the trigger point of the notifier is reached?
Also as to the require type condition as DrByte was discussing, the initial portion of the path is not mandated. Note how the admin's index.php file has in it a require includes/application_top.php and not an "admin" related prefix (which of course also doesn't exist at that point in loading the file).
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
PHP Code:
class ups extends shipping
Be careful about declaring a new class named `ups` if the store might already have a `ups` module installed.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
mc12345678
In observing did you both load the observer class and instantiate it as well as ensure that the observer is loaded/instantiated before the trigger point of the notifier is reached?
Also as to the require type condition as DrByte was discussing, the initial portion of the path is not mandated. Note how the admin's index.php file has in it a require includes/application_top.php and not an "admin" related prefix (which of course also doesn't exist at that point in loading the file).
i turned the DEBUG_AUTOLOAD on. and i could not get the proper file path to come up with for an observer from within the encapsulated directory. so instantiating it is kind of besides the point.
file paths are much trickier from within the encapsulated plugins. i'm not sure how much you have played with them. the auto load does a whole bunch of different things which unfortunately i do not have time to debug and play with.
my testing suggests that currently you will have to do some tricky things from within the auto_loaders config file to get to an observer from within an encapsulated plugin.
would love for you to prove me wrong or show me the way!
best.
Re: encapsulated plugins require question....
v158 will support auto-loaded observers
(https://github.com/zencart/zencart/b..._observers.php)
But v157 does not.
For v157 you could use the auto_loaders config files to declare which files/classes to load/instantiate "the old way".
Re: encapsulated plugins require question....
Quote:
Originally Posted by
DrByte
There isn't any special function or variable for that as far as I recall.
zcwilt just mentioned that there does exist a getPluginVersionDirectory() function:
https://github.com/zencart/zencart/b...ginManager.php
which is also used in the various methods of
https://github.com/zencart/zencart/b...InitSystem.php
Re: encapsulated plugins require question....
Depending on which file you're in, using __DIR__ could be useful (as opposed to __FILE__), as it gives you current directory information.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
i turned the DEBUG_AUTOLOAD on. and i could not get the proper file path to come up with for an observer from within the encapsulated directory. so instantiating it is kind of besides the point.
file paths are much trickier from within the encapsulated plugins. i'm not sure how much you have played with them. the auto load does a whole bunch of different things which unfortunately i do not have time to debug and play with.
my testing suggests that currently you will have to do some tricky things from within the auto_loaders config file to get to an observer from within an encapsulated plugin.
would love for you to prove me wrong or show me the way!
best.
Challenge accepted?! :)
Quote:
Originally Posted by
DrByte
The second link provides functionality that would get you to the point of loading and instantiating an observer class through the use of the auto_loaders type structure. Basically whatever "function" you wanted to be done would be the 'autoType' in the auto_loaders file. Effectively the method called within the InitSystem is 'processAutoLoader' . $var['autoType'] (yes there is some case play, but lets say you wanted to load a class file (such as an observer), then the 'autoType' would be 'class' to load the class, then 'classInstantiate' to initialize the class (calling its __construct method).)
To "simply" require a file would in fact need some "path" information as discussed above about "finding" where things are currently located so that the associated processAutoLoaderRequire method could pull in the correct file(s).
For loading a class would likely have the autoloader look something like:
Code:
<?php
if (!defined('IS_ADMIN_FLAG')) {
die('Illegal Access');
}
$autoLoadConfig[200][] = [
'autoType' => 'class',
'classPath' => 'observers/',
'loadFile' => 'new_observer.php',
];
$autoLoadConfig[200][] = [
'autoType' => 'classInstantiate',
'className' => 'zcObserverNewObserverClass',
'objectName' => 'myObsVariable',
'classSession' => false,
'checkInstantiated' => false,
];
This seems as if it would load an observers class in the admin directory of the plugins section for "this" version of the plugin.
The last two variables of the classInstantiate section are not required, but at least provide a template for what might be expected in instantiating a class through the plugin controller...
Re: encapsulated plugins require question....
Quote:
Originally Posted by
DrByte
Be careful about declaring a new class named `ups` if the store might already have a `ups` module installed.
noted.
Quote:
Originally Posted by
DrByte
as i just learned about the auto. loading of observers, i have previous done all of the "heavy lifting" myself. so this is not a problem.
Quote:
Originally Posted by
DrByte
ok... i will debug and find out where i am going wrong. or if there is an issue in the initSystem. i'm guessing now that this is where i will be looking.
https://github.com/zencart/zencart/b...System.php#L82
Quote:
Originally Posted by
DrByte
Depending on which file you're in, using __DIR__ could be useful (as opposed to __FILE__), as it gives you current directory information.
i ended up using:
PHP Code:
$path_info = dirname(__DIR__);
which i think is cleaner, in-line with what you are saying, and easier to read. i will perhaps investigate the aforementioned ZC function though.
thanks again. i will let you know where i have gone adrift in the loading of the observer.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
mc12345678
Challenge accepted?! :)
The second link provides functionality that would get you to the point of loading and instantiating an observer class through the use of the auto_loaders type structure. Basically whatever "function" you wanted to be done would be the 'autoType' in the auto_loaders file. Effectively the method called within the InitSystem is 'processAutoLoader' . $var['autoType'] (yes there is some case play, but lets say you wanted to load a class file (such as an observer), then the 'autoType' would be 'class' to load the class, then 'classInstantiate' to initialize the class (calling its __construct method).)
To "simply" require a file would in fact need some "path" information as discussed above about "finding" where things are currently located so that the associated processAutoLoaderRequire method could pull in the correct file(s).
For loading a class would likely have the autoloader look something like:
Code:
<?php
if (!defined('IS_ADMIN_FLAG')) {
die('Illegal Access');
}
$autoLoadConfig[200][] = [
'autoType' => 'class',
'classPath' => 'observers/',
'loadFile' => 'new_observer.php',
];
$autoLoadConfig[200][] = [
'autoType' => 'classInstantiate',
'className' => 'zcObserverNewObserverClass',
'objectName' => 'myObsVariable',
'classSession' => false,
'checkInstantiated' => false,
];
This seems as if it would load an observers class in the admin directory of the plugins section for "this" version of the plugin.
The last two variables of the classInstantiate section are not required, but at least provide a template for what might be expected in instantiating a class through the plugin controller...
thank you.
this works here:
PHP Code:
$autoLoadConfig[200][] = [
'autoType' => 'class',
'classPath' => 'includes/classes/observers/',
'loadFile' => 'my_bloody_observer.php',
];
much appreciated!
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
thank you.
this works here:
PHP Code:
$autoLoadConfig[200][] = [
'autoType' => 'class',
'classPath' => 'includes/classes/observers/',
'loadFile' => 'my_bloody_observer.php',
];
much appreciated!
Hmmm, because I was going to make a suggestion of a potential alteration to the above path, wanted to ask/confirm that the observer is in fact in the plugin and not installed to the "core" fileset, correct?
Re: encapsulated plugins require question....
Quote:
Originally Posted by
mc12345678
Hmmm, because I was going to make a suggestion of a potential alteration to the above path, wanted to ask/confirm that the observer is in fact in the plugin and not installed to the "core" fileset, correct?
correct. yes.
Code:
[236] => Auto Type Method - processAutoTypeClass
[237] => processing class - /var/www/base157/zc_plugins/shipAdmin/1.0.0/admin/includes/classes/observers/my_bloody_observer.php
[238] => loading class - /var/www/base157/zc_plugins/shipAdmin/1.0.0/admin/includes/classes/observers/my_bloody_observer.php - SUCCESS
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
correct. yes.
Code:
[236] => Auto Type Method - processAutoTypeClass
[237] => processing class - /var/www/base157/zc_plugins/shipAdmin/1.0.0/admin/includes/classes/observers/my_bloody_observer.php
[238] => loading class - /var/www/base157/zc_plugins/shipAdmin/1.0.0/admin/includes/classes/observers/my_bloody_observer.php - SUCCESS
Seems like it would be a good idea in the docs to indicate that constants such as DIR_WS_INCLUDES should not be used in plugins when referring to directories such as the classes and/or other "defined" paths...
Reason? those particular constants are associated with the store and not with the plugins where plugins should be developed to be applicable to "any" store's configuration. Meaning, the path used should be relative to the plugin's directory structure and not the store's directory structure when referencing items within the plugin's folder...
I was otherwise going to suggest actually using DIR_WS_CLASSES (which I thought was going to be used by the plugin loader path until you made the change identified above and showing the processed path here).
Btw, in line with DrByte's previous statement about loading a class file, using the above 'class'/'classInstantiate' would allow you to declare a variable name that can be used within your other plugin areas. That variable is the 'objectName'. In this way you don't have to "chase" down the current path for the file being loaded, just load the class as part of your plugin and reference it from within the plugin...
Re: encapsulated plugins require question....
Quote:
Originally Posted by
mc12345678
Btw, in line with DrByte's previous statement about loading a class file, using the above 'class'/'classInstantiate' would allow you to declare a variable name that can be used within your other plugin areas. That variable is the 'objectName'. In this way you don't have to "chase" down the current path for the file being loaded, just load the class as part of your plugin and reference it from within the plugin...
interesting. perhaps i will look into it.
next hurdle to jump over is some javascript files that need to get loaded on the page load. again trying to keep everything within the encapsulated plugin directory. i suppose i could load the contents into the page load as opposed to a reference to the file (which would necessitate being outside of the plugin). but i am open to other ideas.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
carlwhat
interesting. perhaps i will look into it.
next hurdle to jump over is some javascript files that need to get loaded on the page load. again trying to keep everything within the encapsulated plugin directory. i suppose i could load the contents into the page load as opposed to a reference to the file (which would necessitate being outside of the plugin). but i am open to other ideas.
Umm. there's already script to load a plugin's javascript:
admin/includes/javascript_loader.php Starting at about line 54... Appears that there is "no magic" necessary. Filenaming may be the only "trigger" issue of concern.
Re: encapsulated plugins require question....
Quote:
Originally Posted by
mc12345678
Umm. there's already script to load a plugin's javascript:
admin/includes/javascript_loader.php Starting at about line 54... Appears that there is "no magic" necessary. Filenaming may be the only "trigger" issue of concern.
ok, thanks for this. it seems that i had some difficulty with file names that had multiple words in them. for example, if my filename was bloody.php, includes/javascript/bloody.js would load as well as includes/javascript/bloody_rsvp-min-3.1.0.min.js. if, my filename was bloody_mask.php; i had some difficulty getting the .js files to load.
could be me.
but, again, i do appreciate the help. using the ZC file naming for loading javascript works out better here.
best.
