EasyPopulate 4.0 Support Thread

[mc12345678]

I do have a question if this is possible.....

My warehouse DB uses the Excel or CSV format.

I tie my Excel DB with my Warehouse Excel DB.

I am using the =vlookup command when I use the product number and quantity from the warehouse excel DB and when I use my Excel DB some of my quantities says "N/A" when means either my warehouse doesn't carry that product anymore. When I upload the updated excel to to the it shows those products shows (0) quantities. Is it possible that the N/A can be automatically deleted from the database without me delete it from the database manually?

Could you please clarify? When I first read the message I thought the request was to possibly delete the product from the database, but now it seems like may be asking to delete the text 'N/A' from the product's quantity.

If it is the deletion of 'N/A' I would say that the "better" option is to further use the formulas to detect if the value is N/A and use 0 when it is. The function ISNA supports that.

[jimmie]

i have a custom field in products table called barcode(also known as UPC), when i export this field the values look like this 7.34995E+11, and it imports like this

[mc12345678]

i have a custom field in products table called barcode(also known as UPC), when i export this field the values look like this 7.34995E+11, and it imports like this

In what application does it change to that? I would not expect the CSV file downloaded from the server and opened with a plain text editor to look like that. If the spreadsheet program is used, then it appears that this column should be identified to be treated as text upon import rather than numbers if it allows.

[jimmie]

i open it with microsoft excel

[mc12345678]

i open it with microsoft excel

Definitely Excel is taking that long set of numbers and changing the display of them scientific. That column though should be treated as text on import.

I did an Internet search for: excel import csv column as text

And came up with a lot of good results.

[chibipaw]

Im trying to set up a simple cron job to import a CSV.
However, upon trying to run the command php ep4_cron.php import=myproducts.csv, the system throws a bunch of these types of errors.
Notice: Undefined index: securityToken in [myadmin]/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE' in easypopulate_4_import.php on line 2493

Any thoughts on how to properly get this to work? There doesnt not seem to be much of any documentations at all.

[mc12345678]

Im trying to set up a simple cron job to import a CSV.
However, upon trying to run the command php ep4_cron.php import=myproducts.csv, the system throws a bunch of these types of errors.
Notice: Undefined index: securityToken in [myadmin]/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE' in easypopulate_4_import.php on line 2493

Any thoughts on how to properly get this to work? There doesnt not seem to be much of any documentations at all.

It's relatively new and incorporated to help someone that had asked for the possibility and didn't know how to put together the bits that would be necessary for its execution, so yes, little to no documentation other than what is in the file itself.

As for the warnings received, that's because the language file is not pulled into the cron and not into the import portion. Furthermore it's because the import file does more than just import, it also prepares text to be exported, but does not actually export text.

So, to get those messages to go away, I am thinking the following would work.

In line 332 of admin/ep4_cron.php add the following:

if (isset($_SESSION['language']) && file_exists(DIR_FS_ADMIN . DIR_WS_LANGUAGES . $_SESSION['language'] . '/easypopulate_4.php')) {
    require DIR_FS_ADMIN . DIR_WS_LANGUAGES . $_SESSION['language'] . '/easypopulate_4.php';
} else {
 require DIR_FS_ADMIN . DIR_WS_LANGUAGES . 'english'. '/easypopulate_4.php';
}

With the require for the import file being at line 339 as it may seem.

My ISP is having some serious issues so I am limited on what I can test, confirm, and manipulate basically by what my cell phone can do or what can be done with limited cell phone data tethering.

[jodean]

Is the 1.56c version now supported?

[mc12345678]

Is the 1.56c version now supported?

Not 100% sure how to answer this question. As written (which may be related to a language issue) the answer is yes because issues that are identified are corrected. As perhaps understood to be meant, I have been able to successfully use EP4 as provided from GitHub on ZC 1.5.6c. Currently, one of the added features is not 100% complete.

The new feature of using the extension of _en or similar to denote a specific language works for the full import; however, does not for one or two of the other imports.

Note, that this new feature has been incorporated to allow continued use of the import file(s) as they were (a language dependent field ending with the language_id associated with how that database is setup) but it also offers some override type features where if both the language_code (e.g. en, de) and language_id were used then one overrides the other.

Further note, that although I chose to be somewhat forceful in discussion with a recent user at the cost of being seen as a jerk, the information obtained led to a solution that resolved the issues that otherwise were going to be ignored.

As far as the software with Zen Cart 1.5.6c there is nothing done to that version of software affecting this, the issues if any are or expected to be related to php versions.

[linuxguy2]

ZC 1.5.6a Classic Clone.
CheckBoxTextBoxIconV1.0.3
EasyPopulate-4.master-ZC
one_page_checkout-2.0.5
ColumnGridLayout_for_155f

Using two "Product Types"
(Type 1) Product General and (Type 4) Document Product.
When I export with ep4 the v_products_type column is correct.
( I get 1 & 4 )
When I import all type 4 get changed to type 1.
Searched all morning but could not find a solution.
Is there a setting that over rides product types when importing with EP4?

In Admin "editing " category mode (Type) doesn't have any effect on the Product Type setting of products already entered.
When entering new products in Admin the Type setting works correctly

Thank You in Advance for your time.