EasyPopulate 4.0 Support Thread

mc12345678 I just wanted to say thank you again for all the help and support. The easy populate and the SBA module is working great together. Anyway thanks again......:smile:

ideasgirl:

Ok, I'm going step by step with new exports I just made. I ran your patch, and made new backup of that, and new exports.

When I ran the products on new sites (complete product list) I notices few blue items what is not supposed to because everything should be green (new items).

When looking for those numbers in the database I see they are duplicated. So apparently the patch somehow didn't work to perfection because there are few items with same model number. To be exact: 2.

So, what is the model number for which the two are "the same"? Will provide an update SQL to correct that as well.. Though could create a new problem...

Still confused on how that could happen from the query that was provided if no products began with 002-, the SQL was run as provided to "prepend 002- to all items that did not have a model number", and that I think the table structure for products prevents the same products_id to be applied to two different entries. So, I can't see how two products could have the same model# after the query provided when a duplicate did not exist before the query provided and the above was true, but regardless, seems like could/need to reset the model #'s for those two items which can be done with a query similar to what was provided before, but specific to the items that are currently an issue.

Don't worry about it. Customer will do those 2 by hand, he doesn't mind.

I ran the Att Basic spreadsheet, and it went through just fine with those 2 items again in blue, but it's understandable and few red ones that are actually inactive on main product list, so that's also understandable.

What is not understandable is that when running the detailed att then everything when red. But even products that says there aren't on the inventory, they are.

The thing is that for some reason the main/first store is not displaying some products the same way the new one is; and also the sort order of product attribues aren't showing as they are supposed to on the new site. For example "Please select" not being first and by default.

Old Main Site: www.uogold.com/index.php?main_page=product_info&cPath=0&products_id=100

New Copy Site: www.uogold.com/uoresources.com/index.php?main_page=product_info&cPath=2_7&products_id=103

Both are supposed to have the PREV / NEXT buttons but the old site doesn't. Also look at the dropdown options on new site.

countrycharm:

mc12345678 I just wanted to say thank you again for all the help and support. The easy populate and the SBA module is working great together. Anyway thanks again......:smile:

Welcome... At some point I hope to add some more features to Easy Populate 4, though they may not initially be made available for free/public... I'm close, but continue to have some other things to touch up on in other areas between managed store, updates to plugins etc... Been trying to do a similar method of plugin combinations, such that if both are installed they work with each other, but if only one of the main plugin is installed then just won't see the extra feature available for when both are installed... Been slow going.. :)

ideasgirl:

Don't worry about it. Customer will do those 2 by hand, he doesn't mind.

I ran the Att Basic spreadsheet, and it went through just fine with those 2 items again in blue, but it's understandable and few red ones that are actually inactive on main product list, so that's also understandable.

What is not understandable is that when running the detailed att then everything when red. But even products that says there aren't on the inventory, they are.

The thing is that for some reason the main/first store is not displaying some products the same way the new one is; and also the sort order of product attribues aren't showing as they are supposed to on the new site. For example "Please select" not being first and by default.

Old Main Site: www.uogold.com/index.php?main_page=product_info&cPath=0&products_id=100

New Copy Site: www.uogold.com/uoresources.com/index.php?main_page=product_info&cPath=2_7&products_id=103

> 
> Both are supposed to have the PREV / NEXT buttons but the old site doesn't. Also look at the dropdown options on new site.

The missing Prev/Next is either a template issue or that someone turned off a setting; however, regarding the sort order, orders are applied in the detailed import.  After that, I would say that something else is messing with presenting the order.  Unfortunately there is nothing related to that particular issue that I can see from physically looking at the web page as a visitor, though it does seem like the div tag for the prev/next buttons is presented without anything beyond that.  Might be an issue with the applicable code, but I have not gone into typical code to figure it out.  Further differences could be a result of files in override directories on one site but not the other...

As for the red on detailed attributes import, well, could be any number of reasons again without further detailed information.  There could be a problem with the way the headings are entered (space before or after a heading entry)... Are you reusing an "old" file in anyway? Or are you downloading a new file, then changing the data inside of it?

You also realize that by having two products downloaded with the same model number that when the file is uploaded it will cause data overwrite so that (and I think that its the case) but both items will have the same data instead of being two unique items.  Sorry for taking so long to get this out, I thought I had already sent it. :)

The missing Prev/Next is either a template issue or that someone turned off a setting
I'm not sure of that because here you can see on original one the PREV/NEXT buttons are present, that only happens when a search is done:

www.uogold.com/index.php?main_page=product_info&cPath=11_10&products_id=100

You also realize that by having two products downloaded with the same model number that when the file is uploaded it will cause data overwrite so that (and I think that its the case) but both items will have the same data instead of being two unique items
Yes, I'm aware that there is only 1 item and is the latest on the spreadsheet because having same model it will override all the info of first item found with same model. But isn't it supposed to happen on the attributes as well? On the attributes the item will appear only once, so it's supposed to be attached to only one product, and not affect the import... right?

What I'm going to do is delete those 2 from the detailed att list and see how it goes. :unsure:

I was just informed that those 2 numbers that were repeated was because he had them twice on the listings.

Now I believe that the items that are not found on the imports they aren't really there. When you see the items on admin you will see them there, but you can't search for them, it's like they don't exist, but when you search for the others, there's no problem. Maybe this is an issue from the patch we did to number the models?

ideasgirl:

I was just informed that those 2 numbers that were repeated was because he had them twice on the listings.

Now I believe that the items that are not found on the imports they aren't really there. When you see the items on admin you will see them there, but you can't search for them, it's like they don't exist, but when you search for the others, there's no problem. Maybe this is an issue from the patch we did to number the models?

I'll say this... Identify an item that had a model # renumbered, that is not locatable in the "search" you have been doing, then go into the admin panel, edit that product, add a character to the end of the model number, save it, and tell me if that new model number is searchable. (Ideally, would like to be able to do that myself, but I can't seem to find where the problematic web address has been provided.) If the item can now be found using that model number, then the model renumbering was incomplete, if however, it still is not found, then there is other data that is incomplete to get a search result. I'm trying to look now to see what information must exist together in order to be provided as a search result.

My guess is that something else is wrong with the database... If ajeh were looking over this, I bet she could tell you straight off where to look. I know I have seen a thread in the forums that addresses something like this: product is listed in admin and store, but not found in a search.

ideasgirl:

I was just informed that those 2 numbers that were repeated was because he had them twice on the listings.

Now I believe that the items that are not found on the imports they aren't really there. When you see the items on admin you will see them there, but you can't search for them, it's like they don't exist, but when you search for the others, there's no problem. Maybe this is an issue from the patch we did to number the models?

mc12345678:

I'll say this... Identify an item that had a model # renumbered, that is not locatable in the "search" you have been doing, then go into the admin panel, edit that product, add a character to the end of the model number, save it, and tell me if that new model number is searchable. (Ideally, would like to be able to do that myself, but I can't seem to find where the problematic web address has been provided.) If the item can now be found using that model number, then the model renumbering was incomplete, if however, it still is not found, then there is other data that is incomplete to get a search result. I'm trying to look now to see what information must exist together in order to be provided as a search result.

My guess is that something else is wrong with the database... If ajeh were looking over this, I bet she could tell you straight off where to look. I know I have seen a thread in the forums that addresses something like this: product is listed in admin and store, but not found in a search.

Okay, I roughly completed my review of what is needed to perform a search, or at least an advanced search (which should offer more options than a basic search), anyways. It looks like there may need to be data present in a few other tables for a product to show up on a search. Here is the coded criteria to get something back from a search with some variables replaced with the ZC default table name (No extensions used):

FROM (products p
             LEFT JOIN manufacturers  m
             USING(manufacturers_id), products_description  pd, categories c, products_to_categories p2c )
             LEFT JOIN meta_tags_products_description mtpd
             ON mtpd.products_id= p2c.products_id
             AND mtpd.language_id = :languagesID";

There is a lot of data that can potentially be returned. The beginning of the statement is not included above, as it does not so directly affect whether something will be returned at all.

Now, I haven't gone to see how the above behaves, and I'm not always on the ball with the various SQL layouts, but if you would entertain the following ideas, perhaps can resolve the issue...

To me, it looked like the meta data needed to be present, but that seems wrong. Although I had run the model number update last night on my unmodeled data, I went ahead again today created a new generic product, didn't enter a model number, reviewed the meta_tags_product_description table and saw that there was an entry missing for my latest addition, performed a search on the product and it appeared... So, does not seem to be related to that.

Did a little searching, which you should have already done as well.. Check this link to see if it offers a solution for your problem: http://www.zen-cart.com/showthread.php?143258-search-not-working&p=816395#post816395

I know there are more recent similar articles because I was watching some of them unfold in the last month or so, but I couldn't tell you exactly where to find them and what specifically corrected their issue.

I haven't read your latest post but I just wanted to tell you that I did several searches and the pattern I see is that every model number where there are only 2 digits after the - are not searchable, not even if I add a number or a letter. So only the 002-### appear to be "real" model numbers, the others are like "non-existent" on the db.

I just noticed that I thought that was a pattern, but there are 3 digit models that are also not searchable. And the thing is that not only by model number, if you do a search for an item of those, you won't find it neither by doing a search by name.

I also noticed that all the model numbers after the - are the same as the product id. So I guess that was the patch work, right? I haven't seen anything not matching.

Thanks for all the help MC, :hug: don't worry anymore for this issue. Here's what I did to solve it and the resume of everything:

-The 2 items that were repeated models were actually repeated items (I learned this from customer so no biggy there), the items where there and the final total of items were 834.

-I noticed that after the basic att import all the attributes were in place, just not sorted.

-Since the detailed import failed few times (100%), I went to the attributes sorter feature and click on sort all attributes for all products, and that made the sort issue to disappear.

-Then last I exported a detailed att export, I downloaded it and did the "Please Select" changes on the spreadsheet and then uploaded without any issues.
-----------MAGIC-----------:wub:

On the new site all the numbers are searchable, so I will see if downloading and uploading the full list on the old one will solve that issue there.

I believe that the little db patch you gave me should be included on your ReadMe file for next version because that really would be a great piece of info to those that don't have/use model numbers on their items and want to use EP from then on.... If I got that piece of info 3 weeks ago, my customer wouldn't have gone for so much trouble and time creating those on the datasheet. It's GOLD info.

ideasgirl:

That's correct, my entry was products_id on that field, nothing else was touched.
.
Just to rectified this... Today I was installing EP on another site and when I was going to enter this user defined field, I noticed that (since I get the options from previous entered text there) when I entered before on the site we were working I entered producst_id and that's why it didn't do the effect wanted. STUPID ME to not put my eyes on details like this. :blink:

Well, so there's one less mystery of this whole dilemma.

ideasgirl:

Just to rectified this... Today I was installing EP on another site and when I was going to enter this user defined field, I noticed that (since I get the options from previous entered text there) when I entered before on the site we were working I entered producst_id and that's why it didn't do the effect wanted. STUPID ME to not put my eyes on details like this. :blink:

Well, so there's one less mystery of this whole dilemma.

Well, glad you figured that one out. Might have made things aa little easier to address, but also if memory serves, even if that had been obtained there was going to be a bit of training needed to use that piece of information (creating SQL statements to populate the model#. But glad the issue on your side was addressed/corrected.

I have added columns to the Product file. Does anyone know which Easy Populate files need to be changed or does anyone have any documentation regarding to the Easy Populate programs other that what is shipped in the release?

jodean:

I have added columns to the Product file. Does anyone know which Easy Populate files need to be changed or does anyone have any documentation regarding to the Easy Populate programs other that what is shipped in the release?

A couple pages back, there is a link provided I think it was by linuxguy2 the gives an overview of Easy Populate, but does not get into the how to use a specific version. Regarding your extra products table fields, enter the field names as they are in your database under the configuration option (when using EP4) as a user defined field. Do not add v_ to the prefix. Export and import of your file(s) will use that info where applicable. (Ie not on the attributes because attributes don't specifically use product data other than generic who am I type info.)

Otherwise, read through this forum for other "how-tos".

Hi, Mc12345678,

another bug found on EP 4.0.22 on ZC 1.51, utf-8 muliti-language site.

default language is english=1, and other is russian=2

all csv are opened and saved via openoffice, using coding utf-8

now problem is:
when upload and then import the data, any category title and meta title start with
russian letter NOT inserted into the SQL, but title starting with english letter is okay.

e.g.
"Главная example" will not inserted into sql
"example Главная" is okay

anyone else know such kind of problem? thank you.

Jerry5763837:

Hi, Mc12345678,

another bug found on EP 4.0.22 on ZC 1.51, utf-8 muliti-language site.

default language is english=1, and other is russian=2

all csv are opened and saved via openoffice, using coding utf-8

now problem is:
when upload and then import the data, any category title and meta title start with
russian letter NOT inserted into the SQL, but title starting with english letter is okay.

e.g.
"Главная example" will not inserted into sql
"example Главная" is okay

anyone else know such kind of problem? thank you.

Good right up. So, initial thoughts. I have seen that russian is one of those "unique" languages that must have additional coding to handle. I don't recall what specifically is necessary, but it may be that a utf8 comaptible type needs to be used. Would have to look at how other applications handle russian.

Perhaps the original programmer chadderuski also has input on this or others using russian or other languages.

Does this happen for all entries that begin with russian characters, or that specific letter? Any error messages other than the default not imported message? (Error logs either by EP4 or in ZC, etc?) Haven't looked through the forum, but is there any similar discussion? Problem occurs with doing first an export, then turning around and doing an import without opening file in OO?

Thanks for reporting this, hopefully a solution can be found relatively quickly.

Hi, MC,

appreicatied for your quick reply.

we tried many titles started with different russian letters, but all titles/meta tiles start with ANY russian letters
were NOT inserted into SQL. however, they can be inserted into SQL for
category descriptions, meta keywords, meta description.

problem like this:
for title "Главная example", only "example" can be inserted, but "Главная" will not inserted into sql
"example Главная" is okay

any other suggestions,MC? thank you.

Hi,MC,

reporte again.

Any Russian can be added through Admin area.
then we download category with meta.csv, without edit, then directly import thourhg EP4.0,
all goes well without and problem. russian tiles are there.

therefore can we say russian can NOT edit by openoffice?

Jerry5763837:

Hi,MC,

reporte again.

Any Russian can be added through Admin area.
then we download category with meta.csv, without edit, then directly import thourhg EP4.0,
all goes well without and problem. russian tiles are there.

therefore can we say russian can NOT edit by openoffice?

I wouldn't say that OO CAN'T be used, but that there is some sort of setting that must be modified to allow it to work. I think there are a few settings throughout this thread that address that issue. For some reason, though. It does appear that the current setup of OO is disturbing the data. I did think that there was something like importing while using a different encoding in OO then to export in UTF8. I have not looked for such a solution nor am I sure that so a thing would work. It is an idea without proof. Back up back up back up. :)