Un-answered, long time WHMCS client custom fields cart question.

[payless4domains]

This seems to be an un-answered, long time WHMCS client custom fields cart question.

 

I've searched the net, tried to ask WHMCS support to no avail (just got run around in circles)

From what I have found out is when loggedin the only access you have to the client custom fields is via the $clientsdetails.customfields var which allows you to use the id and value only. This can not have any direct input from the user. (I could be wrong)

 

What is needed is the clients custom field to display and to be editable in the cart the same as when the client is loggedout, and from my understanding this can only be done using the $customfields var.

 

The $customfields var is populated, using {debug} when loggedout but when loggedin the $customfields var is there but unpopulated, which is why when loggedout the code works fine.

 

{foreach key=num item=customfield from=$customfields}
{if $customfield.name eq "Date of birth"}
<div class="col-sm-6 form-horizontal">
<div class="form-group">
<label for="inputDateofbirth" class="col-md-4 control-label" style="font-size:.85em;">Date of birth</label>
<div class="col-md-8">
<div class="control">{$customfield.input|replace:'>':"placeholder='e.g. dd/mm/yyyy' style='font-size:.85em;' >"}</div>
</div>
</div>
</div>
{/if}
{/foreach}

 

Does anybody know if there is a hook or something to solve this? This should be just a simple exercise, it makes no sense that a client custom field can be edited loggedout, but can't be once a user has loggedin.

[brian!]

Does anybody know if there is a hook or something to solve this? This should be just a simple exercise, it makes no sense that a client custom field can be edited loggedout, but can't be once a user has loggedin.

I don't believe that you're thinking of this in the correct way - you talk of being loggedin and loggedout - but in this context, you need to think of them as a client or not.

 

e.g if they're not logged in, they're not a client and so a new record in the database needs to be created for their order... now it's possible that they may already be a client, but if they don't login, WHMCS isn't going to know that.

 

if they are logged in, then they're an existing client and they can easily update their custom client fields in the client area - clientarea.php?action=details ... they can do that at any time.

 

i'm struggling to work out why, if I was a client, do I need the option of editing my date of birth during a subsequent ordering process... a) it's not going to change and b) even if it currently has the wrong date, I can update it in the client area.

 

even in the normal address fields, if you remove the "readonly" option, the updated information isn't passed back to the database - so checkout is clearly not the intended method for a client to update their settings.

[payless4domains]

Thanks for your reply Brian,

I don't believe that you're thinking of this in the correct way - you talk of being loggedin and loggedout - but in this context, you need to think of them as a client or not.

e.g if they're not logged in, they're not a client and so a new record in the database needs to be created for their order... now it's possible that they may already be a client, but if they don't login, WHMCS isn't going to know that.

You explain things so much better than I do, and I can understand exactly what you are talking about.

 

And yes it makes sense that the custom client fields are used to generate a new client account and that if they're not logged in, they're not a client and so a new record in the database needs to be created for their order.

 

The thing is, depending on the product that is being purchased by our new (loggedout) or our existing (loggedin) clients, is to what extra client details we need, I am aware that these probably and should be added as custom product fields but I was trying to avoid using custom product fields, for one they generate an extra page for the client to full in i.e. configureproduct.tpl, we could possibly try to skip the configureproduct template during the order process (if there was a way to do this) and maybe include it in the viewcart.tpl e.g. using something like {include file="configureproduct.tpl}

 

But the main reason behind not using product custom fields and needing to be able to edit and save client custom fields as an existing client in the cart as you can as a new client, are the reports & some of our add-on modules that our system require are using custom client detail fields.

 

Plus the details we require are more client related than product.

 

if they are logged in, then they're an existing client and they can easily update their custom client fields in the client area - clientarea.php?action=details ... they can do that at any time.

Having the same ability on the cart page to add some individual custom client fields that update the database as the clientareadetails page does would solve our issue; this is why I was asking if there was a hook out there that could let use access the customfields var . Even though I didn’t explain it to well, hope I have now.

 

i'm struggling to work out why, if I was a client, do I need the option of editing my date of birth during a subsequent ordering process... a) it's not going to change and b) even if it currently has the wrong date, I can update it in the client area.

Yeah I can understand the confusion here; I shouldn’t have used ‘Date of birth’ as an example.

 

even in the normal address fields, if you remove the "readonly" option, the updated information isn't passed back to the database - so checkout is clearly not the intended method for a client to update their settings.

Yeah found this one out, after days of trying to get it working.

[brian!]

The thing is, depending on the product that is being purchased by our new (loggedout) or our existing (loggedin) clients, is to what extra client details we need, I am aware that these probably and should be added as custom product fields but I was trying to avoid using custom product fields, for one they generate an extra page for the client to full in i.e. configureproduct.tpl, we could possibly try to skip the configureproduct template during the order process (if there was a way to do this) and maybe include it in the viewcart.tpl e.g. using something like {include file="configureproduct.tpl}

 

But the main reason behind not using product custom fields and needing to be able to edit and save client custom fields as an existing client in the cart as you can as a new client, are the reports & some of our add-on modules that our system require are using custom client detail fields.

 

Plus the details we require are more client related than product.

the problem with using client custom fields in the way you describe is what happens if, for two different products, a client custom field requires different values - e.g Yes for one, No for the other - it can't store both.

 

personally, i'd just used product custom fields on the extra page and then adjust your other reports and addons - but I suspect either route (product or client fields) involves a lot of hassle.

 

Having the same ability on the cart page to add some individual custom client fields that update the database as the clientareadetails page does would solve our issue; this is why I was asking if there was a hook out there that could let use access the customfields var . Even though I didn’t explain it to well, hope I have now.

as you're using v6.1.0, it might be better to post in Service Offers & Requests and pay a developer to code this for you.

[payless4domains]

the problem with using client custom fields in the way you describe is what happens if, for two different products, a client custom field requires different values - e.g Yes for one, No for the other - it can't store both.

 

personally, i'd just used product custom fields on the extra page and then adjust your other reports and addons - but I suspect either route (product or client fields) involves a lot of hassle.

 

 

as you're using v6.1.0, it might be better to post in Service Offers & Requests and pay a developer to code this for you.

 

Agreed, Looks like I'm going to have to use product custom fields in the cart and client.

 

I can see a problem with that also, I need to be able to let the clients edit some of the product custom fields from their client area i.e. clientareaproductdetails page, once again I can view them but don't know how to have it save, as you can on the clientareadetails page with the client custom fields.

 

Bit of a catch twenty two

 

Any ideas? can it be submit using a form? hmmm head hurts.

 

Kev

[brian!]

Agreed, Looks like I'm going to have to use product custom fields in the cart and client.

 

I can see a problem with that also, I need to be able to let the clients edit some of the product custom fields from their client area i.e. clientareaproductdetails page, once again I can view them but don't know how to have it save, as you can on the clientareadetails page with the client custom fields.

 

Bit of a catch twenty two

 

Any ideas? can it be submit using a form? hmmm head hurts.

Product Custom Fields are really intended to take specific information during the ordering process.

 

https://forum.whmcs.com/showthread.php?33785-Custom-Fields-for-Product-Services&p=168786#post168786

 

Yes custom fields for products/services can only be set by a customer at the time of signup. If a customer was allowed to edit the fields at a later date from the client area, your admins or staff wouldn't know it had been done so not sure what it would achieve?

so while it's probably technically possible to take the product custom fields from the database, let the customer alter them in a form and then write the updated values back to the database... i'm unsure if it should be done.

 

i'm assuming these custom fields are just text fields and so could contain any text? perhaps if you had a text field that should only contain specific words (e.g Red, White, Blue etc) then you could use a configurable option dropdown for that and the client would then be able to easily change their selection from the client area.

 

other than that, you're either going to need a custom solution to allow the customer to edit their product custom fields... or get them to open a support ticket with you when they need to make changes and at least that way you'll have a record of the changes made to the custom fields.

[payless4domains]

Thanks again Brian for your wisdom,

 

Product Custom Fields are really intended to take specific information during the ordering process.

https://forum.whmcs.com/showthread.php?33785-Custom-Fields-for-Product-Services&p=168786#post168786

Quote from the above link:

“If a customer was allowed to edit the fields at a later date from the client area, your admins or staff wouldn't know it had been done so not sure what it would achieve?”

 

I understand this is an unusual case, but as I said earlier the information that we need our clients to enter into these fields are more client related.

To be more pacific the data that is entered into the fields are dates and reference no’s and these details need to updated by the client at different times during the year.

Our reports do the rest, this is why we were using client custom fields, which works fine, as a new client, until we realised that client custom fields didn’t save in the cart for an existing client if they were to purchase a new product that required the additional information.

 

so while it's probably technically possible to take the product custom fields from the database, let the customer alter them in a form and then write the updated values back to the database... i'm unsure if it should be done.

So thinking along the lines of being technically possible, using the {debug} on the following pages I can see that custom fields are listed with the input function:

 

Configureproduct.tpl - $customfields

Viewcart.tpl - $customfields and/or $products

Clientareadetails.tpl – only client $customfields

Clientproductdetails.tpl - $customfields and/or $productcustomfields

 

If we were to convert our existing client fields to product fields, we will still need our clients to edit these within their client area. So we need a way to update the DB with information entered into the product custom fields.

 

Do you know a possible way that we could this? Logically it looks as if it could be done on the Clientproductdetails.tpl but there is no current way of submitting the info, on the other hand on the Clientareadetails.tpl you can submit but this only updates client custom fields. Hmmm

 

And another thought, the viewcart.tpl has both $customfields and $product.customfields listed in the var, so could the configureproduct.tpl page be skipped and the product configuration be entered directly in to the viewcart calling the available var? To shorten the order process.

 

Thanks again Kev

[payless4domains]

Brian,

 

I just had a reply from a WHMCS ticket. And this has put another spin on things.

 

Something to note is that Client Custom Fields can only be modified when the customer registers a new account, or when the customer edits their profile via the Client Area. Simply adding a field to the checkout process won't force WHMCS to pass the data and modify the existing Client Custom Field.

 

The best way to accomplish this would be with the ClientAreaPage hook. You could use this to hook to create a smarty variable that drops in a submission form where the user can enter in their data, and then when they submit the form the script could process it using the Update Client API function.

 

You can read more about this hook and function on our documentation site at:

http://docs.whmcs.com/Hooks:ClientAreaPage

http://docs.whmcs.com/API:Update_Client

 

We have worked though the first part of this, but here's another idea. Any idea on how this could be written, and would this be a better way to do things?

[brian!]

I understand this is an unusual case, but as I said earlier the information that we need our clients to enter into these fields are more client related.

To be more pacific the data that is entered into the fields are dates and reference no’s and these details need to updated by the client at different times during the year.

Our reports do the rest, this is why we were using client custom fields, which works fine, as a new client, until we realised that client custom fields didn’t save in the cart for an existing client if they were to purchase a new product that required the additional information.

 

Do you know a possible way that we could this? Logically it looks as if it could be done on the Clientproductdetails.tpl but there is no current way of submitting the info, on the other hand on the Clientareadetails.tpl you can submit but this only updates client custom fields. Hmmm

if a .php file isn't expecting additional information to be sent to it, then changes to the template won't make much difference.

 

And another thought, the viewcart.tpl has both $customfields and $product.customfields listed in the var, so could the configureproduct.tpl page be skipped and the product configuration be entered directly in to the viewcart calling the available var? To shorten the order process.

it wouldn't shorten the process by that much if the same information still has to be entered - unless the loading time between cart steps on your site is very slow.

 

I just had a reply from a WHMCS ticket. And this has put another spin on things.

We have worked though the first part of this, but here's another idea. Any idea on how this could be written, and would this be a better way to do things?

it's not another spin, just exactly the same as my reply on Tuesday.

 

not wanting to repeat myself, but you're going to need a developer to custom write this for your specific situation - sure, I could give you the basics of what needs to be done, but this might need significant tweaking and with you using v6.1 and needing the code to interact with other addons, generalities will likely not be enough.

 

so while it's probably technically possible to take the product custom fields from the database, let the customer alter them in a form and then write the updated values back to the database...

another thing about using client custom fields is that, by default, all of them will be shown to all clients - regardless of whether they're applicable to them or not (e.g they may not have the product) - but perhaps you've taken care of this in the client area templates.