EasyPopulate 4.0 Support Thread

[mc12345678]

Even though i still have problems with my EP, i could not agree with you more. The feedback and help here are amazing.

@kernheimer, as you and I know, we have talked outside this forum. I would like to ask a few questions to find an answer.

In admin->Configuration->Easy Populate 4:

What are the settings for:
1. Import/Export Primary Key
2. Import Language Override

The problem described indicates a conflict.
To correct the issue I understand:
If 1. is products_id or blank_new, then 2. should *NOT* be products_model_only.
If 1. is products_model (historically the default), then 2. should *NOT* be products_id_only.

The above is for the problem described. The problem described has been, when importing a product file created by export, the system response is "No category provided for this new product".

I have more questions, but in this situation I want to slow down and address one issue at a time. Please continue to have patience.

[brittainmark]

I have just got the latest version from git hub and wanted to check if it is now a requirement that the folder in which you keep the uploaded files is under [YOURADMIN] directory.
The reason I ask is that I was having trouble with all the files showing CSV Unknow Delimiter. I tracked the code down to module easypopulate_4.php lines 438-444

$basepath = "";
  $realBase = realpath($basepath);
  $userpath = $basepath . $file;
  $realUserPath = realpath($userpath);
  if ($realUserPath === false || strpos($realUserPath, $realBase) !== 0) {
      return NULL; // return back to the function with a non-result?
  } 

The issue is that
$file /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realBase /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN
$userpath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realUserPath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv

does not pass the test unless EasyPopulateUploadDIR is under MYADMIN
thus $file /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN/EasyPopulateUploadDIR/Myfile.csv

I can leave the folder under MYADMIN just checking that this is now a requirement, OR if i have set something up wrongly.

[mc12345678]

I have just got the latest version from git hub and wanted to check if it is now a requirement that the folder in which you keep the uploaded files is under [YOURADMIN] directory.
The reason I ask is that I was having trouble with all the files showing CSV Unknow Delimiter. I tracked the code down to module easypopulate_4.php lines 438-444

$basepath = "";
  $realBase = realpath($basepath);
  $userpath = $basepath . $file;
  $realUserPath = realpath($userpath);
  if ($realUserPath === false || strpos($realUserPath, $realBase) !== 0) {
      return NULL; // return back to the function with a non-result?
  } 

The issue is that
$file /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realBase /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN
$userpath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realUserPath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv

does not pass the test unless EasyPopulateUploadDIR is under MYADMIN
thus $file /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN/EasyPopulateUploadDIR/Myfile.csv

I can leave the folder under MYADMIN just checking that this is now a requirement, OR if i have set something up wrongly.

Was not intended to become a "requirement". I have a fix for the above issue that retains the expected security.
It can be found at this commit: Restore import from catalog side/remove CSV delimiter warning · mc12345678/EasyPopulate-4.0@84331eb (github.com)

[mc12345678]

I have just got the latest version from git hub and wanted to check if it is now a requirement that the folder in which you keep the uploaded files is under [YOURADMIN] directory.
The reason I ask is that I was having trouble with all the files showing CSV Unknow Delimiter. I tracked the code down to module easypopulate_4.php lines 438-444

$basepath = "";
  $realBase = realpath($basepath);
  $userpath = $basepath . $file;
  $realUserPath = realpath($userpath);
  if ($realUserPath === false || strpos($realUserPath, $realBase) !== 0) {
      return NULL; // return back to the function with a non-result?
  } 

The issue is that
$file /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realBase /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN
$userpath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realUserPath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv

does not pass the test unless EasyPopulateUploadDIR is under MYADMIN
thus $file /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN/EasyPopulateUploadDIR/Myfile.csv

I can leave the folder under MYADMIN just checking that this is now a requirement, OR if i have set something up wrongly.

Was not intended to become a "requirement". I have a fix for the above issue that retains the expected security.
It can be found at this commit: Restore import from catalog side/remove CSV delimiter warning · mc12345678/EasyPopulate-4.0@84331eb (github.com)

I can't seem to "properly" edit the previous post and it is not a "timeout" issue, the original content just doesn't appear in the editor.

Anyways, the above is to be incorporated into the next version which I'm near completing for forum posting but had some things to work out/on.

[brittainmark]

Thats great. Thanks. If i find anything else shall i post here or raise issue on git-hub.

[mc12345678]

Thats great. Thanks. If i find anything else shall i post here or raise issue on git-hub.

For me to respond, either would work; however, generally in the spirit of the community, I would suggest posting here. If that is then determined better to capture/address in github such can be then be done.

I want to also say that the above posted "solution" considers the admin directory to be only one directory deep away from the "public" folder being used. E.g. if a store were found in https: // DOMAIN / sub-folder / 2nd sub-folder and the file were located at https: // DOMAIN / filename.csv Then I suspect/expect that the CSV unknown delimiter issue would occur... That also said, I was just about to indicate how I might change the message to reflect the condition causing this issue; however, I'm not so sure that I want to offer up that additional piece of info that the file is being retrieved from a location considered to be unauthorized...

The general principle behind the check is to consider the actual file path (location on the server) and in a way to ignore or not use database and/or constant related information when considering likeness.

[brittainmark]

For me to respond, either would work; however, generally in the spirit of the community, I would suggest posting here. If that is then determined better to capture/address in github such can be then be done.

I want to also say that the above posted "solution" considers the admin directory to be only one directory deep away from the "public" folder being used. E.g. if a store were found in https: // DOMAIN / sub-folder / 2nd sub-folder and the file were located at https: // DOMAIN / filename.csv Then I suspect/expect that the CSV unknown delimiter issue would occur... That also said, I was just about to indicate how I might change the message to reflect the condition causing this issue; however, I'm not so sure that I want to offer up that additional piece of info that the file is being retrieved from a location considered to be unauthorized...

The general principle behind the check is to consider the actual file path (location on the server) and in a way to ignore or not use database and/or constant related information when considering likeness.

Think I understand now. The "Uploads Directory Admin/Catalog" setting determins where the upload file should be located. I think my issue was that this flag had been reset in the update from false to true. I will reinstall and old version and reupdate to see if it happens again.

Just for completeness "Show all EP4 Filetypes with Files" has true and false with a capital letter, all the others are lower case.

[brittainmark]

Think I understand now. The "Uploads Directory Admin/Catalog" setting determins where the upload file should be located. I think my issue was that this flag had been reset in the update from false to true. I will reinstall and old version and reupdate to see if it happens again.

Just for completeness "Show all EP4 Filetypes with Files" has true and false with a capital letter, all the others are lower case.

Sused it. If you include the admin directory in the path of the "Uploads Directory" you set the "Uploads Directory Admin/Catalog" flag to true and remove the admin directory from the path. V clever!

I'll carry on testing.

[mc12345678]

Think I understand now. The "Uploads Directory Admin/Catalog" setting determins where the upload file should be located. I think my issue was that this flag had been reset in the update from false to true. I will reinstall and old version and reupdate to see if it happens again.

Just for completeness "Show all EP4 Filetypes with Files" has true and false with a capital letter, all the others are lower case.

The false to true condition is further discussed below. It is possible "upon upgrade" that the software will look in the admin instead of the store side if the previous version did not contain this configuration setting as the default install/upgrade is to add the configuration setting with it set to true by default. Therefore, if one were using the catalog side in the old version (where the setting did not exist), then when the configuration switch is added it is by default set to true and therefore now the software looks in the admin for the folder that was intended to be on the catalog side.

"Show all EP4 Filetypes with Files", I don't see where a capital letter is used for true or false in my search of the extra functions file and the main file. A capital is used for "Hidden", but that appears to be consistently used. If there is a discrepancy in other use of capital/small letter, could you please point me in the direction where that problem exists? "True" != "true" per se... At least it is not intended to be equal.

Sused it. If you include the admin directory in the path of the "Uploads Directory" you set the "Uploads Directory Admin/Catalog" flag to true and remove the admin directory from the path. V clever!

I'll carry on testing.

So, in an earlier effort to ensure that the admin directory remains as "obscured" as possible and recognizing that a default install of Zen Cart does not populate the database with the admin directory, I sought to remove storage of the admin directory in as "simple" of a way as possible. That is not to say that someone couldn't work around the issue and force the admin directory to be in the database, but I take that to be something that someone with the appropriate access and at that time authority wanted to include the admin directory and that it is on them, not necessarily the software.

Glad it was figured out though.. Thanks for feedback.

[kernheimer]

@kernheimer, as you and I know, we have talked outside this forum. I would like to ask a few questions to find an answer.

In admin->Configuration->Easy Populate 4:

What are the settings for:
1. Import/Export Primary Key
2. Import Language Override

The problem described indicates a conflict.
To correct the issue I understand:
If 1. is products_id or blank_new, then 2. should *NOT* be products_model_only.
If 1. is products_model (historically the default), then 2. should *NOT* be products_id_only.

The above is for the problem described. The problem described has been, when importing a product file created by export, the system response is "No category provided for this new product".

I have more questions, but in this situation I want to slow down and address one issue at a time. Please continue to have patience.

Dear mc12345678

What are the settings for:
1. Import/Export Primary Key. - Products_model
2. Import Language Override. _ Language_code _only