A question was asked on the Cartweaver Forum, about adding new application variables that would allow two sites to run from a single database, with separate settings:
CW 4 seems to set many admin parameters in the DB itself… can 2 stores share the same db but not all admin setup variables?
In other words, can you user a single database and admin, but display things one way under a specific url (e.g. server1.com/product.cfm), and another way in a store in another location (e.g. server2.com/product.cfm). The answer, of course, is yes… with several options.
There are a few ways you can handle this, so I’m going to outline a few options. The user proposes this example, as a setting that should vary depending on the page being looked at:
Let’s take the “Cart Display Settings > add to cart action” as an example of an admin setting stored in the Database. In the public online store, I may want to set it to go to cart but in my local intranet store, I would like to overide this to the detail page. (Just an example)…
Note: this was asked on the ColdFusion forum, so the examples here are in CF. But the same general principles apply to Cartweaver 4 php, though the request/application scopes aren’t quite the same behind the scenes, since those are native to CFML.
Application vs. Request Variables
The first thing to understand is the way that this setting is applied to the page via the ‘request’ scope, even though it is initially stored along with all of the other admin variables in the ‘application’ scope.
Any value saved into the request scope is available at any point in that page’s processing, after the point where it is set, even inside of includes. So you could put this anywhere in your code:
<cfset request.cw.color = ‘blue’>
and then at any point after that, in any part of your code, you could display the value like:
<cfoutput>#request.cwpage.color#</cfoutput>.
This is a crude example, but… that’s how the request scope works. Set it anywhere, use it anywhere else, and unlike application variables which are stored in the system memory, the request scope only exists for each page request.
Using the Request Scope
So, for our example setting, the ‘add to cart’ action, near the top of the code in cw-product.cfm, you will see this line:
<cfparam name=”request.cwpage.cartAction” default=”#application.cw.appActionAddToCart#”>
This takes the value you have set in the admin, “appActionAddToCart”, and puts it into the request scope for that page.
However, note the use of “cfparam” here, instead of “cfset”. This means, if the value does not already exist, set the default. Otherwise, this code is ignored.
So, that line is where the setting from your admin gets transferred to your actual page. As for how it is actually used, we look at the value of the add to cart action, to set a different value, which is the URL for the page shown after an item is added. Further down in that file you will see this block:<!— redirect after cart action —>
<cfif request.cwpage.cartAction eq ‘goTo’ and not len(trim(request.cwpage.addToCartUrl))>
<cfset request.cwpage.addToCartUrl = trim(request.cwpage.urlShowCart)>
</cfif>
Note the line in bold. If your cartAction is “goTo”… we take the customer to the cart. Otherwise, the default value is left in place, and the customer stays on the page they are on.
Changing the Default Values aka Overriding Admin Settings
Now for the potential solutions to the problem at hand.
1) Quick ‘n Dirty … Hard Code it in the Page
Right above that first example ‘cfparam’ line, you could set the value of the cart action variable like so:
<cfset request.cwpage.addToCartAction = ‘confirm’>
This would override the cfparam by putting an actual value in place, and your page would use this setting instead of the admin value for the Add To Cart Action. Taking this one step further, if you were trying to set that value only for a specific server location or directory, you could wrap it in a conditional cfif, like so:
<cfif cgi.server_name contains ‘server1.com’>
<cfset request.cwpage.addToCartAction = ‘confirm’>
</cfif>
This way, your page would use the default value unless you are on ‘server1.com’, at which point your hardcoded setting would apply instead.
2) Setting a Global Request Value
The method above will work just fine… but only for the one page you are editing. If you wanted to override this setting for the entire site, you would want to put the <cfif> code into a global location.
A good spot for this is in cw4/cwapp/func/cw-func-init.cfm. The “init” file sets all of the global settings for every page, and for the Application itself. Your code (the cfif block above) can be inserted at the end of the func-init file, just before the closing </cffunction> tag for the cwInitRequest function. Anything set into the ‘request’ scope in this file will be available to every page of your site.
3) Creating Your Own Application Variables
One of the most powerful but least-known features of the Cartweaver admin is the way the config variables (aka Admin Settings) are created in the first place. Logged in at the developer level to your store admin, click the option in the menu for
Site Setup > Configuration Variables.
This is where Cartweaver’s global settings are created and stored… and where you can add your own.
For the sake of this example, let’s say you wanted to add a new setting called “appActionAddToOtherCart“.
From the Configuration Variables page, click on the little pencil icon next to the “Cart Display Settings” group. Then, click the button for “Add New Config Item”. Fill in the form that appears, and voila, there is your new custom application variable. (Since the CF application is refreshed automatically when you change or add any config setting, the variable you created is available right away).
So now you have a variable called
application.cw.appActionAddToOtherCart, with a value of “confirm”.
Going back to product.cfm, you could alter the cfparam to use a cfif, just like we did for the request value.
<cfif cgi.server_name contains ‘server1.com’>
<cfparam name=”request.cwpage.cartAction” default=”#application.cw.appActionAddToOtherCart#”>
<cfelse>
<cfparam name=”request.cwpage.cartAction” default=”#application.cw.appActionAddToCart#”>
</cfif>
This is a little bit of a stretch in terms of actual application, but you can see how you could use an ‘either/or’ setting in this way, based on a value you create and control in the admin. With this type of setup, you could then change the action of the ‘other cart’ at any point in the future, without affecting the default behavior on your primary domain.
This also demonstrates how easy it is to create your own global settings, for anything. You can even create a new “config group” such as “other site settings”, and then put all of your new values in there, so they are on their own page in the admin altogether.
4) Custom Cart URL
Lastly, specific to this particular setting, you will see that we are actually using this ‘goto’ value to set a different setting, which is then applied to the Add To Cart logic.
<cfmodule
template=”cwapp/mod/cw-mod-cartweaver.cfm”
product_id = “#form.productID#”
form_values=”#formstruct#”
redirect=”#request.cwpage.addToCartUrl#”
sku_custom_info=”#form.customInfo#”
>
So, you could also intervene at this level, setting the value of “request.cwpage.addToCartUrl” in any of these locations, rather than in that page. And of course, your <cfif> doesn’t have to just use the server name, you could switch this setting based on the Customer Type, the contents of the user’s cart, or just about anything else.
There are even more ways you could accomplish the goal of setting custom variables in your CW store, without breaking the default behavior, but the examples above use the primary principles for modifying Cartweaver with custom variables per page, or per request, or at the global level. Cartweaver 4 is built in the principle of “maximum insertion points”… in both the php and CF versions, there are always multiple ways to inject your own code or logic.
As always *remember to mark your changes to any Cartweaver file* with a custom comment, or some text string you can find later!
Recent Comments