EasyPopulate 4.0 Support Thread

Also, just so we are clear on how I am doing this. I am doing my edits the same way someone would add new products. At the bottom (end) of the spreadsheet, I add the product information as if it were a new product. From my understanding, it should just overwrite whatever information has been changed. It seems to work fine, since it edits the quantity and doesn't create a doubled product. BUT it deletes the product name.

Now .... when I specifically go to a current item .... if I merely change the qty and import, everything is fine. Qty gets updated and everything is in tact. The filename only gets wiped when the method is like I'm adding a new product.

Does this plugin allow exporting products images as well?

Thannaree:

Does this plugin allow exporting products images as well?

This plugin is a database related plugin and will export the path to the base image (please read the applicable FAQ for additional images). It does not export the actual image itself. It is generally considered that ftp be used to export the file that is the image (or "right" clicking the image and saving it when it is displayed onscreen).

Jenovee:

Also, just so we are clear on how I am doing this. I am doing my edits the same way someone would add new products. At the bottom (end) of the spreadsheet, I add the product information as if it were a new product. From my understanding, it should just overwrite whatever information has been changed. It seems to work fine, since it edits the quantity and doesn't create a doubled product. BUT it deletes the product name.

Now .... when I specifically go to a current item .... if I merely change the qty and import, everything is fine. Qty gets updated and everything is in tact. The filename only gets wiped when the method is like I'm adding a new product.

This is a process different than tested... Seems that if the model# is known, it could be just as easily searched for as compared to retyped, unless I am missing something... Will still look at the process to see why "adding" the product anew in the list has a different affect than modifying the item in the list. Would almost suggest in this scenario that all other line records be removed from the list other than the one instance of the model#(s) being revised.

For further clarification when stating:

Jenovee:

The **filename **only gets wiped when the method is like I'm adding a new product.

the term filename refers to the product name correct? And that is the only data that the code removes or unexpectedly modifies in this scenario?

mc12345678:

This is a process different than tested... Seems that if the model# is known, it could be just as easily searched for as compared to retyped, unless I am missing something... Will still look at the process to see why "adding" the product anew in the list has a different affect than modifying the item in the list. Would almost suggest in this scenario that all other line records be removed from the list other than the one instance of the model#(s) being revised.

Yes, it would be error-free doing it by search and edit method. The reason I am doing it this way is because I am trying to sync my quantities with those of a dropshipper. I would have to manually search for every product to edit, which would take hours. But this way, I can simply import all the data within a few minutes. Even products I don't carry can be imported without sorting, since EP will simply ignore it with: "SKIPPED! - Model: CGG3333333333 - No category provided for this new product"

Since there is no dropshipper module that I can find, this is the easiest and fastest method I currently see.

mc12345678:

For further clarification when stating:

the term filename refers to the product name correct? And that is the only data that the code removes or unexpectedly modifies in this scenario?

Yes, I'm sorry. I was typing faster than I was thinking. I meant to say the product name; and only the product name.

Jenovee:

Yes, it would be error-free doing it by search and edit method. The reason I am doing it this way is because I am trying to sync my quantities with those of a dropshipper. I would have to manually search for every product to edit, which would take hours. But this way, I can simply import all the data within a few minutes. Even products I don't carry can be imported without sorting, since EP will simply ignore it with: "SKIPPED! - Model: CGG3333333333 - No category provided for this new product"

Since there is no dropshipper module that I can find, this is the easiest and fastest method I currently see.

Yes, I'm sorry. I was typing faster than I was thinking. I meant to say the product name; and only the product name.

No problem, just double checking...

So back to my earlier suggestion, how do things work if the file is "blank" of products listed and just the dropshipper's data populates it? (Headings still in place and assuming that the dropshipper's data has the model listed once only. If listed more than once, could setup a quick calc column to show a duplicate and then delete the desired duplicate before saving for uploading.)

mc12345678:

No problem, just double checking...

So back to my earlier suggestion, how do things work if the file is "blank" of products listed and just the dropshipper's data populates it? (Headings still in place and assuming that the dropshipper's data has the model listed once only. If listed more than once, could setup a quick calc column to show a duplicate and then delete the desired duplicate before saving for uploading.)

Ahhhhhh, I was able to try it just now. I did everything exactly the same, but then I deleted ALL my products. I imported just 1 line of data. Everything seems good! The item name is fine, and all other data seems intact.

I will keep testing it, but this method seems to work. Thank you MC. :smile:

mc12345678:

This plugin is a database related plugin and will export the path to the base image (please read the applicable FAQ for additional images). It does not export the actual image itself. It is generally considered that ftp be used to export the file that is the image (or "right" clicking the image and saving it when it is displayed onscreen).

Thank you

Hi mc12345678

so will the code you posted fix the v_options_values_price_w issue? or is that an added feature of an update in the works?

$row2 = ($ep_uses_mysqli ? mysqli_fetch_array($result2) : mysql_fetch_array($result2));

HugoStiglitz:

Hi mc12345678

so will the code you posted fix the v_options_values_price_w issue? or is that an added feature of an update in the works?

$row2 = ($ep_uses_mysqli ? mysqli_fetch_array($result2) : mysql_fetch_array($result2));

No, unfortunately the posted fix does not address the field that is in question.

Perhaps I could get a little help based on the following:
To ensure that the new field is incorporated only for those that have the applicable plugin installed, what "flag" on the right side of the screen indicates "on" or "yes" when only the applicable plugin is installed?
If the answer is none, then I have a clear path forward.
If something specific, then need to account for that "other" plugin and this one.
Verification on my side to identify requires me to install the. Plugin upfront to correct (a bit of a time issue involved and I'd like to provide a resolution rapidly)

Jeking, able to identify this?

unfortunately I'm not sure what you mean.
however I can provide access to the admin & ftp of an installation that has the plugins installed.

HugoStiglitz:

unfortunately I'm not sure what you mean.
however I can provide access to the admin & ftp of an installation that has the plugins installed.

I would think that simply having access to the EP4 application under tools would be sufficient for what I need, or a screen shot of the same without divulging your admin directory.

is this what you are after?

Attachment #15117

HugoStiglitz:

Yup. Thanks.

It'll be a new section to add for support. Clear path as identified above. :)

I just tried the attribute pricing for the first time. My results are different than Hugo's. I had existing product with attribute prices that I just created. I exported the file to see how it all looked. I also entered attribute pricing for another new product I had just created. The new prices updated into catalog.

But, the prices are all prefixed with a "0". In my drop-down list, instead of "$2.50", it's "[email protected]". And this is not just for the new prices I entered. The existing prices on the product that already had prices before the export are also changed to "0$x.xx" now.

Since this is different than Hugo's issue, I'm just mentioning it in case the fix is different.

Okay, I just went back to figure out what happened. Since this is my first time with attribute pricing, I now see what happened. Importing the file has somehow changed the prefix from "+" to "0". Now that I can explain it better, it should be easier to understand. :)

Jenovee:

Okay, I just went back to figure out what happened. Since this is my first time with attribute pricing, I now see what happened. Importing the file has somehow changed the prefix from "+" to "0". Now that I can explain it better, it should be easier to understand. :)

To try to help as quickly as possible before identifying a more global fix, does your export file have a zero in the field of the prefix (original file) or is it blank?

mc12345678:

To try to help as quickly as possible before identifying a more global fix, does your export file have a zero in the field of the prefix (original file) or is it blank?

Yes, it seems to be converting the prefix to "0" on export. Some items are blank, while others have zeros. I can't tell why though.

Jenovee:

Yes, it seems to be converting the prefix to "0" on export. Some items are blank, while others have zeros. I can't tell why though.

If the zero is appearing on export (to the csv file from ZC) then the zero was already in the database. Overall, Zc is basically supposed to ignore any different character if it is not a minus basically. Anything other than a minus in a default install I thought it was supposed to display as a +. Maybe it is process as a plus but display whatever is entered. Anyways, to fix, from within your editor (ideally Open Office) simply change and save that column with either blank if nothing is to prefix the display or the appropriate symbol to display (+, -, etc...)

Should fix your issue, then could export again to see if it remains as input.

mc12345678:

If the zero is appearing on export (to the csv file from ZC) then the zero was already in the database. Overall, Zc is basically supposed to ignore any different character if it is not a minus basically. Anything other than a minus in a default install I thought it was supposed to display as a +. Maybe it is process as a plus but display whatever is entered. Anyways, to fix, from within your editor (ideally Open Office) simply change and save that column with either blank if nothing is to prefix the display or the appropriate symbol to display (+, -, etc...)

Should fix your issue, then could export again to see if it remains as input.

Well, I just restored my database to how it was before I decided to mess with attribute pricing. Comparing the exported file to what was in my catalog, I can see that it's changing values. I have products with size/color attributes, but no prices attached to them. I can see a blank field for attrib price when in admin panel, and it has the "+" prefix. On export, that plus gets changed to zero. I manually changed one of the changed zeros back to "+" and exported again. It changed back to zero on export. It's changing values rather than ignoring.