Display Logs Plugin Stuck In A Loop

[mikeel100]

ZC version: 1.5.7c
Plugins: Display Logs and MyPlugin (in development)
PHP version: 7.4
Ubuntu 20.04 LAMP with Mariadb

Display logs got stuck in a loop when I tried to delete all logs. I hit the browser stop icon because it was taking so long to delete 6 log files. When I was able to return to the log screen, the first file was over 5 MB in size.

Within the zc_plugins file structure, I was in the process of modifying init_MyPluging.php to try and find a way to get the plugin name and version (for using in my language file definitions). I was going to extract the data by reading the manifest.php file with this code:

//
$file = fopen("../../../manifest.php", "r");
while (!feof($file)) {
//...get name and version...
$info = fgets($file);
$data = explode('\n', $info);
fclose($file);
}

On a side note, I would appreciate it if someone could tell me how to get the plugin name and version as constants or variables before the language file definitions are loaded.

Probably should open another question up but thought I'd knock 2 birds out with one post if possible.

Thanks.

[mc12345678]

What do you mean by being in a loop?

As far as before and after in deleting, did any of the original 6 log files get deleted? Was this supersized file there before attempting to delete or was it caused by attempting to delete?

As for determining the plugin information, there are some global/class like variables that have that information or can readily make it available. It may be helpful to understand more about at what point in operation/install this information is being gathered and/or being used. I mean think about it, the way attempted basically already assumes that the current directory is within the plugin, so there must have been some amount of information available at that point to get to that subdirectory.

Out of curiosity what language information is so generic that it depends on plugin "path" like information instead of being hard coded?

Btw, in my opinion, running at least some level of risk by exploding on "\n" without either forcing or verifying that the line ending is or is only "\n".

[mikeel100]

What do you mean by being in a loop?

As far as before and after in deleting, did any of the original 6 log files get deleted? Was this supersized file there before attempting to delete or was it caused by attempting to delete?

As for determining the plugin information, there are some global/class like variables that have that information or can readily make it available. It may be helpful to understand more about at what point in operation/install this information is being gathered and/or being used. I mean think about it, the way attempted basically already assumes that the current directory is within the plugin, so there must have been some amount of information available at that point to get to that subdirectory.

Out of curiosity what language information is so generic that it depends on plugin "path" like information instead of being hard coded?

Btw, in my opinion, running at least some level of risk by exploding on "\n" without either forcing or verifying that the line ending is or is only "\n".

The Firefox browser working arrow kept spinning after I attempted the file open code (in my plugin) mentioned previously. Stopping the browser (X) enabled me to return to DisplayLogs...where I attempted to delete the 6 files. It deleted the 6 files but new error log entries immediately appeared within the Display Logs screen. I tried deleting the files multiple times but kept getting more new log files. I had to uninstall DisplayLogs and shut down my server completely to stop the loop.

Needless to say, I abandoned my approach to getting the directory path from the manifest file.

The supersized files were not there before I attempted to run my custom code.

As far as needing the plugin path is concerned, I need it to improve the portability of my plugin. At the moment, MyPlugin_filenames.php has my admin base directory identified like this:

define('DIR_EZ_FEEDS_TOP', DIR_FS_CATALOG . 'zc_plugins/EZ-Feeds/v1.5.7c/admin/includes/'); 

Every time I need to copy the plugin to another shop, this line of code will have to be edited to make it work...clear as muddy water?

I was able to find a variable, $filePath, that gives me the path I need:

/var/www/jestcountry.com/zc_plugins/EZ-Feeds/v1.5.7c/

I put the following code in init_MyPlugin.php thinking that would solve my problem.

//use Zencart\FileSystem\FileSystem;
if ($current_page == FILENAME_EZFEEDS . '.php') {
    define('DIR_EZ_FEEDS_ZC_PLUGINS', $filePath);
    print_r('defined in init_ezfeeds.php but not following to ezfeeds_filenames ... ' . DIR_EZ_FEEDS_ZC_PLUGINS);
} 

The define is working within init_MyPlugin.php and even prints when my base admin file is loaded.

However, using the new define, DIR_EZ_FEEDS_ZC_PLUGINS, in MyPlugin_filenames.php is not working...

I do not understand this behavior because the Zencart Docs program flow help page indicates init is loaded before defines. What am I missing?

I tried moving the init code into extra_configures but the variable, $filePath, is not available in extra_configures.

I'll keep looking....

Thanks for your help.

[mikeel100]

Additionally...init_MyPlugin.php does not autoload under zc_plugins. I have to use config.MyPlugin.php to require the file.

$autoLoadConfig[300][] = array(
    'autoType'  => 'require',
    'loadFile'  => DIR_FS_CATALOG . 'zc_plugins/EZ-Feeds/v1.5.7c/admin/includes/init_includes/init_ezfeeds.php'); 

This is another place where the new define, DIR_EZ_FEEDS_ZC_PLUGINS, would be usefull. However, the define would have to be set within the core files in order to be useful here.

So, I am stuck for now unless I modify a core file...really don't want to do that.

This is getting off topic for this tread...do you want me to start a separate thread?

[mikeel100]

I found a way to define my root directory in the extra_configures under the zc_plugins file structure.

use Zencart\FileSystem\FileSystem;
$ezfeedsPath = FileSystem::getInstance()->getPluginAbsoluteDirectory('EZ-Feeds'); 
define('DIR_EZ_FEEDS_ZC_PLUGINS', $ezfeedsPath); 

Now I don't have to change 7 other lines of code in 2 different files.

I am sure that a variable is available for 'EZ-Feeds', in getPluginAbsoluteDirectory('EZ-Feeds'); , but I have to figure that out as well...pretty sure the answer lies in application_bootstrap.php. If anyone can shed some light, I will be grateful.

It would be great if the dev team would consider automating a define for the base file directory of each plugin within the core files...

[carlwhat]

    use Zencart\FileSystem\FileSystem;

    $test = FileSystem::getInstance()->getPluginAbsoluteDirectory('EZ-Feeds');
    echo "-------->" . $test . "<---------<br>";
    
    $path_info = dirname(__DIR__, 3);

    echo "-------->" . $path_info . "<---------<br>";

    die('<br>' . __FILE__ . ':' . __LINE__); 

i would explore the dirname (as well as pathinfo) functions in php. much more reliable. you might need to append a trailing slash.

i would advise you to use your own version number for your plugin; ie 1.0.0 and update as necessary. 1.5.7c is the zen-cart version, not your plugin version.

[mikeel100]

    use Zencart\FileSystem\FileSystem;

    $test = FileSystem::getInstance()->getPluginAbsoluteDirectory('EZ-Feeds');
    echo "-------->" . $test . "<---------<br>";
    
    $path_info = dirname(__DIR__, 3);

    echo "-------->" . $path_info . "<---------<br>";

    die('<br>' . __FILE__ . ':' . __LINE__); 

i would explore the dirname (as well as pathinfo) functions in php. much more reliable. you might need to append a trailing slash.

i would advise you to use your own version number for your plugin; ie 1.0.0 and update as necessary. 1.5.7c is the zen-cart version, not your plugin version.

Thanks Carl. It looks like you answered about the same time I found that solution.

I think I will keep my version number as is. I have been working on this plugin since 1.3.8a. If I ever submit it for approval, I will rename it if needed.

I ran across your other suggestions about dirname and pathinfo last night while reading other posts about zc_pluggins...very informative and useful.

I actually ended up putting my custom define at the top of my filenames and deleting my init and extra configures files.

I was making things way to difficult because I had not grasped the new directory structure, tools available and because I am not used to working with classes. I was trying to use the DisplayLogs as a boiler plate...mistake on my part. I don't need to use the scripted plugin method at this point. The basic plugin method will probably suit my needs.

I experimented with adding code to the end of the bootstrap file to try and create a defined zc_plugins directory for every plugin...all the required info is available there, why not automate it? I couldn't get the define to pass to any other files. Maybe someone with more expertise can figure it out and have it added in the future.

I have working code now under the zc_plugins structure so I will bury this dead horse for now.

Thanks again, everyone.