Child pages
  • [in-commerce] Comma in option value breaks option saving
Skip to end of metadata
Go to start of metadata

Imported From:

Internally product option values are separated by "," (comma). When one of option values contains comma, like "3,5 ml" then that one value is saved as two separate options and breaks down all option-related stuff. To solve this option escaping problem once and for all I propose to use "inp_edit_minput" control for option value input and store all that as one xml record (fields: Values, Prices, PriceTypes).


  1. Also I propose to merge options and options combination together in one
    table. This will allow to keep stock information even if we only have one
    option and we don't want to create option combinations for that purpose.

  2. Hello Alex,

    while you are talking about product options and the way they are
    stored in DB, should it be the right time to ask for a complete
    product export function, including all product options?


  3. Why not, but export problem is more complicated, then it seems at first.
    What you are asking is to export all/some data from related tables
    associated with exported products. Problem is that for now one record in CSV
    file means one product, but for example if we product has 5 options and each
    option has it's own set of fields, like PriceTypes, Values and so on then I
    don't really know how should we store it in CSV format. Same with product
    images and so on.

    The way, when all related table data is mixed into huge XML and stored in
    one table in one new column format doesn't seem to comfortable. Also storing
    each related record on separate record with same product info on each line
    also doesn't look good.

    The only way how I imagine that is to map database structure to XML file and
    export/import from XML format. In this case why bother with CSV at all, we
    could dump database directly from phpMyAdmin.

  4. Hi mates,

    I have a suggestion here - why can't we list as many options we have in each
    new row along with product data, Example:

    ProductName, Descrioption, Price...., HASOptions = 1, Option1, cost,
    ProductName, Descrioption, Price...., HASOptions = 1, Option2, cost,
    ProductName, Descrioption, Price...., HASOptions = 0

    When Importing we'll be looking and processing Products that have options

    What you think?


  5. And when we need images, then what?

    Total record count: products count * image count per product * option count
    per product and so on. And when we have same field in different tables?

  6. I would try to place all Product images in 1 field in some special format

    ProductName, Descrioption, Price...., HASOptions = 1, Option1, cost,
    OptionSKU...., (Name|Alt|Path|Path2)||(Name|Alt|Path|Path2)


    ProductName, Descrioption, Price...., HASOptions = 1, Option1, cost,
    OptionSKU...., Image_1, Image_2, Image_3

    I think we can work it out don't you think?

    Meaning we can learn list and understand Images as 1 field or multiple
    Fields not limiting on number of them, but simply adding them as last

    With best regards,

    Dmitry V. Andrejev

  7. You don't problem in perspective. We have a set of subitems with various
    fields. Each of category item types (links, articles) have various subitems,
    that other category item types doesn't have. We should develop format, that
    should support all variants of data and even multiline values, that could
    contain your "|" separator.

    It should be easy configurable and easy usable on import/export screen and
    understandable in excel.

  8. Alright I just thought we are talking about Options for Products.

    Let start listing some basic fields or sub-items that we might have so
    we know what we are going to deal with.

    Alex would you please start?

    With best regards,

    Dmitry V. Andrejev

  9. I'm really glad to see that, despite the fact I've moved the
    discussion on another subject, we are moving ahead very fast on things
    that are very important.
    For instance, all customers working with more than a hundred of
    product will need a good import/export tool.

    Alexander, your idea to use XML format seems to me the best
    alternative, as this format is -really- open source, and open to users
    understanding, that is the top (we have a proverb saying "something
    well done should be understoud easily").
    About images, just adding the relative path would be perfect, this way
    a simple copy of XML and a images directory would perform a complete
    backup of all catalog.

    Finally, working with XML could also open the road to the next major
    step I imagine, taking the step on all other solutions around: a java
    client ! Even if we are not going to develop it tomorrow, thinking a
    long time ahead couldn't be bad, isn't it?


  10. Don't really understand how XML product export is related to java client

  11. Maybe you meant JavaScript, but that's two different programming languages
    and why javascript need to use product import.

  12. Well, I was thinking if we use XML to import/export file, this could
    be easier for an external authorized program to import/export data,
    and I've took this opportunity to talk about another very old idea:
    having a local client, platform-independant (that's why I think about
    Java), which could be use for admin, including importing/exporting big
    files in a folder, for example...

    Anyway, XML seems more serious than old-fashion CSV, as we will
    immediatly wipe out the problems linked to coma, semi-colons, and so
    on, as every fields are surrounded by a tag... isn't it?

  13. Hi Phil,

    Have you ever edited things in XML text editor?

    The power of CSV is that you can edit files in Excel or other editor
    while XML is more complex...

    It's just you don't think it will solve the problem - otherwise we and
    everyone would do this from the day one.

    In some cases you need to Edit data in the editor - do you agree with me?

    With best regards,

    Dmitry V. Andrejev

  14. Hi Dmitry,

    to be honest, I edit both CSV and XML with PSPad, because I can
    perform fast text replacement, but I agree that CSV is easier to open,
    but no so easy for importing/exporting.

    I've spend a lot of time before, trying to surround fields with " or
    ', because of comma into fields, and after this, if any text contains
    a " or a ' inside, import fails or miss some lines... and you can have
    the problem in importing a file you have just exported, and then you
    need to try differents fields surrounders, export again and trying to
    import... very boring and time consuming.

    I'd better say: CSV is probably easy, but actual import tool is really
    boring to use, as we never have any report when it doesn't work, and
    all setup is lost after each operatuion (we are discussing about that
    in another post).

    I've used in-portal in real situations, and I wanted to explain why I
    push on XML, based on my past experiences.


    2010/3/4 Dmitry V. Andrejev <>:

  15. Here is one more advantage to csv format: it can be used to import very
    large amounts of data, since we only need to read line of file we are
    parsing and not all file to import it. From this point XML format isn't very
    useful, since we need to read whole XML file, which maybe event 2GB long to
    see where we are on current import progress step.

    On Fri, Mar 5, 2010 at 1:16 AM, Phil ..:: ::.. <

  16. Another point for improving CSV export/import!

    I say we think about XML later once CSV does what we need.


  17. well, let's face my opinion: I had bad experiences before, using CSV,
    but if it works like it should, i.e. being able to export all kind of
    items, with all options and customs field, and are correclty embracing
    datas in a way that text contents couldn't break the file, I'd of
    course prefer a lighter file format... but is it possible?
    I have the case actually, I need to update a v4 to v5, and I don't
    know where to start from, as I can't rely on export functions, which
    doesn't handle product options...

    2010/3/24 Alexander Obuhovich <>:

  18. Why need to import/export, just upgrade using installer as any other
    in-portal site.

    On Wed, Mar 24, 2010 at 6:32 PM, Phil ..:: ::.. <

  19. I'll try it of course, but the problem remain the same, if you need,
    for any reason, to do a "clean install", there's no way to backup your
    product catalog to re-import it afterwards...

    2010/3/24 Alexander Obuhovich <>:

  20. Manual export of tables will work in case if that table structure won't be
    changed during upgrade.

    On Wed, Mar 24, 2010 at 7:27 PM, Phil ..:: ::.. <

  21. ok, thanks for info

    2010/3/24 Alexander Obuhovich <>:

  22. We've went offtopic on this, but described bug is still there even in latest In-Commerce 5.2.2-B1 version.