mc12345678:
Thanks for the advise. I looked into apsona shopadmin. From just a perusal, it seems rather easy, but I would have to look into it more. I'm down ill, can't sleep, probably call the doctor.
Silver
Printable View
mc12345678:
Thanks for the advise. I looked into apsona shopadmin. From just a perusal, it seems rather easy, but I would have to look into it more. I'm down ill, can't sleep, probably call the doctor.
Silver
Would you please provide the link to "partial functionality for stock by attributes".Quote:
Originally Posted by mc12345678
Is this functionality for kuroi's version of stock by attribute, recently updated by potteryhouse?
One of the things missing from this plugin is a consolidated list of "instructions". In my opinion (and it is just my own opinion) EP4 isn't difficult to use. The operator must only understand the sequence of actions necessary to fully build a product, the importance of the prefix to a file being uploaded, the character(s) necessary to properly import, and the actions that may be necessary to save a properly formatted CSV file. The second and third parts can be figured out by exporting multiple files potentially on different dates/times. The fourth part is described in this forum on page 1. The first part, well, think about how you build a product using the admin panel, and basically you follow the same sequence, but without timeouts and with the potential of multiple products being updated at once.Quote:
Originally Posted by SilverHD
Again, I do not have a comparison to go by, but the above has been the majority of questions related to EP4.
https://github com/mc12345678/EasyPopulate-4.0/archive/master.zip will download the file, otherwise if you are familiar with github, then remove archive/master.zip and you can navigate through github about the file.Quote:
Originally Posted by Kevin205
The functionality that was developed was a detailed import/export of SBA data from a SBA table that was designed like what I have installed. Unfortunately, I am not 100% sure which version e installed because I installed it really early on in my work with ZC about 2 years ago, but I do believe it was kuroi's that became robophungs. I know that I had separated the drop down functionality from the product so that I could use SBA in all situations as desired for the site I was working on. If the table is not setup the same as what I had (table name, numberof columns, and column names) then a SBA detailed export option will not appear in the user panel.
I had begun working on the basic import and export, but haven't worked on it since late last year. Partially because I was advised that an update would be coming that would almost completely revise the way things were coded, so I didn't want to introduce multiple differences from what was to become considered a ZC approved package. If too much is/was added in, then it would have to be reworked to fit in the new version, and would rather one product exist that has multiple functionality than to have multiple products that for the most part do the same thing with a little extra. As usual, use at your own risk and make backups before modifying your data/admin/store files.
Would this update be included in 1.5.2 version of ZC or a later version?Quote:
Originally Posted by mc12345678
I am not aware of EP4 (or a similar tool) being incorporated into ZC 1.5.2. If it is not currently in. The version available for review, then it is not expected to be incorporated as a default option. The update I am referriing to is an update to EP4. Supposedly there have been some significant rewrites that are to be packaged into a standard ZC approved package. As it stands this version was allowed to be linked from here early on and identified as Beta like product. As far as I've been able to tell, also, there doesn't seem to be anything about this version that would be an issue for ZC 1.5.2 or at least that would prevent operation, but as said there are other updates expected to the plugin.Quote:
Originally Posted by Kevin205
"ZC 1.5.1 AND EasyPopulate-4.0-master AND export_shipping_information_V1.3.2.1" out-of-the-box-install.
Tested on 2 different installations reversing the order of installing EP4 & export-shipping and EP4 fails on both installs. Tested both mods separately and they worked as advertised.
EP4 will export products OK but won't Import them. it goes through the motions without throwing any kind of error but doesn't import any products. Tried several different EP4 files just to be sure it wasn't the file. See results below.
Not sure if "EasyPopulate-4.0-master" or "export_shipping_information_V1.3.2.1" is the issue. In the past I had to install EP4 before I installed any other mods otherwise it wouldn't install so I tend to think it's EP4 causing the problem.
Green Bar At the top says: Success File Import Completed.
Import Results
Filename: Full-EP2014Feb09-165331.csv
Finished Processing Import File
Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 581144
Memory Peak: 591464
Execution Time: 0.000150918960571 seconds.
What spreadsheet program did you use for your data? Looks like the file was blank for the most part based on the report copied from the screen. Or at least that there was nothing that was to be changed. The green bar indicates that it successfully went from the beginningof the programming to the end without error. The fact that the data may or may not have lined up with something in the database doesn't mean that there is an error. It says how many things were modified, and in this case none.Quote:
Originally Posted by linuxguy2
So, what does it take to modify something? A difference of information for a line that has a model# associated with it.
What piece of info were you trying to change in the full file to verify/update the record?
There is an incompatibility between the two mods.
Tested both mods separately and they worked as advertised. Then tested on 2 different installations reversing the order of installing EP4 & export-shipping and EP4 fails on both installs.
My CSV file is solid as I have uploaded & installed it on a site without
"export_shipping_information_V1.3.2.1" installed and it works.
EP4 is a self installer and I don't know exactly which tables/rows/columns it modifies in the DB when you install it. If I had the raw *.sql file I might could figure something out.
My guess, and I'll take a look, is that export shipping installs a file that is loaded in after something associated with EP4 and therefore a variable needed by EP4 is overwritten feeding something incorrect to EP4. The fact that it sounds like the install occurs without error (review logs) and that the export continues to work that the autoinsall is not a problem, but there is a conflict in variable usage. Again, will take a look at this, though maybe a needle in a haystack dependingon what it is.Quote:
Originally Posted by linuxguy2
Okay, don't know what the issue is... Just installed the most recent version of export shipping information alongside of EP4, performed an export from EP4 using several of the export options, then turned around and imported them without issue... All items identified as being "updated", then modified the data for one of the entries, and confirmed that the piece of data was updated.Quote:
Originally Posted by mc12345678
Something else must be interferring, in addition there was very little that export shipping does/has in it. Didn't really see anything that would load while EP4 was loaded, so don't see what interference there is between the two. Is this the situation under which you experienced no updates? (Export file which essentially puts the CSV on the server, then without touching the file, trying to import it.) In that situation, what results are presented?
Thanks for the feedback,
Were you testing on a local test server or a hosted site?
This AM (on three completely different test installs) I'm getting some really strange behaviour when importing with EP4.
I'm going to go back and do a fresh ZC 1.5.1/EP4/SO install so I can document the exact steps to reproduce the failure.
Don't have all of the specs available at the moment, but yes local server, nothing special about it's setup. Software is 1.5.1,but for some reason the database is reporting 1.5.0 and I haven't gone to update/repair that part anytime recently. There are some data differences that I occasionally have to entertain, like entering a 0 instead of allowing a NULL, but that to me is minor and I get errors if I don't do that, not just blind acceptance of information.Quote:
Originally Posted by linuxguy2
Shouldn't really get too much interaction between EP4 and SO, as SO primarily touches the orders table not the products/products description tables. But yes generally good to start with something frsh when troubleshootinf odd behaviours.
When I started this round of testing 2 days ago I re-downloaded ZC1.5.1, export_shipping_information_V1.3.2.1 from the zc plugins area and EP4 master from your link on github.
This PM I tested on a completely different hosting service with the same failing results.
I remembered a while back I downloaded EP4 at github h t t p s://github.c o m/chaddro/EasyPopulate-4.0 which I downloaded a few minutes ago and overwrote the non working installation and BINGO!
It is now working.
SOOOO... I either got a corrupted download OR there is some subtle difference in the copy at h t t p s://github c o m/mc12345678/EasyPopulate-4.0/archive/master.zip
When I get a few I'm going to go back and compare the two sets of files.
Thanks,
I found it!!!
In the file easypopulate_4_import.php the copy at h t t p s://github c o m/mc12345678/EasyPopulate-4.0/archive/master.zip has the "Detailed Attributes Import" code beginning around line 252 which doesn't work on my installs.
Maybe because I had no attributes setup?
Ahh, yes the two different versions. I tested against the original version, not the one the I modified to partially support Stock By Attributes. In that version i added one subroutine that I tried to uniquely name so that unlikely to exist in another plugin, and to incorporate applicable escape code so that if additional plugin was not present the software would work as originally written. (Sans SBA)Quote:
Originally Posted by linuxguy2
Problem is, sounds like you installed the version modified to partially support SBA independent of the other program and had no problem (unless I am mistaken about that) with its functionality, but supposedly when both installed together there was a problem. My guess is that users that don't have SBA installed probably have a problem with the version I provided, although the goal was to provide the possibility of additional functionality, not to disable existing functionality.
There was one individual originally that was looking for that additional functionality and they indicated that it worked after it was developed/implemented. No one that didn't have SBA has till now stated they've had a problem. Will have to go back and verify that for those without SBA the "unnecessary" information is properly skipped. Until then I recommend to continue using chadderuski's version if SBA is not installed and if desired to try to add some functionality to EP4 with SBA installed, then can try the version slightly modified of chadderuski's version. Hopefully sometime soon he'll post the updated version that he's been working on.
I don't have the line number but there was a logic error for those that didn't have SBA installed. If you search for:Quote:
Originally Posted by mc12345678
and replace with:Code:if ( ( strtolower(substr($file['name'],0,15)) <> "categorymeta-ep") && ( strtolower(substr($file['name'],0,7)) <> "attrib-") && ( strtolower(substr($file['name'],0,4)) <> "sba-" && ep_4_SBA1Exists() == true)) { // temporary solution here... 12-06-2010
That version of Easy Populate should work for those that do not have SBA installed, and provide additional functional options if SBA is installed that meets the criteria searched for.Code:if ( ( strtolower(substr($file['name'],0,15)) <> "categorymeta-ep") && ( strtolower(substr($file['name'],0,7)) <> "attrib-") && ((ep_4_SBA1Exists() == true ? (strtolower(substr($file['name'],0,4)) <> "sba-") : true))) { // temporary solution here... 12-06-2010
I have looked and looked for a thread on changing these to true, but can't find anything. Any help will be appreciated.
Custom Products Fields
Product Short Descriptions: FALSE
Product Unit of Measure: FALSE
Product UPC Code: FALSE
Google Product Category: FALSE
Manufacturer's Suggested Retail Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE
Those "values" (true/false) are displayed as a result of a database check performed in the admin/easypopulate_4.php file using the function ep4_check_table_column in the function file.Quote:
Originally Posted by Skullman
Specific fields are searched in the applicable table, and if found then returns true. It appears those fields are included possibly to support another mod(s) made/created by chadderruski the individual I would call the developer of this plug-in.
The short description is captured/expected in the products description table, all of the rest are in the products table.
Some Place on github there is a detailed explantion by chadderruski.
Remove the spaces in h t t p s & c o m before applying this link......
h t t p s://github.c o m/chaddro/EasyPopulate-4.0
Thanks, helped me out
To assist others that may be following the thread, what helped and what additional information was found/where was it found?Quote:
Originally Posted by Skullman
Rat's, I can't find the link again but chaddro wrote and extreme explanation of EP4
Not exactly an exhaustive source about EP4; however, searching for UPS in this thread resulted in some of the useful related to that particular subject:Quote:
Originally Posted by linuxguy2
http://www.zen-cart.com/showthread.p...37#post1122937
http://www.zen-cart.com/showthread.p...63#post1104263
http://www.zen-cart.com/showthread.p...70#post1190870
Similar searches for the other items in the list may show how to create/add that functionality, etc...
Excel 2007 works for me but when I download I save my files as filename.csv.txt (or save & rename with the txt extension) then start Excel and open the file as (delimited, tab/comma) NEXT(at his point if you have any leading zeros set that column to TEXT or excel will truncate them) NEXT/FINISH then save as a somefile.xlsx file do my mods then save as a somefile.csv file and upload/import.
That has always worked for me. This method doesn't seem to let Excel mess with the formating
Sorry guy's, I was way off on the document.
It was by schoolboy and about EP 1.2.5.4 but I think a lot of it applies to EP4.
Anyhow here's the link to the wiki.
http://www.zen-cart.com/wiki/index.php/Easy_Populate
Somehow this got in the wrong threadQuote:
Originally Posted by linuxguy2
Hello,
I looked this under few different search words and didn't see anything similar, so my apologies if it has been discussed.
ZC v1.5.1
EP v4.0.21
Main intention to install the module is that customer created a new store but most of the items are going to be the same. So having more than 800 items he asked if it was possible to do it through a feed or copied into the new store. I suggested EP BUT his items didn't have model numbers. Since EP works with model numbers I told him to use the spreadsheet to create all those model numbers and then we could update his active store and propagate his new one.
The problem is that on the first store EP duplicated all the items, so he had the old ones without model numbers and all the same items duplicated with model numbers.
You would say, well, then delete all the old ones and stay with new ones, but majority of old ones have attributes, also the data of those products orders relation to inventory will be deleted. Without talking about the pain of going 1 by 1 deleting because since they don't have model numbers there's no way to change that data or better put insert the '9' for deleting them. :blink:
What should I do to import to those items that don't have model numbers? Does this issue has solution? :unsure:
I have uploaded easy populate on my test site and getting the same problem when going to admin/tools/easy populate a blank page when trying to install the configurations.Quote:
Originally Posted by karlh626
Running PHP Version: 5.5.7
Database: MySQL 5.5.35
Any ideas
A few addon's but none are causing this.
Blank page... Error log... (Typically)Quote:
Originally Posted by countrycharm
I have no issue with: PHP Version 5.5.0 and MySql 5.6.12
When you say trying to install the configurations, could you be a little clearer? Able to get to access Tools->Easy Populate 4, but once the page is displayed a selection is made and then a problem occurs? Is that correct?
Sorry about that, no I'm not able to access the page at all. When clicked on easy populate 4 link from tools I get a blank page. I don't get to the Easy Populate 4 page.Quote:
Originally Posted by mc12345678
Error log
PHP Fatal error: Call to undefined function mb_internal_encoding() in /home/<admin dir>/easypopulate_4.php on line 139
Okay, so the short answer to this, that I can think of is to get familiar with SQL commands.Quote:
Originally Posted by ideasgirl
So there are number of ways to go about fixing the situation that I can think of. And yes, while I read all of the above, I can't say that I have a single magic code answer to provide, but I do have a suggested process:
1. First of all, find a way to identify what it is you want to keep/want to not worry about. I would think that a full download would make that determination easier. (These items are active, these are not, these I remember as having attributes (which you could download also), etc...) EP4 does not prevent pulling the data out of the database just because it doesn't have model numbers. Now... It is also possible to pull the product id (if it is not already included in the datadump) through the user defined field(s) of the EP4 configuration. just enter the field name that appears in the products table (Sorry for not going back to reference the table at this point, but its either product_id or products_id). This information will help when you run SQL queries later on all of the data.
2. Okay, so the next thing that could be done is to use the spreadsheet and formulas to generate a SQLl command for the product to be able to update the model number for those that do not have one to something completely unique that won't be able to clash with any other existing product. This could be a combination of things like date, time, row number, etc... So basically, for each item as you look down the list, try to identify a field that has data in every row, where that data is different in each row (ie. product_id) and use it as your WHERE portion of your SQL command. Or if necessary the combination of two or more fields as long as they are uniquely combined (no two rows have the same combination of data), and in the end would use an UPDATE type command. However, may want to test the operation with a SELECT command.
3. Once you have created all of your UPDATE commands, then you can copy and paste them into the Install SQLPatches field from the Admin Tools. And voila, every product will have a model number. Alternatively, you could do a single SQL that would do an update on all products that do not have a model number to have one assigned to it based on whatever data would make that model number unique from any other existing model#.
The last would probably be the easiest/quickest, but would need to know/understand the existing model assignment so that the provided statement would not create a duplication.
All depends on your level of experience/familiarity. Unfortunately, EP4 doesn't currently have a "magically" assign model numbers on export option (yet)...
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.Quote:
Originally Posted by countrycharm
BTW, sorry, would find this setting/option in your php.ini file, where you have potentially listings of extension=Quote:
Originally Posted by mc12345678
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.
My cpanel didn't have mbstring extension active so I'm rebuilding my Easy::Apache profile now. I'll let you know if it worksQuote:
Originally Posted by mc12345678
After reading your post maybe 4 times :blink: I'm a bit dizzy (well, my mind is).
1st. Option = I didn't understand much because I went to configuration and updated the "User Defined Products Fields" to products_id and I created another export and there's no column for product id, so I'm lost there.
2nd. Option = I'm also lost there because I wouldn't know how to create that "magic" formula and since I don't have a product_id column there's a lot of repeated data (unless we can solve that).
3rd Opton = If we can solve the "unique" data column, I believe we can go there.
Last and best/easier/quickest Option = Customer created just consecutive numbers 001-001, 001-002, 001-003.....001-830.... and I'm sure he doesn't mind to have a better logic on that number. He just created it that way because the easiest and fastest way to do it without breaking his head about it.
Soooooooooooooo, what's next? :lookaroun
Quote:
Originally Posted by mc12345678
Yeah, kinda' expected the dizziness.. :)Quote:
Originally Posted by 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)
2. That's the getting used to SQL part that I was talking about.
3. So, you do not have any products that have a model number that starts with 001- correct?
Will provide an update SQL statement shortly. Need to go do something else for a few minutes...
OK this is what I have but I still get a blank page. I'm stumped.Quote:
Originally Posted by mc12345678
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
Does it even need that function to operate? If not what needs committing out for it to work.Quote:
Originally Posted by mc12345678
What is the source of that table?Quote:
Originally Posted by countrycharm
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.
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.Quote:
Originally Posted by 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 knowQuote:
Originally Posted by mc12345678
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 ...... :)Quote:
Originally Posted by countrycharm
That's correct, my entry was products_id on that field, nothing else was touched.Quote:
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)
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.Quote:
3. So, you do not have any products that have a model number that starts with 001- correct?
Okay, thank you for clarifying. I'll create something that uses a different prefix but will include the product I'd.Quote:
Originally Posted by ideasgirl
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.
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.Quote:
Originally Posted by ideasgirl
The end of that string is two apostrophes not a single quote.Code:
UPDATE products SET products_model=concat('002-', products_id) WHERE products_model='';
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- ?
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.Quote:
Originally Posted by ideasgirl
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. :)
Yes, it was consecutive entries on the spreadsheet (nothing to do with product_id).Quote:
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.
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
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:Quote:
Originally Posted by ideasgirl
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:
Ok, deep breath. Please slow down and provide more detail.Quote:
Originally Posted by ideasgirl
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...
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.Quote:
are you saying that no where in the data is the model numbers that you had before when exporting?
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.Quote:
Originally Posted by ideasgirl
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?Quote:
Originally Posted by mc12345678
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.
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.Quote:
At some point something was restored (what was the something a EP4 file, the complete database?
Then after that, all my tests have been using the backup/restore using MyBackupSql module.
Store.Quote:
When you say frontend, are you referring to the admin panel or in the store?
They actually aren't, I'm doing the search because the system is saying they don't exist to do the attributes.Quote:
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.
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?Quote:
What I was referring to was, when you download/export the database to a spreadsheet are the original model numbers still in the spreadsheet?
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).Quote:
Originally Posted by ideasgirl
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.
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:
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...Quote:
Originally Posted by ideasgirl
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.
Both are supposed to have the PREV / NEXT buttons but the old site doesn't. Also look at the dropdown options on new site.Code: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
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.. :)Quote:
Originally Posted by countrycharm
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...Quote:
Originally Posted by ideasgirl
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. :)
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:Quote:
The missing Prev/Next is either a template issue or that someone turned off a setting
Code:www.uogold.com/index.php?main_page=product_info&cPath=11_10&products_id=100
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?Quote:
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
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?
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.Quote:
Originally Posted by ideasgirl
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.
Quote:
Originally Posted by ideasgirl
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):Quote:
Originally Posted by mc12345678
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.Code: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";
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.p...395#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.
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:Quote:
Originally Posted by ideasgirl
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.Quote:
Originally Posted by ideasgirl
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.)Quote:
Originally Posted by jodean
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.
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.Quote:
Originally Posted by Jerry5763837
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?
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. :)Quote:
Originally Posted by Jerry5763837
Fyi, the patch identified at http://www.zen-cart.com/showthread.p...18#post1236718 is no longer required. Github has been updated with the patch.
This is applicable to the version forked from chadderruski. When he posts the new version he's been working on, the expectation is that features added will get incorporated through our joint effort. (Ie he may incorporate them,, I will or perhaps a third party. Goal is to continue to have a continuously functional product that has the features and capability desired/possible.)
I'm working on creating a CSV file to import into my new Zencart shop. I'm importing a little over 1K products so I need to make sure I automate as much as possible to save time on error debugging.
- I cannot find which version of EasyPopulate my web designer installed -- it is not on the Tools->Easy Populate page
I have also read the wiki, dated 2007 and cannot find my answers there
I'd like to know how important the time stamp is within the v_date_added field. I would like to retain my product by date order. My old ecommerce platform did not use a time stamp, only the date.
e.g. 1/12/2012
It looks like EasyPopulate wants something more akin to this:
1/12/2012 15:48
My question is can I leave off the time stamp? Will EasyPopulate be able to handle this? Or do I need to insert a time stamp into each entry.
- Second question is about single and double quotes. I've read that EasyPopulate is not happy with quotes. I currently have quote-less titles but my descriptions do have quotes, both single and double as well as a smattering of other special characters like accented chars and various forms of punctuation like commas, semicolons, etc. Does the quote-less restriction apply to the v_products_description_1 field too? What about commas and other forms of punctuation? If there are issues, is there an escape character (like \ in regex) that will work? Otherwise any advice on this?
I've got, as I've said, over 1K products and most of the descriptions are unique.
Thanks in advance.
The absence of the easy populate option from your tools menu option is probably related to your "upgrade" process. Older versions were installed differently than those in ZC 1.5.x. More than likely there is a file named easy_populate or similar in your admin directory, looking at the contents (header area) you should be able to identify the version number.if not, please address in a new thread.Quote:
Originally Posted by linniedarling
Regarding EP4, if you omit the column for date_added, EP4 will populate the column with the current time at least for new products. If it is included then it will use the provided date/time.
2. EP4 has a few configure settings to address handling characters such as qus, single quotes, etc and will run addslashes (php command) that will modify the "input" to address the concerns some/many of the concerns expressed. (Btw, the escape code is typically a backslash (\) before the character that would cause the problem; however, EP4 doesn't extra backslash, so if you wanted to import: my "name" is short, you wouldn't want to have it listed as my \"name\" is short in your description because the result would maintain the backslashes in the description that the customer would see.
Does EP4 handle quantity discounts?
Does EP4 handle custom product fields? I have Numinix Product Fields installed and need to be able to update this info via EP4.
Not sure what you mean by questioning if EP4 handles quantity discounts. Discounts are not applied to the product table, but a different table in general. What table or operation applies quantity discounts? Off the top of my head, there is nothing that is in the products table or attributes tables that apply that. So, if the product(s) can be setup (placed in a category or a designated manufacturer or something similar) then the answer would be yes as long as the discount is/can be applied to that designated group. Otherwise, would need more information.Quote:
Originally Posted by k1ra
Regarding custom product fields, yes, there is the ability to incorporate custom fields that are a part of the products table. These are entered into the configuration area of EP4 as the name of the field separated by commas for each additional field. Do not prepend a v_, just the field's name as it is provided/added to the product table.
I have a client whose products are available in quantities of 100,250,500,1000,2500 each at different prices. Currently these are setup with the Pricing Manager in Admin. I'm not sure that their current setup is the best way, but I kinda got dumped in the middle of what another person was working on.Quote:
Originally Posted by mc12345678
Thank you for explaining the custom fields. That sounds easy enough to figure out.
Well, I just applied a qty discount to an item on a local store, and well, it seems to me that that option is not a bad way to go.Quote:
Originally Posted by k1ra
I haven't gone to look at the fields associated with quantity discounts and what is exported using EP4, but if it isn't already, the products_discount_type field could be included in the export/import, which would allow manual revision of the type of discount to be applied; however, the actual product discount "multiplier" is in the products_discount_quantity table. Export/import of that would require additional coding; however, if a product already existed, updates of that product would be applied using the "rules" of the qty discount, so, if the discount is percentage off or money off, etc., then whatever new price is entered will have the same modification then as it did before.
In that regards EP4 does "handle" quantity discounts, at least not have a problem because they are applied, but it doesn't currently apply changes to or modify quantity discount quantities.
Well I feel dumb.:blush: Apparently the 'Model/Price/Breaks' import/export option was exactly what I was after! :frusty:
It seems that the csv file for easy populate doesn't allow for importing the sort order of products, or am I missing something? Thanks for your imput.
It's been my experience a product sort order was not exported in my template.
In my original spread sheet I ordered my 750 products in ascending order and assigned Model numbers in an ascending order.
Now when I export all products it groups them by Category.
Not allowed and not included as a default in this case are two different things. It seems that sort order was not one of the fields that made it to the must have list; however, any field that is in the product table can be included for both import and export if added to the list of manual fields. (Somehwat discussed over past couple of pages). That said: if you know the title of the field as it is entered in the SQL database for products, then it can be entered on the admin page. Do not include a v_ that is seen in the export files.Quote:
Originally Posted by Jim Stone
Perhaps see the previous post? May that help a little?Quote:
Originally Posted by linuxguy2
Perhaps that makes two of us! :)Quote:
Originally Posted by k1ra
I can't say that I have dug into what that functionality offered. Glad that the neededresults were found and available.
hi
i have a bit problem whith easypopulate4
if a modified a products (model12345) in admin at new import/update zencart create a new product with another product id and with the same products_model, then I find in these cases with two products with the same products_model
how can I fix?
you can indicate whether this forum has already dealt with the problem?
thanks
send a screenshot del db , please note the record with red point....
tanks
I think I understand the problem; however, it is difficult to understand all that was written. The obvious fix is to restore the backup made before updating the database with EP4. The next thing: I am not sure how many data entries are involved. If one/two, then easy either go into the admin panel and delete the one that is extra, or set it's status to zero and modify the model# to something different.Quote:
Originally Posted by salvo72
If multiple products have the same model# or there are multiple "pairs" of products with the same model#, then one method to "repair" them is to delete all of the products with the duplicate model#, then change the model# in the upload file as necessary to have unique product model#s and upload them.
If the issue is that the same product description was uploaded for a different model# (model# changed), then I would suggest deleting the newer uploaded entry.
A few words of warning: deleting products from the database may affect other reports and relationships in ZC, especially if they are dependent on the products_id field in the products table.
EP4 can delete a product by model# by changing the status of the model# for the product to 9 instead of 0 or 1 when importing the data file.
Looking at the picture provided, I see two red dots, the the information on the two rows is not the same: different model#, different image, etc... But now that I have looked again, I see that the red dots are two products that have the same information as the two products at the top of the list.
So, there's the short-cut way identified above, of deleting all cases, then uploading the expected product, but realize short-cuts tend to lead to problems. And then there is a way that would preserve your existing relational data. This method would use SQL statements or mySQLAdmin as well as EP4 or at least EP4 data and is more along the way I would try to recover if a backup had not been made.
Identify all duplicate model#s,
Identify the products_id,
Using the above information, modify the model#s for the newest product to be "removed" to a unique model# possibly the next product to be added and change the status to 0.
When the new product is added, change all relevant information to the new product and update the status to 1.
I may do more than that depending on a review of the purchase history of the product being modified, but that's basically what I think I would do in that situation.
Basically, the only fix when using EP4 by itself, without editing the product, is to delete all cases of the model# (status 9) and then upload only the one entry desired. There is no "rename" option in EP4. Otherwise there are other tools that can help.
Hello,
I am new to the ZC Forum and have never posted before. Hoping this is the correct place and method.
Using EP4 and ZC 1.5.1. I loaded 1700 products simultaneously with success, (updated existing and added new), except for the length of the "v_products_name_1" field was too short for some of the products names. The field length is set at 128 according to the "warning" I received on the products "with issues" and the settings shown on the upper right hand part of the EP4 page. I need about 135 in length.
I have looked everywhere for a solution on the Forum. Closest suggestion found in the Forum was to go to phpMyAdmin in cPanel, then go to "products_description" and "change products_name" there to length of 135. Also go to orders_products and change products_names to 135. I did both and it made no difference. I don't see a name for "products_name_v1" - only for "products_name".
Can you please tell me exactly where to adjust this setting? I am not a developer and am without anyone right now to help me but can follow explicit instructions. I hope you can help me.
Thank you.
You came to the right area for this question (I think), good first post, keep up that type of description in future posts.Quote:
Originally Posted by pdevo
Either I or someone that already know the answer for the first part will get back to you with how to change the size/length of the field, but there is a part of your post that I don't fully understand, but may make an assumption.
When you say there is no product_name_v1, do you mean that when you look in mysqladmin at the table in question, all you see is product_name and you don't see product_name_1?
The extra _1 is a language "switch". The value of _1 means to assign the product_name to language1 (whatever thatmay be ie. English) a product_2 would be to assign the text to the second language. This way an update can be made to a product in multiple languages. If that has given you enough to make the desired change(s), then good.
Now as for the fulllength needed, should be able to use the spreadsheet program to identify the maximum length of your current products. Add a new column that calculates the length of the cell that has the name, then using a different cell, find the maximum in that column. After you have figured that out, if the new data is on the same spreadsheet as all of your other data, I recommend deleting it before saving/exporting to prepare for upload to urstore. Otherwise do the calculations on a different sheet, and don't have to worry about deleting it. Probably want to add a few characters to the total length so that don't have to increase again any time soon.
Didn't check the above, but hopefully my spacebar worked enough times to not be confusing. :) (cell phone used to type this.)
Hello and thank you so much for taking time to reply with your cell phone. :) I can read your post just fine.
You asked, "When you say there is no product_name_v1, do you mean that when you look in mysqladmin at the table in question, all you see is product_name and you don't see product_name_1?"
Yes, and sorry for the typo adding the "v" in front of the "1". There is no "product_name_1" I can find in the phpMyAdmin table. I learned through other posts about the "1" being a designator for language and did not know that until today. Thank you for explaining it is a "switch" and why it's there as I did not know that. I always just followed the example I had for the column heading and didn't question it. Now it makes sense.
I look forward to someone telling me how to change the length of the field with the "_1" at the end of products_name since what I did does not seem to have fixed it. There are several column headings on my EP4 template for updating and loading new products which have the "_1" suffix on them. So I don't know if there is something special I have to do with regard to making this change or if it should have worked the way I did it. Obviously, I am missing something.
Thank you for the suggestion of running a formula for length of cell. Very helpful and I should have thought of that. :) Much easier.
Thank you for your time.
Okay, so another confusing statement, but no matter... :)Quote:
Originally Posted by pdevo
So, each field that has an underscore followed by a number (ie. _1) is a field that can be found in the (prefix)products_description table. And again, the number corresponds to an installed language. No two stores are guaranteed to have the same sequence of languages. (Meaning a random selection of websites that have multiple languages may put Spanish 2nd, 1st, 6th, etc... Assuming that another language was applied/installed at some point before...
So, regarding the field length... That is controlled within your mySQLadmin editor...
If you open the mySQLAdmin editor (most likely through your cPanel), then open your store's database, then open the table (prefix)products_description, then while on the Structure tab, select the products_name field and edit it.
The next window should show the various information related to the field. For example the Length/Values... Update though for this type of data to have the maximum that you want to be able to enter.
Hope that helps.