EasyPopulate 4.0 Support Thread

[mc12345678]

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.

[countrycharm]

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 ...... :)

[ideasgirl]

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.

[mc12345678]

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.

[mc12345678]

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.

[ideasgirl]

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

[mc12345678]

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. :)

[ideasgirl]

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.

[ideasgirl]

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