3.7.1 custom product merge fields

[Si]

Hi,

Another issue with 3.71 is that custom product merge fields in emails which worked previously now no longer work. I've followed the manual and used the formats in the fields which are shown

 

Quote from manual: Likewise with product custom fields, you use the format {$service_custom_field_fieldname} and so if the field was called "Dedicated IP" you would put {$service_custom_field_dedicatedip}

 

So, I have a dedicated field which is called 'Additional Domain' so I've tried:

 

{$service_custom_field_additionaldomain}

{$service_custom_field_AdditionalDomain}

{$service_custom_field_additional domain}

{$service_custom_field_Additional Domain}

{$service_custom_field_Additional_Domain}

 

and none of them work. ?

 

Anyone give me any pointers as to what I'm doing wrong?

 

Thanks

 

Si

[Iceman]

A random thought... what happens if you remove the space from the custom field name?

 

Cheers,

Paul

[HiDef-Laws]

Like the merge field table shows on the email template page...

 

{$service_custom_fields.#}

 

So you go based on the # in the list of your fields for the specific service in question. If field #5 for Joe Blow's Place is an IP address that you wanted to relay to them you would do the following:

 

{$service_custom_fields.5}

 

That's it. Honestly, I wasn't happy when I saw mine weren't working but this coding is a lot easier to type in than full field names.

[Iceman]

A quick question based on that then... (Im not on 3.7.1 yet)... what happens if you delete custom field #3. Does that then mess up the numbering? eg #5 becomes #4 etc.

 

Cheers,

Paul

[Si]

Like the merge field table shows on the email template page...

 

{$service_custom_fields.#}

 

So you go based on the # in the list of your fields for the specific service in question. If field #5 for Joe Blow's Place is an IP address that you wanted to relay to them you would do the following:

 

{$service_custom_fields.5}

 

That's it. Honestly, I wasn't happy when I saw mine weren't working but this coding is a lot easier to type in than full field names.

 

I should have said, I tried this too and it doesn't work either.

 

I have a particular product with 2 custom fields only, so you would think

 

{$service_custom_fields.1}

{$service_custom_fields.2}

 

would return them. It doesn't. 1 returns what I expect to be in 2 and 2 returns nothing. ?

 

Si

[Iceman]

lol...

I'd guess it starts at field 0,1,2... etc NOT field 1,2,3...

 

Cheers,

Paul

[Si]

lol...

I'd guess it starts at field 0,1,2... etc NOT field 1,2,3...

 

Cheers,

Paul

 

why didn't I think of that. (answers on a postcard)

 

Thanks Paul - that sorted it.

 

Si

[Iceman]

Cool

 

So what happens to the number system if you delete say field #1 ... does that mess up all field numbers after it?

 

Cheers,

Paul

[Matt]

You can use both methods discussed in this thread to reference the custom fields in emails. I've provided examples in a similar thread @ http://forum.whmcs.com/showpost.php?p=74230&postcount=8

 

Matt

[Chrisw]

Matt,

 

I'm blonde so forgive me..

 

You said:

The first and easier way is the array method for example {$service_custom_fields.0) or {$service_custom_fields.1} for fields 1 & 2 respectively.

 

ok, and if I set it up like that and later remove the custom field 0, what will happen? Will "0" be dead and the next one I create be "2" or will "1" drop to "0"?

[Iceman]

Hey Chris,

 

That's exactly what my question concerned in two of my posts above. If the numbering for each field changes after deleting a field it will play havoc with your custom templates.

 

Cheers,

Paul

[HiDef-Laws]

Hey Chris,

 

That's exactly what my question concerned in two of my posts above. If the numbering for each field changes after deleting a field it will play havoc with your custom templates.

 

Cheers,

Paul

 

Yes, that is one problem with the WHMCS system. Even before the change to the # scheme for custom fields/values, if you were to re-order or remove a field you would scramble all of your field values. 3 becomes 2, if you delete 2. Much care must be used when added custom fields to ensure that they are in a proper order without much chance of changing them in the future.

[Matt]

ok, and if I set it up like that and later remove the custom field 0, what will happen? Will "0" be dead and the next one I create be "2" or will "1" drop to "0"?

Yes, it's the field number in terms of order displayed - not a fixed ID number. And therefore removing a custom field would change the number and require updating.

 

That's quite rare however but if you do think you might do that in future, that's why you also have the option of using the name convention instead. When I said it was easier earlier, I meant it's easier for people to understand how to do, rather than having to convert the field name to lowercase and remove all but certain chars.

 

Matt

[HiDef-Laws]

I just attempted to use the "field name" function for the mergeable fields instead of the # function and I'm getting no values reported.

 

 

{$service_custom_field.blahblah}

 

I even tried {$service_custom_fields.blahblah} like the #'s use. Nothing. I've followed the directions Matt provides in the other forum entry (drop all capital letters and remove all special characters outside of a-z 0-9). So the term, My Amazing Control Panel, turns into, myamazingcontrolpanel. Anyone else have this working reliably? I don't typically post on a forum for troubleshooting unless I believe I've thoroughly exhausted variables so hopefully I'm not doing something stupid here.

[HiDef-Laws]

Still nothing being outputted with those tags.

 

For a custom product field named: Ventrilo Service IP

 

I have attempted the following template codes in email:

 

{$service_custom_field.ventriloserviceip}

{$service_custom_fields.ventriloserviceip}

{$service_custom_field.ventrilo service ip}

{$service_custom_fields.ventrilo service ip}

 

The {$service_custom_fields.#} works without any problems, however not every product field lines up the same way and remaking welcome emails 10-15 times is not my idea of fun.

[Si]

Hi,

Yeah, sad to say I gave up on trying to get those named fields working as described by Matt's forum link post. I resorted to the .1 .2 method, which works for me now, but in future I too am going to hit issues like you are hitting now.

 

Sorry it's not good news but I am sure it's probably just us being stupid as it's rare that Matt gets things wrong.

 

Si

[HiDef-Laws]

Sadly, I'm up a creek at the moment. I'm not going to re-order each packages items to line up similar items into the same field. I'd lose data unless I did a ridiculous amount of sql editing by hand (even then, I think I'd lose quite a bit of data). I'm going to be forced to send a random email about activation and point them to their package details. I've hacked that page to show the custom fields at the bottom. Hopefully Matt will see this and get to the bottom of it. I sent him a pm about it but no response yet.

[Matt]

I just attempted to use the "field name" function for the mergeable fields instead of the # function and I'm getting no values reported.

 

{$service_custom_field.blahblah}

 

I even tried {$service_custom_fields.blahblah} like the #'s use. Nothing. I've followed the directions Matt provides in the other forum entry (drop all capital letters and remove all special characters outside of a-z 0-9). So the term, My Amazing Control Panel, turns into, myamazingcontrolpanel. Anyone else have this working reliably? I don't typically post on a forum for troubleshooting unless I believe I've thoroughly exhausted variables so hopefully I'm not doing something stupid here.

 

You need to use the syntax as in the examples I provided earlier ( http://forum.whmcs.com/showpost.php?p=74230&postcount=8 )

 

So instead of {$service_custom_field.blahblah}, it should be {$service_custom_field_blahblah} - underscores to seperate the values - not a period.

 

Matt

[HiDef-Laws]

That was it.