countrycharm:

Does it even need that function to operate? If not what needs committing out for it to work.

I think someone else commented out the line(s) that made the call. My understanding for the reason that is used is to ensure/force all data to be UTF-8 encoded. Been a while since I have looked at that area, but it made sense to me and I didn't want to modify what worked, especially if it is/was on my side that was not setup to handle the calls made.

mc12345678:

What is the source of that table?

Is the error received still the same when you are now getting a blank page? I seem to recall having to enable something else, but can't remember what it is/was.

The error message you are now receiving should shed some light. If it is the same message then probably something else was needed to implement mbstring.

That information shows when I pull up my server info. No I'm not getting anymore error messages for some reason. All I'm getting is well you know

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

countrycharm:

That information shows when I pull up my server info. No I'm not getting anymore error messages for some reason. All I'm getting is well you know

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Go figure, now all the sudden it started working. Strange stuff ...... :)

So, for the first thing, am I correct you entered just: products_id in the User defined fields entry of the configuration->Easy Populate 4. Not v_products_id. The code will export a products field that is provided in that user defined fields entry.

So something is wrong with that setup (not the program)
That's correct, my entry was products_id on that field, nothing else was touched.

3. So, you do not have any products that have a model number that starts with 001- correct?
   Not correct. All the items started by 001- (I really don't understand why he did that, but I'm sure if there's any other way for him to create models it will be ok, since he's only using them to use EP, nothing else.

ideasgirl:

That's correct, my entry was products_id on that field, nothing else was touched.

Not correct. All the items started by 001- (I really don't understand why he did that, but I'm sure if there's any other way for him to create models it will be ok, since he's only using them to use EP, nothing else.

Okay, thank you for clarifying. I'll create something that uses a different prefix but will include the product I'd.

Odd, that the products_id did not export because it is designed to do so if included as a custom user field. Will look to see if there is code to prevent it's export, which I would consider unusual when the field is specifically a custom field. Understandable when/if used internally..

It should export as v_products_id if it did get exported.

ideasgirl:

That's correct, my entry was products_id on that field, nothing else was touched.

Not correct. All the items started by 001- (I really don't understand why he did that, but I'm sure if there's any other way for him to create models it will be ok, since he's only using them to use EP, nothing else.

Okay, so below is a SQL statement that when used through the ZC Install SQL Patches area will update all blank model numbers to start with the string provided in the first part of the concat function (in this case 002-). Now, it hasn't been written to prefix zeros so that second part of the model number is a uniform length. That's a separate thing to address.

UPDATE products SET products_model=concat('002-', products_id) WHERE products_model='';

The end of that string is two apostrophes not a single quote.

If the above is run through mySQLAdmin, then the table prefix would need to be added to the 'products' statement.

For those reading this in the future. The prefix 002- was chosen because no other existing model # began with 002- and therefore no duplication would result.

Great! Is there any reason as to why not use 001- ?

ideasgirl:

Great! Is there any reason as to why not use 001- ?

If the store owner mapped 001- as consecutive entries instead of in accordance with the product_id (or if mistyped when entering it by product_id) then the possibility of duplication may exist and then, well all sorts of unexpected things start happening if the duplication was not planned.

If you find that you would have no problem with the data if it is prepended with 001- then feel free to change it. Also, there are ways to force formatting with 0's prepended to the products_id, but also if the model # is only being used for EP4, then there really isn't a need to do that. (Ie., not displayed with the product(s), not used for any sort of tracking, etc...).

It's all in planning and future use. Later, a similar SQL update query could be run to modify/replace the '002-'s with 001-, but I am trying to provide a generic resolution that is knowingly guaranteed not to cause an immediate problem. :)

If the store owner mapped 001- as consecutive entries instead of in accordance with the product_id (or if mistyped when entering it by product_id) then the possibility of duplication may exist and then, well all sorts of unexpected things start happening if the duplication was not planned.
Yes, it was consecutive entries on the spreadsheet (nothing to do with product_id).

I already ran it with both 001, and 002, didn't see anything unusual the only odd thing that on products all display if i sorted by model number for example 001-101, then 001-1001, 001-1019, 001-102, 001-1020... that kind of sorting, but it will do the same in both scenarios.

I will use 002 just to be safe.

I couldn't edit my post to include the screenshot I forgot to include:
http://imageshack.com/a/img823/9546/llna.jpg

ideasgirl:

Yes, it was consecutive entries on the spreadsheet (nothing to do with product_id).

I already ran it with both 001, and 002, didn't see anything unusual the only odd thing that on products all display if i sorted by model number for example 001-101, then 001-1001, 001-1019, 001-102, 001-1020... that kind of sorting, but it will do the same in both scenarios.

I will use 002 just to be safe.

So, if all of the entries had 4 digits after the - and these now only have three, you could use 002-0 as the prefix and that would put them in a somehat numerical order. You could also get real picky about it, and if want all items to have 4 digits after the dash, could imploy the query with an additional catch on the where part:

So here the concat would have '002-000'
Where products_model = '' and products_id < 10;
And then have 002-00
Where products_model = '' and products_id < 100;
And then have 002-0
Where products_model = '' and products_id < 1000;
And then have 002-
Where products_model = '' and products_id < 10000;
(Thankfully no product has products_id = 0 otherwise would need one more. But thatthe "lazy" way to apply the formatting.

I will keep it simple, he's not picky about it, we just want to solve the issue, and he can take it from there on when entering products.

Thanks! You have been great help. :smartalec:

Ok, BIG PROBLEM.

I did it as planned. Worked like a charm, here's where it failed:
-I did a new export to propagate new site. = FINE AND DANDY, everything worked just right.
-I did another export of attributes to upload and import to new site. = everything turn to this:
SKIPPED! - Attribute Entry on Model: 002-12 - Not Found!
with all the model numbers WRONG.

I checked the spreadsheet and there it was, all the numbers where changed on the spreadsheet... WHY?
Instead of 002-100, 002-1000, 002-1002.... they are 002-12, 002-13, 002-14. And even there's a model 002-1009, the system is saying there's not. :shocking:

Final report on that:
Updated records: 0
New Imported records: 0
Errors Detected: 3439
Warnings Detected: 0
Memory Usage: 4546612
Memory Peak: 4755516
Execution Time: 0.787619829178 seconds.

NOW WHAT? :yuck:

ideasgirl:

Ok, BIG PROBLEM.

I did it as planned. Worked like a charm, here's where it failed:
-I did a new export to propagate new site. = FINE AND DANDY, everything worked just right.
-I did another export of attributes to upload and import to new site. = everything turn to this:
SKIPPED! - Attribute Entry on Model: 002-12 - Not Found!
with all the model numbers WRONG.

I checked the spreadsheet and there it was, all the numbers where changed on the spreadsheet... WHY?
Instead of 002-100, 002-1000, 002-1002.... they are 002-12, 002-13, 002-14. And even there's a model 002-1009, the system is saying there's not. :shocking:

Final report on that:
Updated records: 0
New Imported records: 0
Errors Detected: 3439
Warnings Detected: 0
Memory Usage: 4546612
Memory Peak: 4755516
Execution Time: 0.787619829178 seconds.

NOW WHAT? :yuck:

Ok, deep breath. Please slow down and provide more detail.

File names, expected action to be done with that file. (Attribute detailed upload, download, etc.)
Regarding the "change" of model numbers, considering what was explained as likely duplicate entries of content with different products_id's are you saying that no where in the data is the model numbers that you had before when exporting? That would occur if the where statement was omitted in the update query which would then make every model# begin with 002- not just the ones that were previously blank.

Also, browser cache/cookies refreshed?

Not understanding very well your questions but I will try to be accurate...

are you saying that no where in the data is the model numbers that you had before when exporting?
Yes, like I posted... on the spreadsheet AND on the site when you are in frontend there are many of those model numbers, but system is not recognizing those numbers. Like for example: model 002-1009 is there, but system is saying there's no product with model number 002-1009.

The previous upload I did with the other spreadsheet where I discovered the issue this morning is gone because I restored the database afterwards with the backup I had made before the import, so there are nowhere on the db.

Would this answer your questions?

ideasgirl:

Not understanding very well your questions but I will try to be accurate...

Yes, like I posted... on the spreadsheet AND on the site when you are in frontend there are many of those model numbers, but system is not recognizing those numbers. Like for example: model 002-1009 is there, but system is saying there's no product with model number 002-1009.

The previous upload I did with the other spreadsheet where I discovered the issue this morning is gone because I restored the database afterwards with the backup I had made before the import, so there are nowhere on the db.

Would this answer your questions?

Unfortunately, no it adds more questions.

Please in order of time identify what you have done. At some point today a backup of something was made. At some point something was restored (what was the something a EP4 file, the complete database?)

When you say frontend, are you referring to the admin panel or in the store?
I thought the model numbers were not used for anything specific, so how can one search for the model as a customer to the store?

There may be other issues with the data if previously a search was successful, but now not.

What I was referring to was, when you download/export the database to a spreadsheet are the original model numbers still in the spreadsheet?

mc12345678:

Unfortunately, no it adds more questions.

Please in order of time identify what you have done. At some point today a backup of something was made. At some point something was restored (what was the something a EP4 file, the complete database?)

When you say frontend, are you referring to the admin panel or in the store?
I thought the model numbers were not used for anything specific, so how can one search for the model as a customer to the store?

There may be other issues with the data if previously a search was successful, but now not.

What I was referring to was, when you download/export the database to a spreadsheet are the original model numbers still in the spreadsheet?

The other question I was trying to get an answer to was: what file were you trying to upload into the database? What did you expect to change/be doing?

So did you create an attribute detailed file for one or more products, but had not created an attributes basic file? So therefore when you used the attributes detailed file to "modify" attribute data EP4 created an "error"?

From what little has been provided it seems that the product(s) (with new model numbers) didn't have the attributes applied to them that were tried when the "error" message appeared.

To understand clearer explanations of what was done and what was observed need to be provided. Preferably in order of time. Also take your time in explaining. If I was standing over your shoulder when this all happened, I wouldn't be asking a single question, because I would have watched exactly what was done. No one here had that luxury, so we need to hear from you what is going on, how it is identified, what was expected to be seen/happen, etc... As said, take a deep breath, relax, and tell the story from beginning to end.

At some point something was restored (what was the something a EP4 file, the complete database?
Actually I didn't with the current site, I did a backup last night but this morning (after being notified by customer about duplication) what I did was used same spreadsheet (with new model numbers) and use the DELETE feature of EP.

Then after that, all my tests have been using the backup/restore using MyBackupSql module.

When you say frontend, are you referring to the admin panel or in the store?
Store.

I thought the model numbers were not used for anything specific, so how can one search for the model as a customer to the store.
They actually aren't, I'm doing the search because the system is saying they don't exist to do the attributes.

What I was referring to was, when you download/export the database to a spreadsheet are the original model numbers still in the spreadsheet?
When you say original, do you mean the ones that were done by the patch you gave me? If so, yes, but there are others that weren't present on original spreadsheet, but now that I think it's maybe because the original spreadsheet only has the ACTIVE products and attributes has them all.... maybe?

Still doesn't explains why is rejecting the ones that are active.

Yes, you are right! I didn't do the simple attributes first, I did the detailed one... so I guess that's the bad step?

ideasgirl:

Actually I didn't with the current site, I did a backup last night but this morning (after being notified by customer about duplication) what I did was used same spreadsheet (with new model numbers) and use the DELETE feature of EP.

Then after that, all my tests have been using the backup/restore using MyBackupSql module.

Store.

They actually aren't, I'm doing the search because the system is saying they don't exist to do the attributes.

When you say original, do you mean the ones that were done by the patch you gave me? If so, yes, but there are others that weren't present on original spreadsheet, but now that I think it's maybe because the original spreadsheet only has the ACTIVE products and attributes has them all.... maybe?

Still doesn't explains why is rejecting the ones that are active.

---

Yes, you are right! I didn't do the simple attributes first, I did the detailed one... so I guess that's the bad step?

Yes that is the step in the process that was missed. Basic import to create the link of the attribute to the product, then a detailed attribute import to link the data specific to that attribute (price, and other information).

And although I possibly still have more questions, if you are able to at least able to move forward with the next desired step, then you should be able to sort out the other issues on your own.

When dealing with attributes (and other options) a "basic" import must be done/or have been done before a detailed import can be done. This is true even when using ZC for one product at a time... Think about the process.. EP4 just does it a little quicker and with several things at once...

So, a product gets added with some basic things, then a bunch of other data gets entered... Then Option Names are created, option values are assigned to option names, then option name/value combinations are tied to a product, then all of the details of each attribute are populated, one attribute at a time... Well, EP4 does this in two steps: the Basic attributes will create new option names if necessary, and new option values, but then will assign the combination to the product. The detailed attribute import then populates all other information that relates to the product's attribute. If the first step hasn't been done either in ZC admin ("slow way") or in EP4 (or similar software) through the basic import, then it must be done...

This process has been described before in this thread, but is provided again to hopefully help the next individual checking out this plugin.

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.