EasyPopulate 4.0 Support Thread

[HugoStiglitz]

Just checking in to see if there is any movement on the v_options_values_price_w issue?

Thanks,

[mc12345678]

Just checking in to see if there is any movement on the v_options_values_price_w issue?

Thanks,

Did you try the latest version identified in this post? https://www.zen-cart.com/showthread....22#post1278422

[mc12345678]

Did you try the latest version identified in this post? https://www.zen-cart.com/showthread....22#post1278422

FWIW, I just confirmed that the field is addressed in the above version. What I request is confirmation that it works as expected/desired.

[reetp]

Spent a day bashing my head on importing price breaks and finally conceded defeat :-)

I started using the lastest EP from github on ZenCart 1.54 - I have been using variations for a long time. I also tried the 4.0.29 update without any success either.

I have a script that parses my data and exports to the appropriate format - spent a long doing that when I first started and have had it down to a fine art until now.

I can easily bulk import the basic records but when it comes to the price breaks it appears to import correctly, but when you look at a product there is no additional pricing. I have tried making sure the file is identical to the original - even making sure that it renders numerals to 3 decimal places.

If I manually add a few prices to a product and then EXPORT from ZenCart, or just import without, I can manually adjust the prices in a plain text editor and it imports the changes back. But despite appearing to completely replicate the file, if I try with my own clean file, it fails (with no apparent errors)

I have posted a couple of demo files here :

http://www.reetspetit.com/Other

The first 3 starting 2015_ are the 3 generated from my code.

2015_Full-EP_Products15_06_17-184924.csv - this will import OK
2015_Remove_file_Products15_06_17-184924.csv - this works OK
2015_PriceBreaks-EP_Products15_06_17-184924.csv - this will not modify the prices or add quantity discounts


PriceBreaks-EP2015Jun17-192419.csv - export from the above imports
PriceBreaks-EP-edited.csv - manually edited. This WILL add/change prices


If you diff 2015_PriceBreaks-EP_Products15_06_17-184924.csv and PriceBreaks-EP-edited.csv the only difference are the prices, and the 'Edited' file was done manually using mcedit.

There is no obvious difference that I can see.....

Any help gratefully appreciated !

B. Rgds
John

[mc12345678]

Code "response" for some opertions are filename dependent.

This is described in the instructions.

[mc12345678]

Code "response" for some opertions are filename dependent.

This is described in the instructions.

From README.txt:

5) File names act as a switch inside the script for Importing. Namely: PriceBreaks-EP, CategoryMeta-EP, Featured-EP, SBA-Stock-EP, and Attrib-Basic-EP/Attrib-Detailed-EP ... these import files must have names that start with this string.

[reetp]

Oh FFS ^&((*"$&()£&%*(^&"$*(^""$( swear bang crash.

Sorry - I have been using the same format for some time - probably 4 years - and just had not realised that it had changed. Thank you pointing it out.

I had read the 'README.txt' but must have glazed over the filename - when you look at it on github, the end of the line is missed off so I only saw :

"5) File names act as a switch inside the script for Importing. Namely: PriceBreaks-EP, CategoryMeta-EP, Featured-EP, SBA-S"

So I wrongly assumed that it was the same rule as before and that so long as the file name CONTAINED this it would be OK.

I even started debugging and saw that it picked up the file as an import file and didn't see any other errors whilst it was processing.

Can I make a suggestion that there should be some form of sanity checking on the filename ? As far as I could see it all went through OK and reported that it had succeeded in the import, which obviously is a complete lie.

If I can figure where to do it I'll try and do a patch myself.

Thanks for the rapid response.

B. Rgds
John

[mc12345678]

Yosameti Sam at his worst. :)

I pulled that from the bottom of the github screen.

What I see can be done, though the code structure doesn't necessarily support such a clear separation of function is to provide notification on import of which "filetype" is being processed.

Alternatively and probably more user friendly/understandable is to have in the admin panel different "windows" ssociated with each filetype by name... An example of the expected filenme prefix shown.

That I think would take things the step further that would help those that have not read the instructions.

Btw, if 5 waas the last one to see/read, then there is a lot to go. The file is included in the download so should be able to read it from desktop.

[reetp]

LOL :-)

I think I start to understand.

It all starts to go wrong at this point in the import file :

1407 if ( strtolower(substr($file['name'],0,14)) == "pricebreaks-ep") {

First, that is probably a change from the version I was using and does indeed only check the START of the filename string whereas before it parsed the whole string probably something like this :

$filename = "test-file-pricebreaks-EP-myname.csv";

if (stristr($filename,"pricebreaks-ep")) {
echo "We found it";
}

That is case insensitive and find the filename anywhere in the string.

Second is that that if it FAILS that test, it jumps through to 1459 and carries on regardless... arrrrggghhhh !!!!!!!! That means it misses some vital bits, but still appears to work.

That is really bad..... it ought to gracefully die and notify the user that 'Filename is incorrect" when it fails the file check (and that occurs in several places). I'm no php coder, but it ain't rocket science....

Not sure how you want to fix it, but it is badly broken :-)

Happy to test anything if you want to try and resolve it.

B. Rgds
John

[mc12345678]

So, in a way I beg to differ that it is broken... That is akin to renaming a zip file of a text document to have an extension of .txt, then trying to open the document in a standard text editor expecting to be able to read the text as originally written.

File opens fine, there is some content provided, but it all did not work as "expected"...

EP4 was written to offer some greater flexibility, assuming that the operator(s) followed the instructions...

Sure, the filenaming could check for presence of words, but then it will be that the chosen text is "wrong", then ever more users will have to change their filename convention after that change.

Okay, all that aside, with the current filenme convention, when a directory is sorted by filename, each file "type" remains together and actully is sorted by date, so "restoration" of a state is easily identifiable. Then there is the saving of a modified file, go to the end of the filename, and do what is desired with it. If the files are sorted by modified date, the the result similar to prefixing the file with a date is obtained, identifying what file was changed and when. Presumably shortly after the change, the file is uploaded to effect the change. An added benefit of the "loose" action within the code is that fields that are not routinely a part of one of the special cases can also be included and will be processed. There are though some things that are relatively specific to the special name mostly requiring different queries compared to the product/product description.

Lastly, the code is modifiable to suit unique desires/needs. The code suggested could be individually incorporated, but in the grand ease of use and instruction, to me I struggle to see how that would provide an overall improvement.