zc_plugins and new SQL Table

[brittainmark]

ZC 1.5.7c
PHP 7.4.11
mysql: 5.6.43

When creating a plugin and using scriped installer to do an install that creates a new table in the database.
The extra_datafiles>mybloodyplugin.php file that contains the table name is not loaded, so the table name defaults to TABLE_MY_BLOODY_PLUGIN or what ever you have called it.

Question.
Should scriped installer load the extra_datafile contents? If so, then a bug.
If not, then I assume that I should include the file as a "require" in the Installer>ScriptedInstaller.php. If this is the case, then is there a correct/preferred method of loading this file, or should the table name be placed elsewhere in another file that is loaded?

[brittainmark]

The following seems to work, but seems a bit clumsy

if (!defined('TABLE_MY_BLOODY_PLUGIN')) require DIR_FS_CATALOG . 'zc_plugins/' . $_GET['colKey'] . '/' . $_POST['version'] . '/admin/includes/extra_datafiles/my_bloody_plugin.php'; 

is there a better way or is it a bug?

[mc12345678]

So the "interesting" thing about this condition and the data that I have so far found available is that once a plugin is installed there is data/variables assigned that help out with accessing information about the plugin; however, before the plugin is installed, well there is not the same data available about the plugin going through installation. There is some data that might be able to be put together, but the way I got around it was to use a reference from the file's current location to then refer to the admin directory within the plugin.

So, I worked this by first performing a file check (with attempt to provide feedback if the file was missing, though accessibility to built in notifications is missing other than good ole $messageStack) then if it existed to load it by any of the following:

require_once dirname(__FILE__) . '/../admin/includes/extra_datafiles/filename.php';

Though, I guess could more generically could use the below to get all files associated which would make the installation file easier to use:

$GLOBALS['fs']->loadFilesFromDirectory(dirname(__FILE__) . '/../admin/includes/extra_datafiles', '~^[^\._].*\.php$~i');

or from some data collection while executing an install:

$GLOBALS['fs']->loadFilesFromPluginsDirectory([['unique_key' => $_REQUEST['colKey'], 'version' =>$_REQUEST['version'],]], 'admin/includes/extra_datafiles', '~^[^\._].*\.php$~i');

or also more specifically based on from what path the data is available.

$GLOBALS['fs']->loadFilesFromPluginsDirectory([['unique_key' => $_GET['colKey'], 'version' => $_POST['version'],]], 'admin/includes/extra_datafiles', '~^[^\._].*\.php$~i');

[carlwhat]

The following seems to work, but seems a bit clumsy

if (!defined('TABLE_MY_BLOODY_PLUGIN')) require DIR_FS_CATALOG . 'zc_plugins/' . $_GET['colKey'] . '/' . $_POST['version'] . '/admin/includes/extra_datafiles/my_bloody_plugin.php'; 

is there a better way or is it a bug?

in one of my ScriptedInstaller.php for an admin encapsulated plugin, i used the following code:

$dir = dirname(__DIR__, 1);
require $dir . '/admin/includes/extra_datafiles/my_bloody_plugin.php'; 

personally i am not a fan of using globals at all....

and considering we are in an installer, i think require suffices over require_once.

in addition, i think there is no need for the conditional, assuming your table is only defined within this plugin. it is safe to say, until installed, ZC will not load the extra_datafiles scripts.

best.

[mc12345678]

in one of my ScriptedInstaller.php for an admin encapsulated plugin, i used the following code:

$dir = dirname(__DIR__, 1);
require $dir . '/admin/includes/extra_datafiles/my_bloody_plugin.php'; 

personally i am not a fan of using globals at all....

and considering we are in an installer, i think require suffices over require_once.

in addition, i think there is no need for the conditional, assuming your table is only defined within this plugin. it is safe to say, until installed, ZC will not load the extra_datafiles scripts.

best.

While expected (by now) that the php version would be 7.0 or higher, its worth noting that dirname(__FILE__, 1) will not work on php versions below 7.0. Stated only at this point because ZC 1.5.7 supports down to php 5.6 and wouldn't want someone to get further aggrivated by trying it and expecting it to work.

As far as "globals", sure, can not like them all ya want, doesn't mean they have to be used either.

Looking again at the origin code $fs can be declared again.

$fs = FileSystem::getInstance();

And then in the above code of the post I made, replace:
$GLOBALS['fs']

With:
$fs

[brittainmark]

Thanks for the feedback as I only need it in the one place, I think I'll go with the $fs = FileSystem::getInstance();

Just fallen foul of the all plugins set to uninstalled issue. But that is another matter. Will have to evaluate how when the plugin has already been installed what is still present, so I don't overwrite any values or create a second set. Anyway, that is another issue.

Thanks for the help.

[mc12345678]

Thanks for the feedback as I only need it in the one place, I think I'll go with the $fs = FileSystem::getInstance();

Just fallen foul of the all plugins set to uninstalled issue. But that is another matter. Will have to evaluate how when the plugin has already been installed what is still present, so I don't overwrite any values or create a second set. Anyway, that is another issue.

Thanks for the help.

Yeah, well, I made that suggestion before attempting it...

Apparently there is a little bit of either a race condition or perhaps it is called something else.

At the point of installing, the FileSystem class has not been loaded it appears, try to require the FileSystem class in the installer code and then loading fails because ultimately the class gets loaded twice which is not permitted.. Further seems that attempts to use other existing FileSystem instances within the classes structure does not appear possible because of method definition to protected preventing access.

Seemed I was only able to access those FileSystem methods by use of the global of the $fs variable...

[brittainmark]

OK, thanks. Then will use

require dirname(__FILE__) . '/../admin/includes/extra_datafiles/filename.php'; 

Thanks again. It's always fun at the beginning when you are trying to understand it all.