I work independently on many web projects, but I also partner up with other companies in various capacities. One of my longest-running partnerships is with Nonprofit Tech, which is now based in Madison, but was my first job when I lived in the San Francisco area back in the early 2000s. We've worked on a lot of different projects with many clients over the years, but one that has been consistent is Consumer Action, a consumer-advocacy organization based in San Francisco. They offer a wealth of information on the laws and industry surrounding credit cards, home buying, privacy, insurance, and a lot of other stuff; and they offer all this in many languages. They're good, and I'm happy to be of service to them.

Their website runs ExpressionEngine, and in the last year they upgraded to the 2.x version. There was a lot of work involved migrating their pretty massive online empire from 1.x to 2.x, because along with having a lot of content, they deliver it over a network of targeted websites (they call them subsites), not just the main Consumer Action website. I wasn't involved in a lot of the migration work, but I did work a lot on their publications store, which we switched from a homegrown system to the Store plugin from Exp:resso. The point of the publications store is to allow registered members (you can become an online member for free) to order printed copies of the publications, and everything is free thanks to Consumer Action's donors and corporate sponsors. We needed the system to support a conventional shopping cart experience, but with all products being free, and being able to use the existing publications channels so there would be no re-entering a bunch of product data. The homegrown system worked, but it wasn't robust, and after researching many options, we ended going with Store, and it did the trick. We migrated the main Consumer Action site to Store fairly painlessly, and got a nice increase in stability.

The trouble came when we wanted to set it up on MoneyWi$e, one of the subsites. Consumer Action uses the "classic" multi-site setup, which predates the current Multiple Site Manager module, to serve its subsites. I'm not as well-versed on the history of ExpressionEngine as I am with other systems, but it's my understanding that the MSM didn't support easy sharing of content between sites (at least not with the editing workflow Consumer Action needed), and that fact, combined with the additional license fee, was enough to keep this website away. Even if using MSM were appropriate (I'm still not sure that it would be for them), the site has become large enough that migrating to the MSM was looking daunting, so it was dropped as a consideration. These days, it seems to be assumed that any set of websites served from a single instance of EE use the MSM, so making this classic setup work with third-party add-ons can be tricky.

It took us a little while to nail it down, but Exp:resso were very helpful throughout the process. Here are the issues we faced and how we solved them.

1. The form action attribute

   One big issue is what happens when the Update Cart button, or other buttons that submit and reload a page, is clicked. Store originally set the form tag's action attribute in such a way that the wrong page would reload. For example, if your subsite is served out of the example_site channel in EE, you might have your cart page loading at a URL like this:

   http://www.example.com/cart

   But with the original setup in Store, your form's action attribute might be set to this:

   http://www.example.com/example_site/cart

   Which, when the form is submitted, would give you a 404 (Page Not Found) error. The solution here was to leave the action attribute empty, which makes sure the page always submits to the original URL. This change went into a subsequent release of Store (I think 1.6.2).

2. Overriding the RET hidden variable

   That fix helped, but sometimes ExpressionEngine finds other ways to take you to the wrong page. On every form it generates, EE adds a few hidden form variables, including RET, which tells EE where to return to after processing a form in the absence of other code. There were times when EE would set RET including the subsite's first segment, like this:

   <input type="hidden" name="RET" value="example_site/checkout" />

   Which wouldn't work in our setup. I really wanted this:

   <input type="hidden" name="RET" value="checkout" />

   If your Store template tag includes a return parameter, Store will include a return_url variable that will generally beat out the RET variable, but on pages that want to reload themselves instead of continuing to a different template (again, like a Cart page), return_url won't win. In that case, you need to add your own hidden RET variable, which will override the one from EE and help you get to the right place. I added it close to the submit button near the bottom of the form, and that worked well.

3. Using initial slashes

   One more note on going where you expect. Sometimes in the form tags, I found that to get here:

   http://www.example.com/checkout

   I'd need to set my return or next attribute with an initial slash:

   {exp:store:product_form return="/checkout"}

   This wasn't always necessary, but it's another variable you can play with if you have issues.

4. Make sure template cache is disabled where appropriate

   Once those issues were nailed down, we had trouble with pages not displaying error messages. We use the inline_errors attribute to keep ExpressionEngine's ugly (but useful… but ugly) error pages out of sight, but the error messages weren't appearing on the forms when required fields were left blank, if an email address was invalid, and so on. In this case, we had template caching turned on for the templates where errors were supposed to appear, and the errors just never showed up. Turning off caching on those templates made everything work great.

I'll say it again: Exp:resso were very helpful in sorting these issues out. There was sometimes a bit of latency in our communications, from both sides, but every response I got back was considered and thoughtful. I always felt like they had genuine interest in helping us solve the issue without just saying "hey, use MSM" or "sorry, you're on your own". Store isn't the cheapest software on the block, so it won't necessarily be an option for everyone, but I don't hesitate to recommend it.