DevriX was employed to design a centrally-managed blog in several languages by merging content from three independent blogs.
The project included:
- Building a centralized content management system
- Media management in one place (shared media across the multisite)
- Updating the outdated look and feel of the blogs and create a better and modern vision
About the Client
The company is a leading creator of screen recording and screen capture software. Their solutions serve over 30 million professionals around the world to showcase products and services, for teaching purposes and engaging in stable video communication.
As of April 2020, their website has several sections in five languages, published in five separate domains.
Presently the client does not wish to have his name mentioned in this post.
The set goal was to build a new blog theme, import and merge the content from three blog sites into one content management system (WordPress). Each blog site was in a different language and that had to be kept.
Design-wise: we had to design the new blog UI to match the existing customer branding. Colors, fonts, spacing, look and feel.
Content-wise, the blog articles in each language were stored in separate sites. Therefore, each member of the editor team had to have an account on each site, in order to apply edits. With this decentralized structure, it was also impossible to share the same resources between the sites easily.
Technically, the task was to design an easy editing experience with shared resources and user groups for the three sites. The bigger challenge was the integration of the new blog multisite network on WordPress. The build had to go along with the rest of the client’s website stack, built on the Azure platform, including its SSL certificate management system.
DevriX designed the blog front-end and built a WordPress multisite network for the blog in all three languages
https://www.NAMEOFCLIENT.com/blog/ https://www.NAMEOFCLIENT.de/blog/ https://www.NAMEOFCLIENT.fr/blog/
For the design, we had to follow the brand identity requirements of the client. That included a careful look into the style definitions of the main site and coming up with a similar look and feel for the blog. Of course, the blog had a lot of new elements, so our design team was tasked with maintaining brand recognition.
The client team’s workflow didn’t require a 1:1 translation of each article posted. They had different types of content published at different points in time for each language.
For this reason, we suggested a WordPress Multisite Network. Instead of applying a commonly used approach with using a 3rd party translation plugin, we have decided to build each language as a sub-site in the network. Another good reason for this decision was our experience with such plugins and the weight they can add to larger-scale websites due to the database storage approaches they take.
At the same time, all WordPress Core, plugins and themes updates, and user management can be done from one centralized place, instead of having the need to update each site separately.
When we implemented the multisite setup, we had separated each subsite on a separate custom domain. The English language site is accessed through a .com/blog domain, the French from .fr/blog and so on. For the regular visitors, these websites look like three completely separate instances, but for the client’s editorial team, everything is in one place and management becomes much easier.
In the multisite setup, we have incorporated a shared media management hub. This greatly improved the editors’ flow allowing them to share common media across the sites. With the media being in one place, we’ve removed potential duplicates and saved disk space.
We partnered with Pagely – our experienced WordPress hosting partner – to secure all technical and server-side considerations. They provide us with a built-in CDN, an easy to use SSL certificate management and top-notch server infrastructure.
With their talented DevOps team, we were able to integrate the new WordPress Multisite, hosted on Pagely’s server, while we use the Azure’s SSL certificate and the Content Delivery Network (CDN) Incapsula on the client’s infrastructure.
At first, the user request goes to Incapsula. From there, based on a number of internal rules, the user is redirected to the proper URL.
It’s a good place to add that the client’s team uses internal URLs for the staging server and the production server, which are working on their internal network, so this has to be managed as well.
The in-house team also had an old setup where each blog was placed on a subdomain:
Before https://blog.www.NAMEOFTHECLIENT.com/ Now https://www.NAMEOFTHECLIENT.com/blog/
If the user requests the WordPress multisite, Incapsula directs it to the Pagely server, the SSL certificate is validated and we serve the proper content.