We recently completed a website project on behalf of our partners at Foxhollow Farm to combine their separate websites for delivery and pickup orders into one. You can read more about our UX solutions and results of the project in our case study. In this journal article however, we wanted to outline some of the development solutions that made this project possible.

The biggest issue when merging two systems is that you have data in different formats in different places, even if it is being used for the same purpose. In Foxhollow Farm's case, we had product data in WooCommerce and Shopify, with additional subscription data in Shopify. VIA Studio intended to merge everything into WooCommerce; this meant we had to move all the subscriptions from Shopify. In addition, one site used Stripe, and the other one used Authorize.net. 

, we were able to set up subscriptions in WooCommerce. The plugin also offers an 

, which can import a formatted CSV with subscriber data. On the Shopify side, Foxhollow Farm was using a tool called ReCharge to manage the subscriptions. 

 offers an active subscriber export, which we used to create a CSV of all the existing data. From there, we did some data massaging to only include the fields we need to import into the Subscriptions plugin. In order to be able to bill customers again, we had to pull the client ID and payment ID from Stripe as well.

Once that data was in the WooCommerce Subscriptions plugin, the subscriptions ran seamlessly, and customers continued to have their subscriptions fulfilled with no interruption on their side. Existing subscriptions use the existing Stripe token to authorize payments while new subscriptions use Authorize.net, to match the rest of the site.

Now that both pickup and delivery products are served through one website, the normal checkout flow provided out of the box by WooCommerce is inadequate. For instance, pickup products do not have shipping, however, they have pickup times and need to be noted multiple times during the checkout flow so the consumer knows this. Another example would be that some delivery products are only available for certain zip codes and there are also instances where both types of products would be in a user's shopping cart.

With this in mind, the design team came up with single page, multi-step checkout experience that informs the user of the shipping information (pickup times, actual shipment information, etc..) and makes everything clear and concise.

VIA Studio partnered with Fox Hollow Farm in Kentucky to improve user experience on their eCommerce shop.

Fox Hollow Farm eCommerce Site

To do this, development-wise we created two different portions - the slideout cart that uses ajax to update cart amounts and products and the actual checkout template. The checkout page is able to include all the required information at page load in tabs, with validation in between each tab step. The backend contains logic for the different use cases of product types.

 to help manage orders. With it, adding new order statuses became something the Foxhollow Farm team could do, and it even has the ability to customize emails sent when the status is changed to the new status. We also customized the existing emails to better reflect the different product types and their delivery or pickup methods.

While these solutions all primarily impacted the website's backend and eCommerce and payment platforms, it is what made the task of combining two website experiences into one, consistent experience possible!

Want to learn more about this project? Check out the UX case study!

Back-end development does all the heavy lifting behind the scenes. From database design and deployment to writing application programming interfaces (APIs) to simply storing and serving your content, we’ve got you covered.

Backend Development

Websites are the cornerstone of marketing in this day and age. Your website is the place where you have ultimate freedom to express your brand and interact with your audience and customers how you’d like. Using agile, user-focused strategies and design, we build highly accessible, highly useful websites that meet your goals.

Websites

Custom Dev

Development

Development Solutions for Foxhollow.com

As a front-end developer in 2020, it is time that I fulfill the FEDeral mandate that I publish words regarding the JAMStack. If you follow too many developers on Twitter, it’s likely you’ve heard about the Next Big Thing in web development, but I’d like to put this trend (fad? movement?) into context to better understand what’s truly new about this approach and whether it’s worth using.

VIA Studio uses the JAMstack to build user-friendly websites.

JAM Web Development

What even is a stack? You may have heard the term “full-stack developer” and know it refers to someone who does both frontend and backend work, but what is the actual stack? A stack — in the web development world — describes the combination of tools being used to host, serve and render a web project. Traditionally it has four components: an operating system, a server, a database and a programming or scripting language.

Let’s look at a couple notable stacks in recent history.

The LAMP Stack comprises Linux, Apache, MySQL and PHP. This is 

 stack of the early 2000s, and due to its ubiquity it will be around for many years to come. Notable LAMP sites — include Facebook (which has since migrated away), Wikipedia (technically using MariaDB rather than MysQL, for the record) and Yahoo (remember Yahoo?). Most importantly, though, is Wordpress, which powers something like thirty percent of the web and is almost certainly the biggest reason for the average person to build a LAMP stack site in 2020. Because of its history and popularity, though, there is a huge community of developers with LAMP knowledge, and it’s very easy to find affordable hosting from almost any provider.

As you may have noticed from the lack of an acronym, this is not a stack per se, but it is a highly opinionated web framework that became a popular alternative to the LAMP stack architecture in the mid-to-late 2000s. It is database agnostic, so you could still use a MySQL server, but Rails itself generates models, controllers, tests, database migrations, etc. and famously enforces the Rails method of application building. Github is a notable example of a Rails site. To this day, if a company is building a monolithic server-based website, it will likely choose either Rails or a framework it’s inspired, like Laravel for PHP.

Arguably the JAMstack of 2014, the MEAN Stack comprises MongoDB, Express.js, AngularJS, and Node.js. As is apparent from all those suffixes, this stack is JavaScript all the way down. The advent of Node.js, a Javascript environment that allows the language to be used anywhere, not just the browser, opened the door for a new era of web development where the full stack could be written in one language. Innovations were being made on the backend with NoSQL databases like Mongo, and the Javascript framework wars were beginning with Google’s Angular and Facebook’s React. (At the time, Angular had the edge. Since then, the frontend community has largely unified around React as the framework of choice, which contributed to the decline in popularity of the MEAN Stack.)

This is very much not a stack but feels worth mentioning as it’s a trend that feels transitional between the MEAN Stack and the JAMstack. With the popularity of React and its tool Create React App, as well as libraries like React Router, a client-side routing tool, many developers began creating sites that were completely client-side: a single index.html with a React application container that simulates a multi-page application without any server-calls or page changes. But while this is useful for interactive web applications like drawing tools, for more traditional websites it meant abandoning server benefits like SEO and resulted in extremely large Javascript bundle sizes.

From a stack perspective, the OS has been replaced by a CDN, the web server has been replaced by serverless functions, the database is optional, and JavaScript is the only required language. Like Ruby on Rails, this approach relies one one tool: the static site generator.

A static site generator is a tool that pre-renders web pages from a combination of markup and Javascript and will usually also perform code-splitting and other optimizations on the codebase. By pre-rendering the pages, the files can be served statically from CDNs rather than having to be rendered at runtime by a web server.

There are many tools available, depending on your language of choice. For true versatility, use something like 

 to take any type of markup — Markdown, Liquid, plain old HTML — and generate static pages without the need for a Javascript framework. Similar tools are 

For those who have a Javascript framework of choice, each big framework has its own choices for SSGs. For React, Gatsby is a popular choice for generating static pages from a React application and has an ecosystem of themes and plugins to choose from. NextJS can do the same but is notably more than just an SSG. On a page-by-page basis, it can either generate a static page or server-render it, providing extra options for those who want the speed and simplicity of static pages without sacrificing the benefits of server-rendering for pages that need it.

The core concept behind JAMstack is that almost any functionality you would need from a server has an API available already. Need CRUD for your MySQL database? Use 

 to generate a GraphQL endpoint for it. Authentication? Use 

. CMS? Well, that’s a whole other blog post, but 

. These are usually referred to as "headless" services, as they have been decoupled from the front-end.

For anything else, use Netlify’s serverless functions or NextJS’s API routes to spin up a little endpoint that handles what you need on the fly.

So should you start building all your sites with the JAMstack? As always, It Depends. Let’s take a look at some of the key decision points.

Static sites are extremely fast. Pages. Unfortunately, they can be very slow to build. If a site has thousands of pages, an SSG generally has to generate every single one of those pages every time the site is built. This can take a long time and severely hold up deployments. Fortunately, features like NextJS’s incremental static page regeneration allows for a hybrid approach where some pages can be generated at build time and the rest aren’t generated until they’re requested.

Some may also argue that static page speeds can be replicated by simply putting Cloudflare’s CDN in front of a Wordpress site, for example, but it’s nice that the speed is there out of the box rather than requiring the setup of a CDN or caching solution on top of the site build.

A common complaint about Wordpress is that they are vulnerable to hacking attempts. This is not so much a problem with Wordpress itself as it is with the fact so many websites are built with it. But the reality is that because JAMstack sites don’t have a server, there isn’t really anything to hack into. And because data fetching can be done in serverless functions, you can also avoid exposing API tokens like you might in a fully client-side site.

On the other hand, you have to put a lot of trust in the services you’re relying on, especially for e-commerce, so it’s important to vet all of your APIs and not rely on the lack of a server for solving all of your security problems.

This is arguably one of the largest benefits of the JAMstack. Static site generators generally have great build tools that enable features like fast refresh, code splitting and ready-made development environments. There is generally very little setup required to get a project started, and libraries, APIs and build tools can be added as needed, if needed. Frameworks like NextJS will handle things like Webpack and Babel configurations, routing, and enforcing best practices for front-end development, freeing up developers to Just Write Code. The only risk here is getting greedy and simply writing too much of it! It’s tempting to use every library out there and end up serving way too much Javascript. But when used responsibly, you can painlessly create great front-end experiences.

Monolithic approaches like Wordpress, Ruby on Rails or Laravel are still extremely useful for developers or teams with a need for fully custom backends or simply want to use a tried-and-true approach with endless resources and hosting options. For developers who want to quickly spin up fully custom marketing sites, ecommerce shops and blogs to deliver rich frontend experiences without needing to build custom servers, the JAMstack is an exciting new methodology that provides great experiences for both developers and users.

HTML, CSS and Javascript form the "presentation layer" of modern web development in your mobile and desktop browser. These things together are considered "Front-end Development". The tools, techniques and standards are changing all of the time - but our development team is always staying abreast of the latest. For our partners, we do the research, experimentation and testing needed to make sure your audience has an accessible, fast, reliable experience.

Frontend Development

While we have wide and varied development expertise and experience the core of our development skill is with PHP, Javascript, Vue and React, allowing us to maintain and develop new features for 80% of all websites on the Internet. That said, we regularly explore new and useful platforms to stay ahead of the ever-changing development curve.

PHP, Javascript & React

What's the JAMstack?

 is a plugin that allows Wordpress to render files written with 

, a PHP template engine. We built a recent project with it and found that it greatly simplified the theme-building experience. Let's dig into why Timber is so useful for building Wordpress sites and how you can get started with it.

If you’re a Wordpress developer, you’re probably familiar with this:

™️ in use. This is how we access a post in a template and make its data available for rendering. You'll notice a few things common to most Wordpress templates: switching between PHP and HTML code frequently to access and arrange data, calling several Wordpress functions to check for the availability of and access post data and using Wordpress functions to render HTML.

Here's how we can do the same thing in Timber:

Ooh! At a glance, it's much easier to read, but let's dig into some of the benefits of using Timber: improving the readability of template code, separating data accessing from our templates and generally offloading a lot of the tedious work of Wordpress.

And that’s important! I’ve been building Wordpress sites for a little while now, but every time I open a Wordpress template file my brain shuts down for a second. It's usually either a mess of interspersed PHP and HTML blocks with Wordpress functions that seem to span entire lines of code or the mess has been abstracted into other files that you have to dig through to get a clear picture of the architecture. Both of these scenarios make it difficult for a developer who’s new to the project (or yourself after going on vacation!) to understand how things are set up and get to work.

A big contributor to the clunkiness of Wordpress templates is that the data fetching and arranging are being done right alongside the templating. In Model-View-Controller terms, the template file is acting as both the controller and the view.

Timber allows us to use the PHP files as controllers that fetch and arrange the data and then pass them as variables to the views: Twig files.

In the example above we only need the post object, which as we'll see later is often available automatically. But what if we need derived data? Let's say we have a Product post type, and on a certain page we want to display all of the products, as well as all of the categories and the lowest price item.

In traditional Wordpress, we would need to write and run all of these queries and make the necessary calculations inside our template alongside the actual display code. This can result in messy files with business logic interspersed in our view. But in Timber, we can grab all of this data and simply pass it to the view as variables, so we don't have to include any query code in the template.

Now in our Twig file we can simply reference {{ cheapest_product.meta('price') }} and not clutter up the view with any math.

As we've seen, we don't need to bother with The Loop anymore! We can grab the data we need in the PHP file and treat them like normal objects in the view.

Often, the post is the only object we need in context, so we don't even need to write PHP files! By using 

, we can just use page.php as a catchall, so we can just create a page-example.twig, and it will be routed through the already existing page.php and automatically get the post object without us having to do anything!

Timber also adds other shortcuts for doing basic Wordpress things. For example, there's no need to remember all of the Wordpress functions for accessing different post data. Instead of remembering whether it's get_the_thumbnail() or get_the_post_thumbnail() or if you actually need wp_get_attached_image() or maybe get_attached_media() — quick quiz: which one of those doesn't exist? — you can just call {{ post.thumbnail }} anywhere in your Twig template. No need to remember all those functions! And if you ever forget what data is available in the object, you can just use the debugging tool covered below to easily find it.

Random Cool Things Timber and Twig Can Do

Let's take our single.twig example above and convert our featured image to webp on supported browsers and to JPEG on non-supported browsers.

If you use ACF, working with Timber is an absolute dream. Let's say we have a page with a Repeater field that contains an indefinite list of employees: an image, a name and an email.

The resulting field will be displayed on the Employees page for data entry. Now to render the content in the page. How would this work in PHP?

Again, no need to worry about remembering function names! All of our ACF data is stored in the post's meta property, and the repeater is just an array that we can loop over.

Ever get stuck trying to figure out what exactly is in a variable you're working with and try the ol' var_dump($variable); die(); only to be presented with a page-long string of characters that allegedly contains the value you're looking for?

An unwieldy output from PHP's var_dump function

, simply calling {{ dump(variable) }} will output a nicely formatted block of code to investigate. This is great for debugging the data that's available in a template's context. And nothing has to die()!

The nicely formatted output of Timber's dump function

So you're convinced! Where to begin? Let’s assume we’re starting from scratch. While Timber can be installed and applied to an existing theme incrementally, beginning with the starter theme will get you up and running very quickly and help you learn the fundamentals you’ll need to start picking and choosing which pieces you want to use.

First, make sure you have a Wordpress installation. Then, grab the 

. Download it, unzip it, and add it to your wp-content/themes directory. Now run composer install in the theme to install Timber.

Note: While Timber can currently be installed through the Wordpress plugin directory as well, that option will be removed in the upcoming version 2, so go ahead and get comfortable with the Composer method.

Now activate the Timber plugin and then the theme, and you’ve got a working Timber installation!

You already have pages here that should be getting post data. Now let's create a custom page. In Wordpress create a new page named My First Page. It should have the slug my-first-page.

Now create the file page-my-first-page.twig. Copy the contents of page.twig over, customize as you'd like and now when you visit My First Page you should see your template!

You can now start adding content and ACF fields and render them in your new template. 

 for additional options for setting this up.

We strongly believe in open-source technologies. Our CMS of choice is WordPress, not just for its ease-of-use, but the large community that pushes its development to new and exciting places. Active in the Wordpress community, we also develop 

WordPress

Building a Wordpress Theme with Timber

When planning the KPA ticketing app, the first big decision was deciding which technology stack to use

Given the complex and highly-interactive design, we needed something that was going to be developer-friendly while letting us build an application that was highly responsive to user interactions. Nothing’s more frustrating than a slow user interface!

VIA has mostly standardized on ReactJS for smaller interactive user experiences as well as single-page web applications so it seemed like a great fit, even though the ticketing app is just a small (but critical!) piece of a much larger site.

The other advantage to developing the ticketing portion of the site as an almost stand-alone app is that development on the rest of the site could continue in parallel. The more simultaneous work happening, the better!

React’s power comes from the way everything is divided into components which are displayed on a page. Once a component is identified, it becomes trivial to use it in multiple places on a page without having to write a bunch of extra code.

For example, we created a component for a single seat in the list of all available seats. This was great because seats that had been added to the user’s cart had a very similar design, albeit with slightly different data. This component-based architecture let us have all the shared code for that seat layout in a single place, even though it was displayed in multiple locations.

An additional benefit of using components is it makes it easier to allow multiple developers to work on the project at the same time.

The ticketing app was, understandably, quite data heavy. We need to store lists of available seats, seat map data, pricing information, promo codes, shopping cart data, venue information, etc. This data was constantly being updated as people selected seats or filtered based on pricing points or seating sections.

Luckily, this is another use-case where React shines. Leveraging an additional tool called, Redux, we can easily store all of the data used by the site in a single data store. Then we can set up our different components to pull data from that store. When data in the store changes, the components using that data automatically update themselves. All of this changing and updating is blindly fast because React is very good at only updating the components that have actually changed. No need to refresh the entire page!

For example, let’s say the user wants to filter seats to a certain price range. We can build a component which lets them select the prices they want. Those selected prices are fed back into the data store. Then React takes care of updating all of the components that depend on that data. This includes things like updating the seat map and ticket list to hide seats that don’t match the selected filter.Tools aren’t a guarantee of success. Just like a fancy hammer doesn’t mean you can easily build a house. The most important part of a project is the people working on it. Given the huge scope of this project and the aggressive timeline, our expert people using the above tools allowed us to deliver a quality product while sticking to the timeline we set out for ourselves.

Want to know more about our work for Kentucky Performing Arts? Read our case studies on 

the new Kentucky Performing Arts branding

how we translated that branding into the new kentuckyperformingarts.org website

If you need to sell online, we’ve got you covered. From simple selling strategies to complex subscription models, we’ve built them all. Our clients with ecommerce process tens of thousands of dollars per month through our systems. From Shopify integrations to WooCommerce workhorses to Magento installations and beyond, we’ve built and managed them all, safely and securely.

Websites

Development Solutions for Foxhollow.com

What's the JAMstack?

Building a Wordpress Theme with Timber

Using React and Redux to build the Kentucky Performing Arts ticketing experience