Website Update! New CMS and Tessitura Integration

Hello Hudson,

I have a few thoughts, some of which may run contrary to the common practices of the Tessitura community, but hopefully it steers you to some helpful considerations.

First of all, using Wordpress as a CMS would require communicating with the SOAP API via PHP.  Although it's possible to do so, the standard PHP SOAP libraries aren't fully compatible with the Microsoft-proprietarily formatted data returned by the SOAP API.  This will increase complexity and required coding time.  Perhaps someone has accounted for this incompatibility over the past few years, but it's something to inquire about.  I recommend considering the .NET platform as an alternative to PHP.  For better or for worse, the Tessitura community favors .NET, and Tessitura's documentation targets .NET almost exclusively.

On .NET as on any platform, beware of "big enterprise" CMSes.  These corporate-focused products want to do a lot more than manage content, and this results in heavy-handed control over the implementation of your website.  They're expensive, they have limited community support, and they get in the way at every turn.  We're stuck with one such CMS (Kentico), and it's a total nightmare.  As an alternative, I recommend a lightweight CMS such as Umbraco or Orchard.

A word on vendors:  Be vigilant about code quality!  I've seen at least four examples of website code delivered by a couple of Tessitura's most prominent vendors, and each has been an unmaintainable mess of violated engineering best-practices.  This translates to bugs, inhibited (slowed) developer productivity, and inflexibility when adding new features.  Tessitura organizations should demand websites that are built to last.  Instead, they buy into a wasteful and unnecessary cycle of rebuilding from scratch every few years.

An alternative to vendors is to hire a small, in-house team of web developers.  These developers are dedicated to your mission, cultivate familiarity with your business model, and are more likely to write code that they want to live with.  This can easily cost less and yield a higher quality web site product.  If your organization can hire a team of 3 or more people for marketing, or for press, or for maintaining a box office (for example), then it should hire a team of at least 3 people to maintain and innovate on your virtual storefront.

Finally, whether you're working with a vendor or in-house team, familiarize yourself with the principles of Agile software engineering.  Help your organization resist the urge to build a monolithic, "complete" set of features up-front.  I recommend reading Chapter 3 of the book, Essential Scrum (http://amzn.com/0137043295).

I hope this helps!  Please feel to reach out if you have any questions.

Bryan

Hey Bryan,

Thanks for the awesome advice! Interesting points about the SOAP API. Got any links where I can do a bit more reading on that subject? 

I hear you 100% about the CMS nightmares. We have a custom-built solution that's not a solution, and I'm dead-set on not letting that happen again. And alas, I don't think we're ready for a team of web developers, but it would be a very welcome addition.

Again, thanks for the tips and taking the time!

Actually, as I'm looking around on these forums, it seems like people are having better luck with PHP than I did five years ago.  Search for PHP on this site and you can find a few examples.

If you're stuck with outsourcing to a vendor, then I would recommend coming up with some standard for code quality.  Unfortunately, this is a bit like putting your faith in a car mechanic.  This has come up recently in a conversation at my organization.  Unit tests (with a high percent code coverage) and integration tests are a good indicator of code quality.

One little comment on this great post from Bryan,

SOAP API compatibility may be less of a concern these days, purely out of the fact that it is on its way out, to be eventually superseded by the REST API. (Only the REST API is under active development for new features.) Something to consider also about choice of CMS is that Wordpress is near ubiquitous and there are many more programmers out there that have experience with it.

Also noting that you mentioned TNEW in your original post -- I believe the session key sharing is a feature that the Yale consortium uses extensively, so you may want to talk to them if you are planning to integrate TNEW with your own CMS.

Yes yes. This is just the type of information we were hoping for. Thank you, Nick, for further clarification.

Hello all!

On the PHP and SOAP API front, we've had a number of sites use PHP successfully and the typical approach is to use the standard SOAP API and if you run into any issues parsing the XML, to move to the Tessitura Simple Type API (simple type bypasses the XML formatting and outputs as a string).  That said, it's probably true that the SOAP API is most natively used in .NET applications, however that doesn't mean other platforms can't use it well and do.  (And of course as Nick points out, with the ever-expanding REST API, this makes an even more agnostic coding landscape in future.  We've focused the REST API development thus far on new features, yes, but a major focus of V14 will be to 'restify' the existing ground that SOAP covers now as well-- transactions, seat map data, etc.)

Regarding TNEW and CMS integration, there's no imperative that you use an external CMS for a TNEW site but it can be helpful in managing the non-TNEW portions of your site and a number of TNEW sites do this.  There are some great CMS-driven sites out there in the TNEW world and we can talk with you about firms we've seen do good work on this front, across a range of CMS tools, if a reference is handy.  Just submit a TASK ticket to line that up.  

Finally as a side note which is part of the whole "how do I best integrate TNEW to build a stunning and powerful website for my organization?" equation, with TNEW V7 coming out next year, we'll be not only building TNEW to work on all devices (mobile, tablet, etc) but also revamping the way web developers can extend and nuance page look and feel via CSS (cascading style sheets).  Don't know what CSS is and don't care?  No sweat!  We will still continue to skin your TNEW site out of the box to look like your existing brand as we always have.  The V7 work we're doing on CSS will just allow those who want even more control over look and feel to do it more efficiently than today. 

Hope this helped fill in some gaps--

Kristin 

"... with TNEW V7 coming out next year, we'll be not only building TNEW to work on all devices (mobile, tablet, etc) but also revamping the way web developers can extend and nuance page look and feel via CSS (cascading style sheets)."

!!!!!

I just fist-pumped while sitting at my desk! Quick question for you, at the risk of derailing this thread: will you be namespacing all of TNEW's CSS rules in the new version? I've certainly run into rule collisions in the past with our hosted template that have subtly messed up the layout and formatting of certain pages.

Well, we're all for fist-pumps around here.  

The simple answer is yes on the namespacing.  Also, we will be using bootstrap as our core framework for building the user interface and we plan on namespacing the bootstrap CSS as well.  

It's early days in the project now so this will evolve but that's what we've discussed/ are planning on at this point.

Hi Hudson - I'm not sure where you are in your process now (I'm a little late to this conversation) but we just launched a new website with Wordpress and TNEW and I'd be happy to answer any questions you may have. And, we did find a way to load in some custom css and javascript on the TNEW pages where we wanted to adjust a few things. We're also using the shared session if you have questions about how that works.

My main advice to you would be to understand your organization's size and needs and make sure you choose a CMS that matches that. There's lots of talk about the best CMS for this or that but with so many choices out in the marketplace, you should find one that fits YOUR needs. Can you afford a CMS that charges $15k a year in license fees, or do you need something a little more ubiquitous because you'll be working with various freelance web people over the years.

And having TNEW taking care of all your e-commerce stuff, you're freed up to make an awesome website and not have to worry about building or buying transaction paths.

Hi Josh,

Quick question: We are in the process of setting up TNEW and I'm having issues with the <!--TNEW content here--> tag being stripped from our template. I've tried coding it right into a custom WP template and I've tried placing it in a WP page (HTML view) but with every method it gets stripped. I tested a static HTML version of what the rendered WP template should look like and in that instance the comment tag remains intact. It's evidently an issue with either WP itself or our server/PHP configuration, but I frankly don't know where to look.

Do you have any insight on this?

Hi Chuck,

We did get around that problem, but we use TNEW as the cart only, and skip the default.aspx page and the calendar (we do the marketing pages and calendar on our TLD). By using TNEW as just the cart, we can minimize the navigation and keep the purchase funnel directed toward order completion page.

That said, we have an Expression Engine TLD (not Wordpress) so I can't speak to the specifics of Wordpress itself. But we avoided the complexity of deconstructing the PHP by creating a flat file of plain old HTML and then putting that file in a directory of our TLD (we named it /tnew). Our TNEW then calls this flat file.

http://artisnaples.org/tnew/

The advantage of this flat file is that when TNEW calls it, it loads very fast. It avoids the CMS which cuts down on the number of processes and data calls necessary to create the page.

Since we minimized the navigation, we do not need to update this file often. We do, however, call all the same css and js files in the HTML that are found on the CMS pages in order to keep the "look and feel" across the TLD and the cart consistent.

Thanks, Andrew.

I think the route you describe in your last two paragraphs will be the route we go, as well. I haven't been able to get an answer to the Wordpress/HTML comment tag from either Googling or from Tessitura, and I'd already built a flat HTML file anyway. Not ideal, but we'll at least still be hosting our own templates/stylesheets.

Unknown said:

Thanks, Andrew.

I think the route you describe in your last two paragraphs will be the route we go, as well. I haven't been able to get an answer to the Wordpress/HTML comment tag from either Googling or from Tessitura, and I'd already built a flat HTML file anyway. Not ideal, but we'll at least still be hosting our own templates/stylesheets.

Chuck-

I have found that there are reports that Visual Editor (the base editor of Wordpress) removes HTML comments. If you have a test site I would try to disable the visual editor for the page you are trying to add the comment tag to.

https://wordpress.org/plugins/disable-visual-editor-wysiwyg/

Christopher,

It removes them when entered in the HTML editor, as well. It also removes them when they are added directly to the PHP template file. It's not a server thing, because I can create a PHP file outside of Wordpress and it'll retain the HTML comment tag, but if it's within WP, it gets stripped regardless of the method used.