Title for users missing?

[MrGettingRatherFrustrated]

Doing some work on the email templates and I was surprised to discover that the user information doesnt include title (ie Mr, Mrs, Miss etc)

Has anyone ever raised this with WHMCS or created a feature request?

The reason I ask is that in French, and I'd imagine in other languages too, a business email should really be addressed to M, Mme or Mlle %Surname% 

[brian!]

30 minutes ago, MrGettingRatherFrustrated said:

Has anyone ever raised this with WHMCS or created a feature request?

yes - https://requests.whmcs.com/topic/ive-suggested-this-before-mr-miss-mrs-dr-sir-before-first-name-so-we-can-see-who-they-are

30 minutes ago, MrGettingRatherFrustrated said:

The reason I ask is that in French, and I'd imagine in other languages too, a business email should really be addressed to M, Mme or Mlle %Surname% 

client custom fields would be the way to go - either a list only for the current language, or a list of all available options or just basic options that then uses Language Overrides (not that they would be applicable in the email templates).

[MrGettingRatherFrustrated]

Thanks once more - Brian!

Over 8 years old! OMFG that is beyond ridiculous that it still hasnt been implemented 

[brian!]

2 hours ago, MrGettingRatherFrustrated said:

Over 8 years old! OMFG that is beyond ridiculous that it still hasnt been implemented 

the fact that it's marked as already possible (as it can be achieved in a clumsy way using custom fields), will mean that it won't get completed.

[MrGettingRatherFrustrated]

That really is nothing other than pure arrogance and laziness by WHMCS - I do see a recurring theme here  ....
I think I'm more shocked that such basic and relevant personal information wasnt identified from day 1 as being needed - I can go back 30 odd years to designing forms (on paper then dBase) where title would have been part of the form and certainly in the UK referring to customers by firstname would have been frowned on back then in my experience.

The fact that multiple templates have to be bastardised and hacked about simply to achieve this also shows what a mess things are - why isnt user registration a common template consumed by others instead of each being unique.

I still do wonder whether the obsfuscation of the PHP pages is more to hide what a shambles the code is than anything else ...

Edited March 16, 2021 by MrGettingRatherFrustrated
clarification

[MrGettingRatherFrustrated]

OK, am I missing something or is this a bug?

I'm using a child theme of 21 and child order forms of standard_cart

I can succesfully modify register.tpl in the theme - so I've moved the salutation to Personal Details and the Currency choice to Billing Address (which I shall now rename to Billing Details in language overrrides)

I copy checkout.tpl from the standard_cart order forms to my custom child order forms. modify it and the layout changes are ignored, if I make the exact same changes to checkout.tpl in standard_cart itself then the checkout is displayed with the changes - so my editing appears correct and the child order form is not behaving as it should as far as I understand things.

I have purged the cached templates to ensure that its not caused by that

[brian!]

for mysterious reasons, you'll need to copy viewcart.tpl to your child theme - and then the modified checkout template should work. 🙄

[MrGettingRatherFrustrated]

26 minutes ago, brian! said:

for mysterious reasons, you'll need to copy viewcart.tpl to your child theme - and then the modified checkout template should work. 🙄

Hmm, I already had viewcart.tpl in the custom child order form so that doesnt appear to fix it now 😞

I've logged another bug to go with the 30+ already on the list.

I wonder how many more months they will wait until approving my feature requests - its blatantly clear that it is quite deliberate obstruction although why is beyond me.

[brian!]

is the child order form your default orderform template? and the product group is not assigned to use a different template ?

[MrGettingRatherFrustrated]

The standard_cart is the default order form template for WHMCS and then I have a custom child order form set on the category

I actually have a couple of custom child order forms for different product types - although that change is made to both.

I did try WHMCS set to one of the custom order forms but that screwed up some links for add to cart etc so I reverted and havent had time to investigate that again yet

[MrGettingRatherFrustrated]

Right, I am back on this and it is def a bug as far as I can see.

The default order form is the standard cart

I have two child order forms and have viewcart.tpl in both

Some but not all of of the customisations are honoured

For example in standard_cart

viewcart.tpl has 

                                        {if $taxrate}
                                            <div class="clearfix">
                                                <span class="pull-left float-left">{$taxname} @ {$taxrate}%</span>
                                                <span id="taxTotal1" class="pull-right float-right">{$taxtotal}</span>
                                            </div>
                                        {/if}
 

and ordersummary.tpl has

            {if $producttotals.pricing.tax1}
                <div class="clearfix">
                    <span class="pull-left float-left">{$taxname} @ {$carttotals.taxrate}%:</span>
                    <span class="pull-right float-right">{$producttotals.pricing.tax1}</span>
                </div>
            {/if}
 

In my custom order forms I have changed both of these to $LANG.truffiere.taxname which I have in language overrides but it has no effect, even if I force the template on the URL with ?carttpl=xxx. 
If I change these in the standard_cart templates then I get the desired effect - ie TVA shown rather than VAT for France, IVA for Spain etc

Obviously the custom order forms are assigned to the relevant product groups

Edited April 4, 2021 by MrGettingRatherFrustrated

[brian!]

On 04/04/2021 at 14:23, MrGettingRatherFrustrated said:

In my custom order forms I have changed both of these to $LANG.truffiere.taxname which I have in language overrides but it has no effect, even if I force the template on the URL with ?carttpl=xxx. 

you can give the tax rate for each country it's own name (VAT/IVA whatever), so why are you using overrides ? without additional tweaks, I doubt they would be used elsewhere in the order process.

my suspicion is that depending on what products are in the cart, then the cart might detect a template conflict and just use the default orderform template... it might be a pain to test to prove that though (certainly from the outside)... using a hook to change the value of the variable would work.

[MrGettingRatherFrustrated]

Hi Brian,

Do you mean changing the labels in the database - I couldnt see a way to do this via the admin interface but did try it directly in the DB

I found that there were two issues with that

1) I was actually trying to do something a bit more complex but kept the explanation simple - what I was actually trying to do was add a localised ex. VAT/inc. VAT lable to the product prices AND localise the name of VAT so needed to customise the template regardless

2) When I tested changing the tax names in the DB there were some places where the change only took effect once the billing country was specfied during the order, until then defaulting to the installation default of VAT - I dont recall where now though (it could have been on the product pages it didnt show but on the cart pages it did)

The conflict makes sense and is almost certainly the cause as adding configproduct,tpl to that child order form (without modificiation) results in a blank page - that hadnt occured to me but gives me a glue as to where to investigate, so thanks once more!

All that aside it does seem another defect with the product that a language key isnt being used in the templates for some of these fields and given how common it is, in Europe at least, to state whether prices include or exclude tax - and often show both prices - this does seem a weakness and oversight in the cart - I am sure you will advise it is one of many! 🙂 

[MrGettingRatherFrustrated]

To further update,

I complety replaced my standard_cart with the one from the 8.1.3 download to remove any risk of that having being modified or corrupted

I created a new order_form with just theme.yaml and the viewcart.tpl plus checkout.tpl as it is referenced by viewcart.tpl
I then modified viewcart to remove the Promo options on checkout and also to remove State

- both theme.yaml and viewcart.tpl are attached 

I clreared the template cache and assigned the orderform to a product hroup and went to order a product in that group - the default_cart is used showing the Promo options & State

If I replace viewcart.tpl in standard_cart with this modified one then I get the desired result

I really cant see how this can be a conflict of some sort and am following exactly the process described in the documentation for a child template so am inclinded to think that this is some sort of bug - or the documentation isnt accurate

I have contact support abut this but as always that isnt yielding much in the way of support ...

theme.yaml viewcart.tpl

[brian!]

6 minutes ago, MrGettingRatherFrustrated said:

Do you mean changing the labels in the database - I couldnt see a way to do this via the admin interface but did try it directly in the DB

yeah there wouldn't be a way from the admin area - I think that's really there to prevent users from changing tax rates directly (off-topic, when the time comes to change a tax rate, you delete the current rate and add a new tax for that country).

31 minutes ago, MrGettingRatherFrustrated said:

1) I was actually trying to do something a bit more complex but kept the explanation simple

oh I took it as red that you were trying to do something more complicated! 🙂

33 minutes ago, MrGettingRatherFrustrated said:

what I was actually trying to do was add a localised ex. VAT/inc. VAT label to the product prices AND localise the name of VAT so needed to customise the template regardless

I might have been tempted to hook rather than template change, but do me a favour and post any relevant new language strings that will be used in these modified templates.

34 minutes ago, MrGettingRatherFrustrated said:

I am sure you will advise it is one of many! 🙂

far too many to mention!

15 minutes ago, MrGettingRatherFrustrated said:

I really cant see how this can be a conflict of some sort and am following exactly the process described in the documentation for a child template so am inclinded to think that this is some sort of bug - or the documentation isnt accurate

it may not be an either/or - both could be the case.

i'll take a look at this tomorrow (be nice to focus on something other than price increases!), but one quick question - when you're testing this, does the product require a domain or not?

18 minutes ago, MrGettingRatherFrustrated said:

I have contact support abut this but as always that isnt yielding much in the way of support ...

I think they often send users with customisation questions back to this place... and so the loop begins!

[MrGettingRatherFrustrated]

Thanks Brian, much appreciated

There are literally no language strings or anything in this example other than commenting out the Promo Code element and the State drop down - intentionally to try and prove that there was something fundamentally wrong here

No domain is required

I will PM you the example products using them, 1 has custom fields and a module, another is as raw as it can be with no module and no custom fields 

Edited April 7, 2021 by MrGettingRatherFrustrated

[brian!]

16 hours ago, MrGettingRatherFrustrated said:

There are literally no language strings or anything in this example other than commenting out the Promo Code element and the State drop down - intentionally to try and prove that there was something fundamentally wrong here

fundamentally, I think this custom orderform template works fine without any obvious issue that I can see (including when using a product with a domain)...

the only change I made to the template was to show the cart theme name in the order summary heading - just so I know which template it's loading... and it's using the "test" orderform template - other than that, it's your viewcart and theme.yaml files as posted and an unaltered checkout tpl from 21 v8.1.3

yet, I can see that it doesn't work on your site - the only way I could get it to work was to pass &carttpl=test in the URL...

whether there is something weird going on because the test product is in a ssl-certificate group, I don't know - it shouldn't be though as they don't appear to be marketconnect products... i'd be tempted to put the test product in it's own product group, assign the test orderform template to that group and see if that gets you any further.

[MrGettingRatherFrustrated]

Thanks, once more, for your effortsand assistance Brian,

I changed it to a new group and it was still the same, the fact that the template worked as is for you and can be forced with carttpl left me stumped.

In desperation I changed the default theme back to twenty-one and it worked as expected, then I reverted to my custom theme and it is now behaving as expected!

I have no idea how this could fix the issue or how the theme could impact the order forms 

Bemused!