About Payments is a platform which catalogues online payment providers and methods. It was originally build in WordPress but as the scope changed from a news site to an online catalogue and marketplace, WordPress was no longer suitable. WordPress is excellent for news and blog sites, but much less a fit for sites which have more structured data they want to exploit. Since Java is our expertise we decided to migrate the website from WordPress to Java.
Building a new website from scratch and doing a big bang release didn’t feel like the right choice. That would mean spending all development effort on a new site, essentially reducing improvements to the existing site to zero. Also, it would require us to rebuild WordPress functionality like editing news posts and SEO optimalizations without actually gaining any benefits. Therefore we chose to incrementally move to Java, keeping WordPress where it works best and introducing Java where WordPress falls short. Working incrementally would also allow us to test new functionality locally without impacting the whole site. Especially for websites which are quite dependent on SEO (search engine optimization) you cannot easily rollback a new feature which negatively impacts SEO; it takes days for Google to pick up changes which makes this a slow process.
So the goal was to have Java and WordPress to coexist happily together. Our initial strategy was to share the database but nothing else. In the WordPress model, everything is a post. Posts can have tags or can be placed in a category (which in turn, is sort of a tag).
For our future plans we needed to have a more structured approach, where we could for example relate payment providers to methods and markets. Thus we would like to have separate entities for those objects. In WordPress, these different objects were all posts belonging to specific categories. Therefore, we defined views for each of those entities. The newly build java frontend would then solely make use of these views so it stayed independent of WordPress. The views thus acted as a sort of Facade or Anti-corruption layer in domain-driven design.
These views would then hide many of the nasty details of WordPress. For example, in this case, logo’s were stored using a plugin called ‘Cimy User Extra Fields’. Categories and tags are stored in the wp_term with a mapping tables called wp_term_taxonomy and wp_term_relationships. The view for providers, the posts in a specific category 123, is thus defined as:
create view ap_providers
as
select distinct p.ID as id,
p.post_title as name,
p.post_name as slug,
p.ID as wpPost_id,
u.ID as wpUser_id,
cd_picture.value as logoUrl
from wp_posts p
join wp_term_relationships tr
on tr.object_id = p.ID
join wp_term_taxonomy tt
on tr.term_taxonomy_id = tt.term_taxonomy_id
join wp_terms t
on t.term_id = tt.term_id
join wp_users u
on u.ID = p.post_author
join wp_cimy_uef_data cd_picture
on cd_picture.USER_ID = u.ID
join wp_cimy_uef_fields cf
on cf.name = 'PICTURE'
and cd_picture.FIELD_ID = cf.ID
where t.term_id=123;
For each page we wanted to migrate, we would define a new data model, define a view for it and then build a Java frontend for that page.
Ultimately, when the whole frontend is moved to Java, we could then replace the views with actual tables and build a new Java admin on top of those.
