encapsulated plugins require question....

[DrByte]

Depending on which file you're in, using __DIR__ could be useful (as opposed to __FILE__), as it gives you current directory information.

[mc12345678]

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?! :)

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

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:

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

[carlwhat]

Be careful about declaring a new class named `ups` if the store might already have a `ups` module installed.

noted.

v158 will support auto-loaded observers
(https://github.com/zencart/zencart/b...e);servers.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".

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.

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 $initSystem->setDebug(true);
https://github.com/zencart/zencart/b...InitSystem.php

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

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:

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

[carlwhat]

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:

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

$autoLoadConfig[200][] = [
    'autoType'  => 'class',
    'classPath' => 'includes/classes/observers/',
    'loadFile'  => 'my_bloody_observer.php',
    ]; 

much appreciated!

[mc12345678]

thank you.

this works here:

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

[carlwhat]

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.

[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

[mc12345678]

correct. yes.

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

[carlwhat]

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.

[mc12345678]

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.

[carlwhat]

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.