EasyPopulate 4.0 Support Thread

[mc12345678]

Ahh yes, need to have the mbstring extension active in order to use that function... Typically active on a hosted site, and typically initially disabled on local computers... :) Go figure.

BTW, sorry, would find this setting/option in your php.ini file, where you have potentially listings of extension=

It may be prepopulated/but commented out with a semicolon at the beginning. On my local version I have
extension=php_mbstring.dll and then I have a comment after php_exif.dll that says that mbstring must precede the exif extension.. I don't know if I added that comment (found in my searches) or if it existed when in the setup, but thought I would share it. I don't use exif, but I had the comment there.

[countrycharm]

BTW, sorry, would find this setting/option in your php.ini file, where you have potentially listings of extension=

It may be prepopulated/but commented out with a semicolon at the beginning. On my local version I have
extension=php_mbstring.dll and then I have a comment after php_exif.dll that says that mbstring must precede the exif extension.. I don't know if I added that comment (found in my searches) or if it existed when in the setup, but thought I would share it. I don't use exif, but I had the comment there.

OK this is what I have but I still get a blank page. I'm stumped.

mbstring.detect_order	no value	no value
mbstring.encoding_translation	Off	Off
mbstring.func_overload	0	0
mbstring.http_input	pass	pass
mbstring.http_output	pass	pass
mbstring.http_output_conv_mimetypes	^(text/|application/xhtml\+xml)	^(text/|application/xhtml\+xml)
mbstring.internal_encoding	no value	no value
mbstring.language	neutral	neutral
mbstring.strict_detection	Off	Off
mbstring.substitute_character	no value	no value

[mc12345678]

OK this is what I have but I still get a blank page. I'm stumped.

mbstring.detect_order	no value	no value
mbstring.encoding_translation	Off	Off
mbstring.func_overload	0	0
mbstring.http_input	pass	pass
mbstring.http_output	pass	pass
mbstring.http_output_conv_mimetypes	^(text/|application/xhtml\+xml)	^(text/|application/xhtml\+xml)
mbstring.internal_encoding	no value	no value
mbstring.language	neutral	neutral
mbstring.strict_detection	Off	Off
mbstring.substitute_character	no value	no value

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.

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