How can I efficiently set up wordpress and AWS Amplify together? - wordpress

I have the need to have a project made up of two parts, the use case seems relatively typical:
An AWS Amplify react project, which has some API endpoints and a nice dashboard written in react.
A wordpress website with a blog, maintained by someone not very technical.
The reason for this separation is that the owner of the company is familiar with wordpress and would like to manage SEO as well as regularly writing blog posts. The main companies purpose (The SaaS) is the amplify project. There is a high probability that the owner will install lots of plugins on the wordpress site, and may well cause it to go down, in this case the amplify project must remain functional.
Ideally:
example.com -> Wordpress
example.com/portal -> Amplify project.
N.b I would like to use sub directories rather than a new subdomain, as I'm told that this helps with SEO as they will share the same page rank. The purpose of the blog is mostly for SEO and to attract people to the site.
What I have considered:
Set up a wordpress site, hosted on an Apache server (Maybe using AWS lightsail, one of the bitnami ones), and set up a reverse proxy on that Apache server to point at the amplify project.
The problems I think this approach causes:
The amplify project will be accessible from 2 URLs. The amplify app directly AND via example.com/portal; how do I stop this being available to the world via the amplify URL and only available through the reverse proxy (example.com/portal)?.
Should the apache server go down, the amplify app is then no longer accessible. The amplify project now depends on a single EC2 (or an auto scaling group potentially but this means adding a load balancer and much higher costs).
Amplify uses cloudfront as a CDN, by routing it all through a proxy we essentially lose the benefit that gives us.
Other option: Put amplify at the top
Have amplify use it's reverse proxy functionality to send requests to a wordpress page hosted elsewhere. This way if wordpress goes down, amplify lives on. My concerns here are:
Wordpress will be accessible from 2 URLs - How do I limit it to just allow the URL of the reverse proxy (example.com)?
I'll need to figure out how to get amplify to run on a URL that isn't the root of the domain, e.g "example.com/service" and will need to get the root of the domain to hit the reverse proxy.
What would make an ideal answer for and hopefully others:
Which of these options you would pick (or a different one) that might help to minimise costs whilst keeping the same level of resiliency of AWS Amplify, and why? Please try to answer in a way that may be useful for a typical set up for others to follow.

Check this one out. Basically AWS Amplify is just the tool. You would need to choose the framework that could be integrated with headless wordpress (via its api) easily.
https://www.cloudways.com/blog/use-react-with-wordpress-to-create-headless-cms/

Related

How to move custom domain from one firebase project to another without downtime?

I have a firebase project that serves live users through a custom domain. I need to move the custom domain to the new version of application that is running in a different firebase project. If I delete the custom domain and add it in another firebase project, how much time will it take to reflect the change? How do I minimize the downtime?
Checked with Firebase support. This can be done without downtime. Here are their instructions:
To delete your custom domain from the project, follow these steps:
Go to the Firebase Hosting console for your project, you will see
your domain.
Hover over your domain.
There's an overflow menu (three vertical dots) on the right. From the overflow menu, select "Delete Domain"
When you delete a domain, we don't immediately remove the domain from
our backend. This is because most of the time developers are moving
their domains from one project to another, and this feature allows us
to re-provisioned the SSL certificate quicker.
I was able to delete and add the domain to another project without any downtime. Thanks to the firebase team for being so thoughtful.
If it is just about moving the custom domain (no user sessions), and making a couple of other assumptions, like: the account used to verify the custom domain belongs to both Firebase projects, and that same account will move the domain, the change should be almost immediate, close to zero downtime. You should give it a try with a test domain, it's pretty straightforward.
If the goal is to have zero downtime, better ask Firebase Support to see if it's doable and how to do it.

Firebase multi-domain support to one instance

👋 I'm hoping to use Firebase to create an application that will allow users to make their content accessible via a custom domain. This is probably best described as a similar setup to how WordPress Multisite Domain Mapping works where there would be a main site, domain.com and many subsites based on their content customdomain.com mydomain.com anotherdomain.com.
The domains (100+) would point to the same codebase + Firestore, but based on the domain - would serve different content. All content swapping would be stored within a cloud function to serve the appropriate site.
I did see this domain limit exceeded FAQ but I wasn't sure if that applies to what I'm attempting to do at a DNS level.
I'm currently doing this in an older version of the app with DigitalOcean and an individual CloudFlare site that points to the same server, but it's a major pain to setup Page Rules, SSLs, etc instead of something that could hopefully be automated.
Thanks for any info!

Mixing Wordpress eCommerce site with external login based Vue Frontend Best Practices

I am new to web development and and would like advice about what is the usual best practices to achieve what I am trying to do.
I am in charge of writing a frontend app using Vue. This frontend will require a login to access the app. The app will be hosted on Amazon.
However we are also wanting to build an eCommerce site in Wordpress or equivalent that sits on the root of the website, (eg www.mywebsite.com) with the app accessible through a "sign in" button. If the user presses the sign in button we want the location bar location to not change from the website they are on (www.mywebsite.com), even though the Wordpress site and Vue frontend may be stored on different locations/domains.
If the site is made in Wordpress, we can get another developer to do that webpage for us, while I work on the frontend. However we want the experience to be relatively seamless between connecting to the wordpress root site, clicking on the sign in button and being taken to the Vue frontend.
Is this possible? Do both sites have to be hosted on the same server for it to work (eg an Amazon EC2 server which hosts two webpages, the wordpress one and the vue one)?
Or can the wordpress put a link to the Vue frontend which doesn't change the web location to the user?
Or (worst case scenario) do we need to make both webpages in Vue as one Vue application, some pages requiring login to access and others not?
Thanks kindly for any assistance.
So in order to use Vue and WordPress together, you can either write 2 separate applications. One for the Frontend and one for the Backend, which is perfectly fine or you can simply write a WordPress Application with a Vue Theme.
This is how this could look like:
WordPress Backend
You can use a normal WordPress backend, where you can build the architecture you want to. In addition, you need to set up the REST-API Wordpress provides. So this also means, just use plugins which support it. Otherwise, you would need to write custom endpoints. For example, Woocommerce would be a good e-commerce plugin, since it supports the API.
Learn more about it here: https://v2.wp-api.org/
Of course, you can host your WordPress installation on Amazon. Here is a good guide for that: https://aws.amazon.com/de/getting-started/tutorials/launch-a-wordpress-website/
Notice: The REST-API is available in core since 4.7. If you are using an older version you would need to install a plugin.
WordPress Frontend
In order to create your Frontend, I'd recommend you to make a custom theme. Since you are just serving static files this can be done pretty easy. But still, you don't need to reinvent the wheel.
There's a really good starter theme out there: https://github.com/EvanAgee/vuejs-wordpress-theme-starter
It comes with all the stuff you need to get started and since it is just a theme, you can simply set up a usual WordPress hosting without handling Domains of multiple applications.
In order to get the data from the Backend, you would simply make calls to the REST-API. Here's an example: https://github.com/EvanAgee/vuejs-wordpress-theme-starter/blob/master/src/api/index.js

Wordpress on new Firebase hosting

I've found out about new Google Firebase Hosting recently and I was wondering if that would work for Wordpress website?
I got a bit confused them talking about static websites & web apps even though as far as I know Wordpress is dynamic...right? on their website it says:
https://firebase.google.com/docs/hosting/#key_functions
Whether you are deploying a simple app landing page or a complex Progressive Web App, Hosting gives you the infrastructure, features, and tooling tailored to deploying and managing static websites.
It looks like a nice Hosting platform for web, especially that they provide SSL certificates, but is it good for Wordpress?
Thanks!
I THINK it would be possible, you still need your SQL+PHP server and you should use it as WordPress backend, you need the WordPress REST API and a plugin with hooks in transition_post_status, comments... and whatever you want to show in your front end, use WordPress API endpoints to send the JSON to the firebase database... after your template should use a Javascript framework in order to make JSON requests to the firebase database and show the data in the browser... It would be difficult but I think it could be the cheaper and best solution ever for a high traffic website (plus all the benefits of firebase).
Nope. Firebase doesn't provide any of the requirements necessary for Wordpress, that being MySQL and PHP on the server side. Firebase provides a JSON store accessible via an API, and static hosting for apps that can access said API.

Creating a WooCommerce Staging site

I am in the process of creating a staging site for my woocommerce shop.
Wanting to protect access to it, I put it behind an HTTP Authorisation.
However, this means that PayPal IPN will not work.
This site is only for my testing usage. I do not want people creating accounts on it.
However, as it is supposed to be using exactly the same code base as production I cannot envisage disabling the signup code.
This is my dilemma.
What can be done to protect this site from unwanted access, still leaving it as a correct copy of production code ?
What I would do is to create a new site under another domain name or subdomain without making the DNS pointers. You would then need to set the pointer in you local hosts file. The site would then work like normal for you but without the entry in the host file you would not be able to access the website(at least not in a normal way without manipulating the requests). As you probably guessed, this is not super safe if you really don't want anyone else to access the staging site, but usually that is not a big deal. No one will end up there by misstake.
Secondly I would create a script sync the production environment to the staging environment. This can be done quite easily using WP-CLI (wp db export db-dump.sql + wp db import db-dump.sql + wp search-replace domain.com stage.domain.com).
I have the impression that there is no ideal solution to this question.
This is my solution - others may have better or alternative answers though.
I created a special sub-domain under a different domain.
I then installed all necessary code and setup the site as if it were a production site. Then I created my test accounts and disactivated all account sign-up links.
I have been able to setup paypal sandbox as well.
This gives me a staging site using the same code base as production where in I can test all changes and updates before applying them to production, without having the risk of using existing client data.
This meets my needs. I hope it may be useful for others.

Resources