OL Connect products (“OL Connect”) is a great tool to automatically generate personalised documents and distribute them via multiple channels. This is done through templates created by a Template Designer, who may be using data extracted by a Data Specialist, all of this being driven by a series of automated processes designed by an Operations guru. This separation of tasks makes it easy to manage large scale projects and allows each specialist to take responsibility (and be accountable) for a specific set of tasks within the project.

However…

Beyond the mapping of personalised data onto multi-channel templates, a lot of additional content may find its way onto each document, content that may be the responsibility of other departments that are not directly involved in the OL Connect implementation. For instance, the Marketing department may be in charge of the different Company and Product Logos and images, which may change from time to time. The Legal department may be in charge of updating the Terms & Conditions or the Legal clauses in contracts according to new regulations. The Customer Service department may have to change the contact information and address for one of the organization’s branches

If the additional content were stored in OL Connect templates, making changes to that content would require every employee responsible for it to be trained on (and to install) OL Connect, which would make little sense when all that’s usually needed is to modify some text or some images. And it would also mean that every employee in each department could make modifications to some other content in the Templates, making it almost impossible to keep a clear audit trail of who made changes where.

The most efficient way of managing additional content is to store it in a Content Management System (CMS). Most, if not all CMSs available on the market have a web-based GUI, allow for storing large amounts of content in a logical structure, provide versioning information for the content and offer access/role restrictions that allow setting up fine-grained permission settings for sensitive content.

One such CMS is WordPress, a system that was originally designed as a blogging platform but that quickly expanded into Content Management and Web Services, to the point where it is now, powering over 30% of all web sites globally, this market share increasing to about 60% when considering only CMS systems (source: W3Techs Technology Surveys).

One crucial element that partly explains WordPress’ popularity is that it can be installed for free and can run in the cloud or be hosted locally, which means it is able to drive an externally accessible Internet site as well as a protected Intranet housed behind an organisation’s firewalls. A huge community of developers constantly creates free or almost free plugins for WordPress that allow it to further extend its already rich feature set, from LDAP management of users to eCommerce connectors to traffic Analytics and Statistics.

Because of its flexibility, cost, low learning curve and global acceptance, WordPress was a natural choice as the first CMS with which OL Connect can integrate. Other CMSs may follow, but this article focuses on WordPress specifically because it is the one that has been tested the most extensively and for which solutions have already been developed.

Note: this article does not discuss the specific methods by which Connect and WordPress share content. Its goal is to explain and clarify the general architecture that allows an organisation to integrate the two systems. Other articles explaining how to pull or push content to and from both systems will be published separately.

There are many different flavours of WordPress packages out there but they all share the same three base elements: a Web Server, a scripting language to drive that Web Server, and a Database to store content. One of the most popular flavours of WordPress is called WAMP, an acronym that stands for:

W Windows-based setup
A Apache web Server
M MySQL database
P PHP language

Almost identical flavours exist for Linux (LAMP) and Mac (MAMP – which is actually also available for Windows). There are also flavours that use IIS instead of Apache as the web server, SQL Server instead of MySQL as the database and a myriad of combinations of Web Servers and databases. But still the same three base elements remain identical.

The particular flavour that’s best suited for an organisation depends on the overall architecture that will be used. All elements of WordPress can be installed on a single machine (or VM), which centralises management in a single location. But the Database could very well be hosted on a different machine, provided both machines can communicate with each other. The main concerns that should drive the design of the architecture should be security and performance: you want an implementation that is secure while remaining easily accessible and manageable, and you want to make sure no unnecessary latency is introduced if the base elements have to communicate with each other over a network.

For instance, you may want your WordPress implementation to use an existing database on your network, say, the MySQL database that gets installed with OL Connect. Before you go ahead, however, you should monitor the current traffic to and from your existing database to determine if it will be able to efficiently handle the additional load. If your Database is already under heavy load, using a separate database, even located on a different server, might turn out to be the most efficient in terms of performance.

We will come back to the different flavours of WordPress packages, but for now let’s examine the pros and cons of specific architectures. Note that whenever the term machine is used, it can mean a Physical Server, a Virtual Machine, or a clouded Server/Application.

1. Single machine, shared database

This architecture is fairly simple to implement and very easy to maintain since only one instance of MySQL is running, used by both Connect and WordPress on the same server. The MySQL instance contains two separate schemas (i.e. databases) but they are both accessible through the same MySQL engine, which may be a concern in GDPR-conscious environments. Unless traffic coming from both Connect and WordPress is expected to be very light, this type of architecture is likely to be the least efficient since the single Database instance may quickly become the bottleneck. Consequently, you should only consider this architecture for development/testing purposes.

2. Single machine, separate databases

This architecture is the easiest to implement as it is the result of using the default installation settings for both Connect and WordPress. Maintenance is also simplified since both instances of MySQL are readily accessible (on different ports), while still maintaining complete separation of data between WordPress and Connect. However, the additional performance cost of having two database engines running on a single system may make this setup even less efficient than the first one. Again, this type of architecture should only be considered for development/testing purposes.

3. Three machines, shared database

This architecture is more complex to implement and to maintain. Usually, an organisation’s IT department must be involved in order to open the proper ports between machines while making sure other machines/applications cannot access them directly. Once again, the shared database may be a concern to organisations that have strict data-protection policies. However, the performance of the entire system will be significantly better since each machine is dedicated to one task and one task only. Even though the database is shared, having it run on its own server lets it use all of the resources on that system, which will yield good performance even with heavier traffic. Consequently, this is a good setup for any implementation where performance is paramount.

4. Two machines, dedicated databases

This architecture is relatively simple to setup, with a single port needing to be opened between machines. Maintenance is slightly more complex because the applications and databases reside on different machines. Separation of data is excellent as is overall performance since each application has its own dedicated database. Because the database engines are hosted on the same machine as the application to which they are dedicated, one or both machines may be using all of their resources to accommodate heavier traffic. However, the entire setup requires only two servers, which makes it suitable in a production environment for organisations that want to strike the right balance between data-protection, medium to heavy traffic performance and a minimal amount of hardware resources.

There are a number of additional combinations that would be too long to explore here, especially when other systems are also involved in the solution (e.g. an existing web server, a CRM/ERP application, a Document Archival System, etc.) or when Connect Server Clusters are implemented. But the above examples represent the most common configurations.

The challenge is to pinpoint the one that’s most likely to meet the current and future needs of your organisation.

Once a particular architecture has been chosen, WordPress can be installed and configured. Because each organisation has different needs and requirements, it is up to them to install and maintain the WordPress server. OL Connect can be configured to communicate with any flavour of WordPress and Objectif Lune specialists can provide the necessary information to do so, but ultimately the architecture and deployment of WordPress must be managed by the organisation’s IT department.

Here is one of the possible step-by-step methods for installing WordPress alongside OL Connect. In this example, both OL Connect and WordPress are installed on the same server and set to share OL Connect’s MySQL database (see the Single machine, shared database scenario above).

1. Install the full version of OL Connect and Workflow. Make sure the services are running.
2. Install Minimal XAMPP (from https://www.apachefriends.org/index.html). Note how MySQL is not selected in this step.
3. Download WordPress (from https://wordpress.org/download/) and unzip the file in the C:\xampp\htdocs folder (this will result in a new C:\xampp\htdocs\wordpress subfolder)
4. Use a text editor to modify the file C:\xampp\phpMyAdmin\config.inc.php. In that file, set the database’s root password by editing the line $cfg[‘Servers’][$i][‘password’] = ‘mypassword’ (Obviously, you should pick a different password)
5. Launch XAMPP, then start the Apache Service
6. Open a new Web browser page and go to http://localhost/phpmyadmin/
7. Click on the Databases tab. The phpMyAdmin process should recognize your existing OL Connect MySQL
   instance. Create a database named wordpress
8. Open a new Web browser page and go to http://localhost/wordpress
9. Follow the instructions. When you get to the Create Admin account section, enter the same root password for the database you specified in step 4, then specify another password for your admin account.

This WordPress setup is now complete and is set to use the same MySQL instance as Connect. Other types of architecture will require more or less the same amount of steps.

With any web-based application, security is a key issue. CMS systems like WordPress have long been choice targets for hackers and bots because they are open-source, widely distributed and – let’s face it – poorly installed. Because they are so easy to install and deploy, organisations often overlook the fact that their default settings are the same worldwide and that hackers are well aware of those settings.

This doesn’t mean WordPress and other CMS systems are unsafe and should be avoided. What it does mean is that merely installing the application is just the first step on the road to making the application secure. If your organisation only plans on using WordPress internally (i.e. not making it publicly reachable on the Web), then most of the security concerns are the same as for any other application used by the organisation, and following a few basic guidelines will ensure the system is well protected against any internal intruder.

However, if WordPress is web-facing, then the same kind of measures that are in place for an organisation’s web site should be implemented for WordPress as well. There are a number of resources on the web that discuss the specifics of implementing WordPress in a web environment, and most of them list the same general guidelines to help make WordPress secure. Here are a few of the most common recommendations:

• Use strong passwords for all accounts. This is key: regardless of all other measures, weak passwords open the door to hackers. Users and Admins alike should use sites like howsecureismypassword.net or passwordmeter.com to check how strong their passwords are.
• Change the default account name. Admin is much too predictable, you should select something that is specific to your organisation.
• Change the default MySQL table prefixes. Instead of using the default _wp prefix, use something more elaborate. You will rarely – if ever – have to type those table names anyway – they are used by WordPress itself – so you can make them as complex as you want. This will prevent SQL injection attacks.
• Keep WordPress and its plugins up to date. Setting up a proper update policy for WordPress and its plugins ensures that any vulnerabilities that are discovered get patched as quickly as possible.
• Install a firewall. You should already have one but if you don’t, it must be the first thing on your to-do list.
  If you have an existing firewall, you should make sure it is configured properly to protect WordPress.
• Delete the readme.html file: the readme.html file is always located in the root of the site. It provides basic information about installation, upgrading, system requirements & resources. It also displays the WordPress version currently running, which can be used by hackers to exploit vulnerabilities. This file gets added back with every new WordPress update. To be on the safe side, the file should be deleted after each update.

These are but a few recommendations. One excellent resource for designing an exhaustive security protection scheme for WordPress is http://www.wpbeginner.com/wordpress-security/. This site is constantly updated with new information, techniques and guidelines. A more basic, yet thorough, article can also be found here:
https://securityintelligence.com/pressing-your-luck-with-wordpress-a-look-at-cms-security-risks/

Remember: as an organisation installing WordPress or any other CMS, it is your responsibility to protect its data and its users from potential security breaches.

 

The following diagram illustrates how Objectif Lune designed its PM Solutions architecture. PM Solutions is a demonstration web site running a number of interactive demos that use OL Connect, WordPress and MySQL. The site is web facing and must therefore be protected against unauthorized access. Note that many of the design choices shown in the diagram were driven by the current infrastructure at OL, which relies heavily on the Azure platform. Other organisations may elect to host everything themselves or to use some other cloud service.

The three main parts of the solution are hosted on Azure:

• a Windows 2016 Server VM, which hosts Connect and Workflow
• a WordPress Azure application, which is not quite a VM but rather a Virtual App (similar to what a locally hosted Docker app would be)
• a MySQL instance, shared between the Connect VM and the WordPress app.

We decided on this architecture because we wanted to benefit from Azure’s high-availability feature for the MySQL database, since that’s the back-end (and the busiest) part of the entire system. Azure, just like other providers, offers different monthly programs that can be adjusted if the traffic increases beyond what our current agreement provides for. Therefore, both the VM and the MySQL database’s capacity can be increased (for an additional fee) on demand. There are also a number of management tools that come with the platform, allowing the IT department to closely monitor usage, traffic and alerts.

Anyone visiting the site needs to go through an authentication process that can be called both from the VM and the WordPress app. Once users are authenticated, they are redirected to the WordPress App or to the VM, depending on the demo.

On the VM, only standard ports 80/443 are open to the public while other ports used by the Connect and Workflow servers remain private. This means all the traffic has to go through a single point of entry. We selected NodeJS as this point of entry because it allowed us to quickly create routes to the internal servers behind it, without having to display the actual URL endpoints on the client’s browsers. With this technique, it is impossible for any client to access the Connect or Workflow servers directly: everything must go through NodeJS, which makes management very easy.

As for the database, its default port was changed from 3306, just in case, and our IT department implemented policies that forbid all access to it except if the requests come from either the VM or the WordPress app.

It should be noted that this architecture does not include some modules that are part of the overall architecture of Objectif Lune’s presence on the web. Routers, firewalls and bot/malware detection mechanisms are therefore not shown in the diagram to keep it as simple as possible but should always be considered integral pieces of the entire structure.