Arena Solutions is one of the largest software companies in the world and, as such, also has a large site.
Initially, the project consisted of converting a BIG site built in AngularJS, to a WordPress site with custom editing capabilities.
While Angular is not exactly “friendly” for conversions, the project was not very special in terms of difficulty. Only large: more than 1000 pages, with around 30 different templates.
Once we started, we found some surprises. First, the site was built in AngularJS… mainly. Then we discovered that different people worked on the site, and all of them built “bubbles” that contained different layers of code in different languages. Thus, we found AngularJS, Django / Wagtail, a legacy WP installation and some PHP code in Laravel. One option was to maintain the same logic of building another layer at the top, but we decided to clean everything and remove all traces of any language other than PHP and any framework other than WordPress.
More challenges
In addition to this, we were asked to:
- keep the information architecture the same
- keep exactly the same design, pixel perfect, no differences were allowed
- connect with different third-party marketing tools and create user flows based on what these tools responded in real time
The first item was really difficult.
Since AngularJS has a completely different architecture, you can name pages, posts, categories, or types of custom posts with the same name without problem.
For example, let’s analyze the “page” slug:
site.com/page/ (where "page" is a page or publication) site.com/category/page (where "page" is a page or publication or subcategory within "category") site.com/page/cat (where "page" is a category)
This is perfectly valid in Angular and in many other systems. However, WordPress changes the name of slugs when it finds a duplicate slug. Then, “page” begins to become “page-1”, “page-2”… “page-N”.
Therefore, we needed to find a solution to this problem, which we achieved with a combination of AJAX and .htaccess.
Pixel perfect design
As for the “perfect pixel” item request, we finally discovered that instead of more or less 30 templates, we had to build almost one template for each page. Finally, we finished with about 200 templates, includes and parts.
But we did it!
Third Party Integrations
The last point was relatively trivial, with the exception of Marketo’s implementation.
We had to send information asynchronously to Marketo, then “listen” to Marketo’s response and create a custom user trip “on the fly”, which we did with AJAX and some JS plot libraries.
