cart.php template vars list?

[disgruntled]

Ok, so the bottom line is this, i have just put together an awesome slider for VPS/Dedicated. this could also be used in general i suppose if you offered custom packages with configurable options.

 

Now what i need is the template vars. This is a one page slider and i think its awesome.. i would, i wrote it. I may also release to the community the full thing, (donations would be gratefully accepted)

 

The slider selects the vps / dedicated base products, and on the same page so no clicking to another page or ajax loadups, the client then gets to select any addons. How many virtual cores, how much ram, you get the idea.

 

The pricing is displayed as well as the quantities selected. However this side is front facing and the pricing is just for client show. This does not make pricing changes to the order itself those need to be set up in the product pages. when submitted the package and quantities are submitted only allowing whmcs to take over the rest of the order process.

 

Now, this is where i am at I have all the pricing hard coded into the functions. (just because i needed to test the slider worked correctly)

 

I need to know what vars whmcs uses in the cart.php as this is the file that will call my slider (will be in the templates). Are all vars available at file call time, or are they called with ajax as the options progress?

 

I need them to be all available ideally, i dont want to rewrite cart.php.

 

If you know the answers, or know of the template vars for this file please let me know so i can continue this cool slider

[bear]

Look within the templates here: \templates\orderforms\cart\

http://docs.whmcs.com/Order_Form_Templates

Adding {debug} temporarily and visiting the page should reveal the available vars.

http://docs.whmcs.com/Template_Syntax

[disgruntled]

Look within the templates here: \templates\orderforms\cart\

http://docs.whmcs.com/Order_Form_Templates

Adding {debug} temporarily and visiting the page should reveal the available vars.

http://docs.whmcs.com/Template_Syntax

 

 

Thank you bear, i totally forgot about debug (DOH)

 

the link you pasted is very generic and doesnt list the vars in use. i think that is something that should be added to the documentation, at least to the developers area. IE: cart.php list of vars, when/where they become available during the order etc. would certainly be a great help.

 

for now, il debug. thanks again bear

[disgruntled]

awesome!! ok so debug tells me more or less everything i need to know, although the scope of the vars is still a mystery but i suspect a few more debugs on different groups, products templates and form points etc will give me that info. thanks again.

 

For anybody else, (add the {debug} to the header file in templates/orderforms/)

[bear]

Happy to help, just make sure to remove it as soon as possible.

[disgruntled]

I have no hair left, i would show you a photo but i look like a right tool.. this is frustrating massively. simply because of the way the templates are called. headache

[laszlof]

I have no hair left, i would show you a photo but i look like a right tool.. this is frustrating massively. simply because of the way the templates are called. headache

 

Whats the problem you're having? The products list is fairly easy to work with. Take a look at orderforms/modern/products.tpl, and you'll see the foreach loop thats used to step through the products.

 

If you're trying to do this on another page that doesnt have the {$products} variable available, you will need to use a sql query to pull them into that template.

[disgruntled]

Whats the problem you're having? The products list is fairly easy to work with. Take a look at orderforms/modern/products.tpl, and you'll see the foreach loop thats used to step through the products.

 

If you're trying to do this on another page that doesnt have the {$products} variable available, you will need to use a sql query to pull them into that template.

 

 

Hi, this is the template im looking at, the problem isnt the slider in itself thats working just fine, but trying to integrate it into the whmcs ordering process now thats a different ball game.

 

Basically,

 

One page ordering is my aim here, so everything package related is selected in one page, no need for ajax here because everything is pulled into the script at call time, so for a little extra load time and it is miniscule the difference i get less steps in the process, or at lease perceived steps and i feel thats important.

 

So i have,

 

Master slider = packages (have inclusive resources)

 

Configurable options all with 0 min to allow just the base pack above.

 

slider 1, Virtual cores <= 12

slider 2, control panel 5 options total, none through to cpanel

slider 3, memory 1GB incs upto 32GB

slider 4, transfer 10GB incs upto 50TB (bulk of below opts will be here)

slider 5, diskpace 10GB incs upto 500GB

slider 6. backup storage same as previous.

 

Now if i use config opts, im looking at a huge amount of config opts for this to work, is there another way?

[disgruntled]

I looked at the config option, there is an option to use slider in it, but it still leaves me needing 5000 individual pricings for each payment term. My god this is rediculous, Seriously i have it working so easily i really cant understand why whmcs is so backward about config options.

 

 

(GB)

min: 0,

max: 50000,

step: 10;

slide: ( run calcs )

 

 

and the calcs are as simple as.

 

productPrice * ui.value, you will know there is a little more to it but thats the gist of it. The slider needs to be workable in this way too a price EACH option should be set, or price each, with extra options to alter price per quantity, as it stands i cant use my slider to work with whmcs and have anything near a competitive pricing.

 

 

It strikes me as whmcs are overcomplicating everything because they are trying to fit in new features into the system, Fair play to that, but seriously, take a look over the way hosting really works, look at how pricings work, how config options work, whmcs has a very long way to go on this imo.

 

A good start would be to work with the ui sliders and realise the options as stand just dont fit the purpose, unless i am missing a massive peice of data

Edited May 28, 2012 by disgruntled