I often want to hide a WordPress “Page” from showing up in my menu structure.
For example, there’s no need for the Thank You page of a webform to be part of your main navigation bar!
Exclude Pages from Navigation is a neat WordPress plugin that puts a checkbox on each Page allowing you to quickly hide that page from your menus.
PHP is great for multi-part signup forms and displaying dynamic HTML content. If you’re using WordPress to host your site, making PHP work can be challenging.
I tested several WordPress plugins and found that only Exec PHP actually works like real PHP. The plugin’s extensive help documentation includes several PHP examples you can test to compare various plugins.
Here’s one test code showing a method I use a lot to display dynamic text. Only Exec PHP made this work right:
<?php if (1) { ?>
<b>Handle THIS!</b>
<?php } else { ?>
<i>Handle THAT!</i>
<?php } ?>
Let’s look at how to use a few lines of CSS to tweak the styling of “hybrid smartforms” provided with the Office AutoPilot and SendPepper marketing and business automation systems.
I like the hybrid forms because except for adding fields, changes to the forms’ functionality are automatically updated without any need to change the form code on your web page.
Plus, the smartforms are “CSS friendly” so you can dramatically change the appearance without killing off the cool built-in Jquery error trapping.
Here’s a picture showing the typical layout and design of an Office AutoPilot smartform:
Here’s a picture of the same form with some small CSS changes.
If you’re going to post your form in a WordPress page or blog post, first learn how to protect your HTML from being destroyed by the notorious WordPress editor.
For the above form, I wanted to “un-bold” the field labels and make them align right. I also wanted the text input fields to be wider for easier data entry. To do this, I added the following styles below the stylesheet that comes with the form.
div.moonray_forms fieldset label {
font-weight: normal;
text-align: right;
width: 125px;
margin-right:10px;
}
div.moonray_forms fieldset input[type=text] {
width:225px
}
Next I wanted to align the Submit button with the the other input fields and add some padding around the word “Submit”. This was accomplished by moving the Submit input up inside the <fieldset> tag, then putting a label in front of it containing a blank space. The following CSS tweaked the style of the button itself.
div.moonray_forms fieldset input[type=submit] {
margin:0;
padding:5px 15px
}
Finally, I wrapped the whole form in a <div> styled like this:
#mytweaks {
background:#D1E3EF;
margin: 0 auto 25px auto;
width: 400px;
padding: 20px;
border: #ccc 1px solid;"
}
The WordPress text editor often modifies your HTML code, making it impossible to accurately style and render custom forms and shortcodes the way you’d like and driving you nuts in general.
The WordPress “wptexturize” and “convert_chars” features pretty much defeat any efforts use any kind of advanced HTML.
Several WordPress plugins have been created to defeat these automatic modifications to your HTML code. These two seem to do the trick for me:
It’s been at least a year since I asked Infusionsoft to clean up the PayPal Radio button craziness…
I know there are folks out there who for one reason or another aren’t set up with a “real” merchant account so they need to use “free” PayPal as the only payment method with Infusionsoft. You know who you are!! And you already know that PayPal will only work with Infusionsoft’s Shopping Cart, not with an Order Form.
So, the nutty thing is, when you set up your shopping cart payment method with “free” PayPal as the only payment method, the cart deploys with two annoying and confusing things:
Let’s fix number 2 first – just add some nice red text in your cart’s “HTML Area 2″ above the PayPal box telling your customers –> Note: PayPal accepts payments from a PayPal account or via a bankcard of your choice.
Making the lone radio button default to “checked” is pretty easy too by using JQuery:
First put this bit of code in HTML Area 1:
<script src="http://code.jquery.com/jquery-1.5.1.min.js"></script>
Infusionsoft will automatically convert that line to look like this:
<script src="/jspServ/imagegetter.jsp?url=http%3A%2F%2Fcode.jquery.com%2Fjquery-1.5.1.min.js"></script>
Next, put this bit of code in your cart’s HTML Area 3:
<script>$('input[name="pmttype"]').attr('checked', true);</script>
If you know a little about JQuery, you can use this technique to really hack (i.e., improve) the look and feel of your Infusionsoft shopping cart.
To display HTML and programming code nicely in a blog, use the Syntax Highlighter plugin. Here’s an example:
<body> <p>I like this plugin!</p> </body>
A few weeks ago, I was hired to try out the new WishList Member integration with Infusionsoft.
The promise of WishList and other membership programs these days is to turn WordPress into a password protected content release membership site that you can monetize with a shopping cart.
The instructions built into WishList’s WordPress interface were incredibly simple. Unfortunately, the integration just didn’t work out of the box. I found a number of experts who said that they had made it work. I even spent 30 minutes on the phone with one. It still didn’t work.
Here’s what I learned in the process after a week of back and forth with WishList’s (email only) tech support. It appears that WishList keys off of some transaction codes deep inside Infusionsoft. It appears that when you test your installation, you must use a live merchant account. You can’t just test the integration by setting your merchant account to test mode.
I say “appears” because we never got to a successful test. There’s a price to pay for cheap software — extremely slow email-only tech support.
A few days into the troubleshooting process, my client started to worry about missing the deadline for his launch. At that point I said let’s go with the InfusionWP membership integration designed specifically for Infusionsoft. In a few hours, we were up and running.
Days later, the techs at WishList finally announced they did a successful test. They noted that their results were achieved by using their own merchant account in my client’s Infusionsoft system, not my client’s merchant account.
In retrospect I could see the problem: The WishList-Infusionsoft integration only works with live bank card transactions. Setting your merchant account to “test mode” inside Infusionsoft will always pull an error. Unfortunately, as of this post there is absolutely no written or video support at WishList’s site for their Infusionsoft integration.
I really wanted to like WishList. It looked simple and cheap. But WishList’s integration strategy is actually quite convoluted. Doing an end run around Infusionsoft’s internal logic with murky coding and cryptic, untestable cron jobs just doesn’t make sense to me at any price.
I’ve been researching recurring billing systems for nearly a decade now. Recurring payment systems have so many uses, from membership eCommerce sites to non-profit donation systems. A lot of merchant accounts offer recurring billing, but very few shopping carts do it well.
To me, an ideal recurring billing shopping cart should do the following:
Today, I put the finishing touches on an eCommerce system that included a cool recurring payment platform that docked to a cool email marketing and business automation application with just one click!
The client first came to me in September 2010 seeking a fix to Infusionsoft’s shopping cart which still does not handle eChecks at the time of this post. For weeks, I looked at every possible shopping cart fix, patch, and workaround. Finally, I quoted the client on a custom cart add-on which was simply beyond the their budget. The project stalled at that point.
Later while working on another project, I discovered that UltraCart offers a sweet recurring billing system for both cards and checks. That still left the high cost of doing a custom cart integration to Infusionsoft which can easily cost several thousand dollars.
By November, I had completed several projects on a cutting-edge business and marketing automation platform called Office Autopilot. More and more, I’m finding the core features of Office Autopilot outpace the comparable features inside of Infusionsoft.
With the one-click integration between Office Autopilot and UltraCart bringing the cost of my client’s project back down to earth, the client decided to abandon Infusionsoft altogether and migrate to the UltraCart/Office Autopilot system.
UltraCart also has a one-click integration with Office Autopilot’s lower-cost marketing and automation system called SendPepper.
Several of my clients use Infusionsoft’s built-in 1-Click Upsell strategy to sell info products. The process for setting it up is shown in this video from October 2009 on the company’s blog: One-Click Upsells Using Infusionsoft.
Two days ago, I set up an upsell form for a client. We did the exact same thing last year and it worked fine. Today I got a skype note from the client that their launch was successful but none of the upsells got charged! They had to run them all by hand!
What happened?
Well, at about 6:55 into the above video, it says you don’t need to select a Payment Plan when placing an order using an Action Set. So, I left the Payment Plan field set at the default as shown in the video and just as I’d done last year.
This morning, I called Infusionsoft tech support to see what’s up. They said that now you must create and then select a Payment Plan when placing an order via an Action Set.
I checked the help section and found an article called “Add an Order Using an Action Set” which confirms this. Read this article if you’re planning on doing a 1-Click upsell with Infusionsoft (you have to be logged in to the help center).
One of the first lessons I learned about business was how to properly set prices. I believe you should always set prices based on the “profit margin” which is a percentage of the total sale price.
Profit margin can never exceed 100% of the sale price. This is very different from “markup” which is a percentage added to the base price.
Let’s look at the difference:
Using markups can result in what seems to be enormous profits. This is why entrepreneurs who use “markup” get into trouble. They mentally trick themselves into thinking they’re making a big profit.
More often than not, I’ve found that entrepreneurs using “markup” underprice their goods and services to the degree where it becomes difficult to operate their business. I have never seen a successful businessperson who views pricing in terms of “markup”.
Why does this matter? Because everything in a business comes out of the total gross revenues — salaries, operations, costs of goods, and, yes, profits.
If you don’t price your goods and services from the perspective that your profit is subtracted from your gross sales, you’ll always be running short on cash, and you won’t have a common yardstick to measure the performance of different product lines and service offerings.
I think a lot of people use “markup” to set prices because the math is easy. The formula for setting prices based on “profit margin” isn’t so hard once you know it. Rather than multiplying (easy), you divide the cost of goods by one minus the desired profit margin (harder):
cost of goods/(1 – profit margin) = final price
Let’s look at the example above. Starting with the cost of goods ($30), divide by 30% (that’s one minus the 70% profit margin). The result is a sale price of $100 with a 70% profit margin.
$30/(1-70%) = $100
$30/30% = $100
Now let’s try a $50 item with a 30% profit margin:
$50/(1-30%) = $71.43
$50/70% = $71.43
Switching from “markup” to “profit margin” pricing is often my first advice to business clients. See for yourself if it makes a difference for your profitability and your peace of mind!
Mark, thanks for your suggestions on how to raise operating capital to start a charter school. We used one of your ideas to raise a $15,000 low-interest bank line of credit, even though the school had no financial assets or revenues at the time!
Nils Peterson
Palouse Prairie Charter School