UPDATE: Apparently you need to check that g.Basket:CUST_ID is not equal to zero. At first my solution only checked that it wasn’t null which was flawed.

<mvt:if expr="NOT ISNULL g.Basket:CUST_ID AND g.Basket:CUST_ID NE 0">
    Welcome back, &mvte:global:customer:login;!
<mvt:else>
    Hello anonymous user!
</mvt:if>

Back…

To explain why “Back to the Future” was such an appropriate theme for the conference, let me give you some background. For those of you who aren’t aware, FindWhat.com, a search-marketing focused company, purchased Miva Merchant in 2004. They made a few good moves at first, acquiring MVCool and re-branding it as MivaCentral as well as releasing Miva Merchant 5, but for the next few years they seemed to basically run Merchant into the ground. They alienated module developers, outsourced support, and almost destroyed the community that made it such a success in the first place.

…to the Future

In August of 2007, it was announced that Miva Merchant had been purchased from FindWhat.com (now Miva, Inc) by several of the management team who had worked so hard to make the product a success in the past. Within a month, the new team managed to bring tech support back in-house and drop-kicked the ridiculous outsourced design services that had pissed off the community so much.

The conference? I’m getting to it!

My cohort and I arrived in San Diego Thursday night after a whopping hour on a Southwest flight from Sacramento. After getting our rental car and checking in to the hotel, we headed down to the beach and hung out just long enough for me decide we need to open an MC2 Design, San Diego division and then were off to Thursday night’s mixer where we were given not only a whole bag of schwag, but also free beer and a chance to meet the infamous Baron Bob.

Basically everything I went to the conference to hear was revealed in Rick Wilson’s keynote on Friday morning. During the keynote, Rick revealed Merchant 5.5 and I think you’d be hard pressed to find anybody who attended who wasn’t completely blown away. I’d just like to go over a few of the features that were revealed in 5.5.

• Skins – Easily one of the coolest new features in 5.5 is the skins system. What it does is allow you to completely change the look and feel of your Merchant store with the click of a button. If you are familiar with Wordpress, Miva’s skin system is similar. We will be making heavy use of this feature.
• Dreamweaver integration – Dreamweaver integration was promised years ago, but it looks like they finally pulled it off. The way this works, is you export the pages you’d like to edit and simply open them up in Dreamweaver. From here you can edit Merchant’s templates as if they were simply html documents. In order for this to work you will need to download a free Dreamweaver extension that will be made available via Merchant’s website.
• Completely re-designed interface – The new interface is wonderful. The first impression I had of Miva Merchant was not good and I have to say one of the main reasons was the interface looked like it came from 1992.
• Built-in SEO features – In the past it has only been possible to customize Merchant’s URLs by manually creating a mod_rewrite file. The new version has this built right into the admin interface
• No more black boxes – Every piece of html / smt template code in Merchant 5.5 is editable through the interface.
• Full CSS support – The new version comes with a completely css-based skin and the layout is based on divs instead of tables.
• Simple administration mode has been removed – Simple administration mode was the stupidest feature available and it was on by default. In fact, advanced administration mode is a lot simpler than simple administration mode. It has been completely removed from Merchant 5.5.
• One-page checkout – That’s right. One page checkout is built-in in Merchant 5.5. It is not manditory, but it’s available. I can’t recall if this is a “coming soon” feature or if it is already implemented
• Configurable error pages – All error pages in Merchant 5.5 are completely customizeable
• Unnecessary whitespace removed – If you have worked with Merchant before, I’m sure you are aware of the fifteen or twenty blank lines that are output before any html on every page. While this doesn’t actually make any difference, it is an annoyance I’m happy that I no longer have to deal with.

What is really impressive about all these features is that they were able to pull them off without breaking a single thing. Merchant will be a streamed update and it will not have any effect (other than the updates) on your extisting store(s).

Just to be honest, once I was told they’d be posting slides online, I stopped taking notes. I know there are other features, but I can’t be sure if they’re on the way or if they are included in 5.5. I’ve told you the best of it anyway. I’ll post links to the slides when they are available. Also, as soon as Michael gets me the photos took of us at the conference, I’ll post those as well.

I’d go into detail about the conference sessions, but honestly they were a little lacking. Fortunately the news of Merchant 5.5 as well as the extremely positive experience I had with the new owners were enough to make up for it. The photo to the right is new Executive Vice President, Rick Wilson with Michael. I missed out on getting my photo taken with them because I was discussing code with the dotComHost guys. There is photo of us with those guys on the way.

One small disappointment is that Merchant 5.5 was not released on the day of the conference as was expected, but this is actually a good thing. The new owners decided they weren’t going to release the new version until it has been thoroughly beta tested and documented. These are two things past versions really could have done a better job of, so it’s good to see them learning from their mistakes.

Leslie Nord of eMediaSales has posted tons of photos of the event, so go check ‘em out!

UPDATE: Pamela Hazelton of Design Extend has written an article along the same theme as this one, only better. Check it out.

According to Miva’s “store-morph” documentation:

When stepping through an array, in a foreach loop, the current position in the array is given by the pos1 variable.

With this information, we simply use the modulo operator while we’re stepping through an array to decide whether or not we’re on an even row.

<table id="basket">
 
  <mvt:foreach iterator="item" array="basket:items">
 
   <!-- if pos1 MOD 2 = 0, then this is an even row because pos1 is divisable by two with no remainder -->
   <mvt:if expr="(pos1 MOD 2 ) EQ 0">
    <tr class="even">
   <mvt:else>
   <!-- otherwise it's an odd row -->
    <tr class="odd">
   </mvt:if>
 
      <td>&mvt:item:name;</td>
      <td>&mvt:item:price;</td>
 
    </tr>
 
  </mvt:foreach>

Now all that’s left to do is style the rows with css:

#basket tr.even {
    background-color: #eee;
}
#basket tr.odd {
    background-color: #ddd;
}

Any questions?

Miva Small Business Solutions has been purchased from Miva, Inc. by a management team lead by Russell Carroll, who will serve as new CEO for the enterprise, and former Miva executive Rick Wilson, its new Executive Vice President. Rounding out the team are Mark Johnson, VP of Development, and David Roquemore, VP of Technology.

Russ Carroll stated “Our entire focus will be on improving our customers’ experience by concentrating on our core products, enhancing our hosting partner relationships, and supporting our developers.”

Executive VP Rick Wilson added, “As an example of our customer-centered focus, we will be transferring support in-house as quickly as possible. This will dramatically improve service levels as well as strengthen the feedback mechanism from our client base.”

This is excellent news for the Miva community. There has been a lot of speculation lately about the possibility of the company going under or being bought out. The fact that it was bought out by a team that knows the product and the company is an excellent sign and shows that they see value in the product and the userbase.

Right away we’re seeing big changes, as today they announced they are bringing their customer support back in-house after outsourcing it to who-knows-where for the past year or so.

According to support manager, Wayne Smith:

Building our customers trust in the quality of our product support is my single objective here at Miva Small Business. We’re focused not just on providing support but providing the most competent support for our products possible. Please bear with us as we complete building the team back home in San Diego. While we might have to schedule callbacks with our customers during peak hours, the tradeoff for excellent support is an easy choice.

Read the entire press release.

Let me write my own HTML

It’s bad enough the Miva Merchant itself doesn’t allow me 100% control over my HTML without module developers doing the same thing to me. Miva and its third party module developers have proven time and time again that they are completely incapable of writing HTML from this decade. I am thoroughly sick of seeing tag soup like the following when I render a Miva module component.

<BR><TABLE border=0 cellspacing=0 cellpadding=0 nowrap>
<TR>
<FORM METHOD=POST ACTION="http://www.example.com/shop" name="ch">
<input type="hidden" name="Screen" value="OINF">
<input type="hidden" name="Store_Code" value="EX">
<TD>
<INPUT CLASS="ch_text" TYPE="submit" value="Checkout">
</TD>
</FORM>
</TR>
 
</TABLE>
<BR><BR>
<TABLE border=0 cellspacing=0 cellpadding=0>
<TR>
<FORM METHOD=POST ACTION="http://www.example.com/shop" name="cs">
<input type="hidden" name="Screen" value="PROD">
<input type="hidden" name="Store_Code" value="EX">
<input type="hidden" name="Product_Code" value="1501T">
<input type="hidden" name="Category_Code" value="women">
<input type="hidden" name="Search" value="">
<input type="hidden" name="Offset" value="0">
<TD>
<INPUT CLASS="cs_text" TYPE="submit" value="Continue Shopping">
</TD>
</FORM>
</TR>
 
</TABLE>

Not only does code like this make it impossible for me to have a w3c-compliant website, it also limits me in many ways. What if I don’t want to post to the page you have so boldly assumed I wanted to post to? Now I have to get another third party module just to fix the mess you made for me. What if I don’t want some of the input elements you have forced me to use? In this case, I’m just plain screwed. If your module needs to render HTML code, let the developer have access to this code.

When developing modules for version 5 or higher, use the template system that is already in place

Don’t provide me with some archaic, proprietary “token” system. There is a half-way decent template system in place in Merchant version 5 (or higher) for you to use, so why reinvent the wheel with your own, less flexible system? I realize that some of this is just left over from version 4 modules, but if you’re going to develop modules, there’s no reason you can’t update the template system, which brings me to my next point.

Update your modules!!

There are so many module developers out there who create a module and never address it again. There are several modules that were created for version 4 of Merchant that still (it’s been about 2 years) have not made the port to version 5 (attribute upload anyone?). Why is this? It can’t be that difficult to update your modules.

Don’t require javascript for your module to work properly

There is absolutely no reason for you to require that javascript be enabled for me to use your backend module. Now, I can understand the requirement of javascript in the case of something built for the front end, but even in this case, the javascript should be loosely coupled enough that it isn’t really required. Take for instance the thickbox component we use on several of our ecommerce sites. If javascript is enabled, it allows for a very nice modal-like experience when you want to see an enlarged photo of a product, otherwise, it just takes you to the larger image via http (view in browser).

Gee, your module is very useful, but the interface looks like hell

This is the most common thing I see in not only modules, but Merchant itself. Merchant’s backend is hideous, and to go along with it, so are just about all module interfaces. Is it a requirement to create ugly interfaces in the Miva community? 

Well, that’s my list. What irritates you most about Miva modules?

All available CGI environment variables are automatically converted into static MIVA Script system variables upon start-up. All HTTP headers are saved in environment variables and therefore are also converted to MIVA Script static variables.

So why is that bad?

The problem is that many of the CGI environment variables come directly from the user, meaning if you use them incorrectly or carelessly, you open yourself up to all kinds of malicious attacks. One such attack is called a cross site scripting or XSS attack (a form of script/code injection). This type of attack is very common, and you would be surprised just how many sites leave themselves vulnerable to it.

A website is vulnerable to XSS attacks if it accepts input from the user (this can be through the url, through a form, etc.) and then outputs it unchecked and unmodified. For example, on a search form, generally a web developer will repopulate the search textbox with the term the user searched for. Something like the following:

 <mvt:if expr="NOT ISNULL g.search">
 
  <h1>Product Search</h1>
 
   <form method="get" action="&mvt:global:sessionurl;"> 
    <label>
     Search For The Following Word(s):
     <input type="text" name="search" value="&mvt:global:search;" />
    </label>
    <input value="Go" type="submit" />
   </form>
 
 </mvt:if>

With that code, user input is outputted to the html page, completely unchecked and unmodified. This means that a malicious user (let’s call her Mallory) could inject html code into your script (since she is allowed to enter characters such as < and >). If Mallory can inject html code into your script, I wonder what else she could inject in there. What if she entered something like the following?

" /><script>alert('Insert Malicious Javascript Here');</script>
<input type="hidden" name="irrelevant" value="

With our existing template code, that would result in the following html being output to the browser:

  <h1>Product Search</h1>
 
   <form method="get" action="http://www.example.com"> 
    <label>
     Search For The Following Word(s):
     <input type="text" name="search" value="" />
<script>alert('Insert Malicious Javascript Here');</script>
<input type="hidden" name="irrelevant" value="" />
    </label>
    <input value="Go" type="submit" />
   </form>

Now, because Miva Merchant converts all environment variables to SMT entities, whether they came from a form via POST or from the url (via GET), Mallory can attach her malicious javascript code to the end of a URL and trick some unsuspecting victim (we’ll call him Adam) into clicking on it (perhaps through an email forged to look like it came from your website). Adam clicks on the link, and logs in, and now Mallory’s malicious script has access to Adam’s session and therefor, Adam’s account information.

Preventing cross-site scripting

In many languages, to prevent this sort of attack, you simply escape user-submitted content before outputting it again. This is generally done with some sort of function. For example, in PHP you would use a function such as htmlspecialchars or htmlentities. This is not necessary in SMT templates, because Miva has taken the liberty of providing 3 versions of every one of these variables for you.

From Miva’s documentation:

Entities start with &mvt, and can have an optional additional character, either an e, or a, for entity encoding or attribute encoding, respectively.

Entities beginning with &mvt are replaced directly in the HTML code with the information they represent. So in bgcolor=”&mvt:colors:lhdr_bg;”, the entity would be replaced with the actual list header color number in hex, giving bgcolor=”#000080″.

Entities beginning with &mvte are “entity encoded”. Their values will be formatted to appear on the screen, with any special characters being displayed verbatim (“as is”), rather than being interpreted according to their special meaning. If the entity you want to display includes the “<” character (“less-than” sign), entity encoding will cause that character to appear, unchanged, on the screen, rather than being interpreted as the beginning of an HTML tag.

So, to sum up the documentation, if you are going to be outputting any kind of variable to the screen, you would use the &mvte prefix. This way, special characters such as < and > would be escaped, so the user cannot inject scripts into your code. So now, let’s adjust our code from up above so that it is no longer an XSS vulnerability. To do that, we simply change the entity prefix from &mvt to &mvte. Pretty painless!

 <mvt:if expr="NOT ISNULL g.search">
 
  <h1>Product Search</h1>
 
   <!-- this variable does not need to be escaped -->
   <form method="get" action="&mvt:global:sessionurl;"> 
    <label>
     Search For The Following Word(s):
     <!-- this user-supplied variable does -->
     <input type="text" name="search" value="&mvte:global:search;" />
    </label>
    <input value="Go" type="submit" />
   </form>
 
 </mvt:if>

With this modification, if Mallory were to try the same attack, it would result in the following (completely harmless) html being output to the browser.

  <h1>Product Search</h1>
 
   <form method="get" action="http://www.example.com"> 
    <label>
     Search For The Following Word(s):
     <input type="text" name="search" value="&amp;quot; /scriptalert&amp;#40;'Inse" />
    </label>
    <input value="Go" type="submit" />
   </form>

Miva also supplies a third version of every SMT variable for use in a URL.

Entities beginning with &mvta, are “attribute encoded”. That is, their values will be formatted so they can be included in a URL, with any special characters being transformed into characters that can be understood by a web browser. For instance, you have probably seen attribute-encoded characters in URLs, such as space characters that are represented as %20. When a category name, for instance, is to be included in a URL, and may contain characters that would require this special formatting, use &mvta.

Places where you may not suspect you need to use escaped entities

There are several Miva Merchant modules out there that allow you to assign your own variables within the template. For example, Emporium Plus’s (exremely useful) toolkit module. Let’s say you want some promotional text to be available on several of your miva templates. With the toolkit module, you simply create a variable within your global head tag with the following template item:

<mvt:item name="toolkit" param="sassign|promotext|One day only! 15 foobars for $1" />

Now, you put the &mvt:global:promotext; in your global header, and only the pages with the toolkit item assigned to them will now render this text, right? WRONG! Because Miva Merchant converts all environment variables into global SMT entities, your script is now open to XSS attacks again. Mallory simply has to craft a link like the following and get Adam to click on it.

Hello Adam, <a href="http://www.example.com/mm5/merchant.mvc?Screen=ACNT&Store_Code=YOURSTORE&
promotext=%3Cscript%3Ealert('malicious%20code');%3C/script%3E">Log in to your account</a>?

Since you didn’t assign the toolkit module to the ACNT screen, and you outputted the value of the promotext variable without escaping, your site once again has an XSS vulnerability.

So, what have we learned?

First of all, never trust user-submitted data. Secondly, you need to be paranoid about outputting any kind of data, unescaped to the browser. Even if it seems as though it couldn’t have been tainted by the user, think of it from all angles.