EasyPopulate 4.0 Support Thread

[Reviresco]

Okay here's how I got it to work:

In easypopulate_4.php, change:

zen_draw_form('import_form', basename($_SERVER['SCRIPT_NAME']), /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')

to:

zen_draw_form('import_form', FILENAME_EASYPOPULATE_4, /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')

and also do the same with the forms "delete_form" and "split_form"

Changing

basename($_SERVER['SCRIPT_NAME'])

to

basename($_SERVER['SCRIPT_NAME'], '.php')

also works.

[mc12345678]

Okay here's how I got it to work:

In easypopulate_4.php, change:

zen_draw_form('import_form', basename($_SERVER['SCRIPT_NAME']), /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')

to:

zen_draw_form('import_form', FILENAME_EASYPOPULATE_4, /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')

and also do the same with the forms "delete_form" and "split_form"

Changing

basename($_SERVER['SCRIPT_NAME'])

to

basename($_SERVER['SCRIPT_NAME'], '.php')

also works.

The best solution is to upgrade as soon as possible to 1.5.7c. There are a number of corrections that are implemented and considered necessary.

As to "this issue", the correction I believe is located in admin/includes/application_bootstrap.php (with possibility of other areas of the system affected/touched):
changing:

$serverScript = basename($_SERVER['SCRIPT_NAME']);
$PHP_SELF = isset($_SERVER['SCRIPT_NAME']) ? $serverScript : 'home.php';
$PHP_SELF = isset($_GET['cmd']) ? basename($_GET['cmd'] . '.php') : $PHP_SELF;
$PHP_SELF = htmlspecialchars($PHP_SELF);
$_SERVER['SCRIPT_NAME'] = str_replace($serverScript, '', $_SERVER['SCRIPT_NAME']) . $PHP_SELF;

To:

$serverScript = basename($_SERVER['SCRIPT_NAME']);
$PHP_SELF = isset($_SERVER['SCRIPT_NAME']) ? $serverScript : 'home.php';
if (basename($PHP_SELF, '.php') === 'index') {
    $PHP_SELF = isset($_GET['cmd']) ? basename($_GET['cmd'] . '.php') : $PHP_SELF;
}
$PHP_SELF = htmlspecialchars($PHP_SELF);
$_SERVER['SCRIPT_NAME'] = str_replace($serverScript, '', $_SERVER['SCRIPT_NAME']) . $PHP_SELF;

There may be other places where a change may be necessary to support the above; however, EP4 has not required the change described above to work in up-to-date systems.

[flappingfish]

i notice this is for .csv, i have a supplier that offers an .xml of products, is there a module for these or can this module be altered easily to work with .xml?

[cefyn]

I'm afraid I need a bit of advice here. I'm using Easy Populate 4.0.37.13, with the SBA mod. Does anyone know what import/export options in EP I should use to take a category with 300 products, all with 4 or 5 attributes (sizes), all with different stock levels, from one website, and copy it into another website? I foresee problems in that the options and attributes have different id numbers on each site, and I can imagine it all crashing horribly. The export site is on ZC 1.5.7b, the import site on 1.5.7c, both with the correct SBA version, (SBA for 1.5.7b, and SBA for 1.5.7c) and both with EP 4.0.37.13. Are there any steps I should take before attempting it ? Thanks.

[mc12345678]

I'm afraid I need a bit of advice here. I'm using Easy Populate 4.0.37.13, with the SBA mod. Does anyone know what import/export options in EP I should use to take a category with 300 products, all with 4 or 5 attributes (sizes), all with different stock levels, from one website, and copy it into another website? I foresee problems in that the options and attributes have different id numbers on each site, and I can imagine it all crashing horribly. The export site is on ZC 1.5.7b, the import site on 1.5.7c, both with the correct SBA version, (SBA for 1.5.7b, and SBA for 1.5.7c) and both with EP 4.0.37.13. Are there any steps I should take before attempting it ? Thanks.

So, the first question is why is the database being "manually" transferred from one site to another by a process other than transferring the entire database?

As far as the concern of matching product and designations, yes that is/would be a concern and for reasons that are described above.

Note also, that the SBA "filter" does not create/remove relationships of product attributes to/from product. It supports modifying the data associated with an existing relationship.

There is guidance in the README about the following: A way to reproduce attributes in one store from another using EP4:

That would at least get the attributes established, but then would need to go generate the SBA relationships. Then would suggest exporting the new SBA relationship file and compare/align data for a proper update.

I'm relatively certain that the question has been asked before in here with details provided. I've spent a little time trying to search on "SBA" or "stock by attributes". There are posts associated to each of those 2 search "terms", but I haven't dug into all/most of them and also haven't cross referenced when the SBA import/export was incorporated to narrow down the window of applicable dates. Maybe if it is found it can be linked back from this area.

[cefyn]

Thanks for your reply, mc. The database it's being copied from has 5000 products. There's an easy way to do it. Copied and uploaded the products with EP, used the native function admin/attributes controller/copy options to a whole category, and then just updated stock quantities with EP.

[mc12345678]

Thanks for your reply, mc. The database it's being copied from has 5000 products. There's an easy way to do it. Copied and uploaded the products with EP, used the native function admin/attributes controller/copy options to a whole category, and then just updated stock quantities with EP.

Glad that worked. Note that I had asked the question of why because 1) in following the standard ZC process for updating, the database is retained from one location to the other and 2) understand that if the same content is carried across multiple sites that as far as the internet is concerned, you're competing against yourself and the two sites having the same content will likely (eventually) cause a change in rankings. They may each have the same or different products_id; however, with ranking being content centric these two sites would initially grossly have the same content.

Again, understand that EP4 does not (yet) recreate the SBA variants which can be independently stocked from the total stock of the product. If the variants exist in the database, then yes natively copying should support duplication of the variants that can then be updated with EP4.

[mc12345678]

i notice this is for .csv, i have a supplier that offers an .xml of products, is there a module for these or can this module be altered easily to work with .xml?

"Easily" would be a matter of perspective; however, I can envision where the current "file read" code may be positioned to a function with some "trigger" being added to identify what the source is for the filetype and support properly moving through the file. While this operation is perhaps easier in newer PHP versions, it remains important to note that the process would work best by stepping into/through the file rather than loading it entirely into memory. The file reading occurs in a few of the modules as well as the main import file. There is also a field delimiter test that is performed against files that may need to be altered to exclude such xml files or provide an equivalent test if necessary.

[flappingfish]

"Easily" would be a matter of perspective; however, I can envision where the current "file read" code may be positioned to a function with some "trigger" being added to identify what the source is for the filetype and support properly moving through the file. While this operation is perhaps easier in newer PHP versions, it remains important to note that the process would work best by stepping into/through the file rather than loading it entirely into memory. The file reading occurs in a few of the modules as well as the main import file. There is also a field delimiter test that is performed against files that may need to be altered to exclude such xml files or provide an equivalent test if necessary.

Turns out on further checking i can actually make my own custom mapped feed at the suppliers website and in .csv format :). I've tried a few times. finally found how to add gtin as an option too and tried to upload again to get the following error messages "Missing primary key from file" and "File Import Completed with issues."

I've spent hours trying to solve this and even hired developers to install the module and get the feed working as i didn't fancy doing it myself. developers worked over the quoted time and between say 4 of us its getting frustrating lol. it's something simple being missed now i'm sure of it?

Anything that's commonly done that would cause such issues ie not including the "v_" beginning to product fields? i'm sure it was in this support thread i read your not supposed to include that part?

[mc12345678]

Turns out on further checking i can actually make my own custom mapped feed at the suppliers website and in .csv format :). I've tried a few times. finally found how to add gtin as an option too and tried to upload again to get the following error messages "Missing primary key from file" and "File Import Completed with issues."

I've spent hours trying to solve this and even hired developers to install the module and get the feed working as i didn't fancy doing it myself. developers worked over the quoted time and between say 4 of us its getting frustrating lol. it's something simple being missed now i'm sure of it?

Anything that's commonly done that would cause such issues ie not including the "v_" beginning to product fields? i'm sure it was in this support thread i read your not supposed to include that part?

The message provided indicates that whatever is being used for your "unique record" is not present in the first line of the file... By default that field header is: v_products_model
By making changes in the configuration menu, it is possible to instead change to using: v_products_id
By way of code, there is an observer that can be used to select/use a completely different primary key.

Note that again, this "primary key" is what ties the data being imported to the record(s) in the database. Depending on what is used for the primary key, multiple database records may be affected. For example, if there was a word within the products description that was used as a "primary key", then every record that has that word would be impacted by importing a row of data with that word. This is why when using v_products_model if more than one product has that exact model designation that import of a record with that model designation will affect all such product.

As far as the reference to using/not using the prefix "v_", that is associated to identifying other product table fields that are to be used in the import/export. The place where the "v_" is omitted is within the configuration settings for the User Defined Products fields... When entering/adding such fields within the configuration menu, they should be added using whatever the field is actually called in the products table.

Perhaps the above helps? It may be of assistance to provide the configuration settings and other pertinent information to get to your solution.