Is it a bad idea to save to a custom order field on OSEL?

[Mike521w]

Hi all, another question regarding my shipping module.

I'd like to save some data to a custom order field, but I build that data on OSEL (before an order is actually placed). If I save it to the custom field, and then no order is placed, is that data 'orphaned' somehow?

Or is there a cleanup routine that eventually deletes custom order field data for non-existent orders?

[Scot - ScotsScripts.com]

Use custom basket fields. These are created on the fly with a custom basket field page item and/or api function calls. If you use custom basket fields with the exact same code as custom order fields, then the custom order fields will be automatically populated with the custom basket field data upon checkout. Just make sure those order fields exist.

[Mike521w]

awesome! Thanks Scot - ScotsScripts.com I didn't know it would auto-convert them, that's very useful

[Mike521w]

I'm having a small issue with this. I'm using the `Write_Basket` function, and it's adding an entry to the s01_BasketInfo table, with `type` = my module's code. Then when the order is placed, the entry is not converted to the corresponding custom order field. Here's how I'm calling `Write_Basket`:

<mvAssign name="l.null" value="{ [ CSMWS_cfModPath() ].Write_Basket( l.module, 'it seems that this is not used', l.customOrderFieldCode, l.dataToSave ) }">

<mvFunction name="CSMWS_cfModPath" standardOutputLevel="">
   <mvComment> taken and modified from: http://www.blogbyben.com/2015/05/miva-merchant-accessing-custom-fields.html </mvComment>
   <mvFunctionReturn value="/mm5/5.00/modules/util/customfld.mvc"/>
</mvFunction>

Coincidentally on this site there are some custom basket fields that are created during checkout using mvt code, and I see those entries in s01_BasketInfo have `type` = 'customfields' and are copied over to their corresponding custom order fields when the order is placed.

So it seems like the 'l.module' that I pass over has to be the customfields module instead of my own module..? Not sure how to do that?

[Scot - ScotsScripts.com]

Use the page item in the miva docs, not an api function like you're doing above. Write_Basket is a low level function that there is little reason to use except in modules dealing with that stuff.

Write:

<mvt:item name="customfields" param="Write_Basket( 'custom_field_code', l.some_data_to_write )" />

Read:

<mvt:item name="customfields" param="Read_Basket( 'custom_field_code', l.data_from_custom_field )" />

If you want them to automatically turn into custom order fields make sure that the exact same custom field code that you are using for the basket fields exists as order fields. Remember that basket fields can be written on the fly using any code so it's up to you to keep track.

[Mike521w]

I'm more confused now.. Do you mean I should put those tags inside my module and compile it?

I tried, all that happened is the full tags were output to the page alongside the html source.. I must be missing something

[Mike521w]

Welp, this hacky garbage worked perfectly. Kill me now.

<mvAssign name="l.fakeModuleBecauseWTF" value="{l.module}">
<mvAssign name="l.fakeModuleBecauseWTF" member="code" value="{'customfields'}">
<mvAssign name="l.fakeModuleBecauseWTF" member="id" value="{'96'}">
<mvAssign name="l.null" value="{ [ CSMWS_cfModPath() ].Write_Basket( l.fakeModuleBecauseWTF, 'it seems that this is not used', l.supplierShipperMap_customOrderFieldCode, l.supplierShipperMap ) }">

[Scot - ScotsScripts.com]

I didn't know you were doing it in a module, the code I gave you works in templates. Looks like you figured out how to do it in the module though!

[Mike521w]

Yea, but is that the best way to do it in a module? I can't believe it

[Scot - ScotsScripts.com]

If you're in a function that has "module var" as one of the params you can use l.module instead of setting your own params. The module settings hardly matter in my experience. Or you could pass the l.module structure around your functions until you need to use it. You can also use module_Description(...) to load your l.module settings:

<MvASSIGN NAME = "l.ok" VALUE = "{ module_description(l.module) }" />

Do you have the LSK? You can see what the write_basket function is doing in the mmlsk-customfld.mv file and see if it's what you need, or if one of the lower level functions inside it would work.

Also, there's an easier way to set members.

Instead of

<MvASSIGN NAME="l.fakeModuleBecauseWTF" MEMBER="code" VALUE="{'customfields'}">

You can do

<MVASSIGN NAME="l.fakeModuleBecauseWTF:code" VALUE="{'customfields'}">

[Mike521w]

oh nice, I didn't know that, thanks!! (about setting members)

Yea I read through the LSK - long story short, in order for it to save as 'customfields' it wants `module:code` to be 'customfields', and the `module:id` has to match the real customfields module ID. So if I pass my own module data along (which is what I originally did), it saved it as a separate BasketInfo field, and it wasn't auto-copied to the custom field later

But if I 'pretend' that my module is the customfields module in this way, it saves it alongside any other customfield BasketInfo stuff, and auto-copies it.

I made a minor modification to pull the correct ID of the customfields module rather than hardcoding it, since I'll be running this on a few stores I manage.

It works but I can't say I'm proud of this particular section lol