How to remove all references to the WordPress site URL on the front-end?

🙋Get Help
, ,
1

Hey folks.

I hope everything is fine with everyone here. Enjoying a lot to work with Frontity. =)

I have a dumb question if you don’t mind: how can I remove all the references from the WordPress site URL from the front-end compiled site? I don’t want to expose the WordPress URL in any way. Since the Node.js server is rendering the content on the back-end, I was wondering how we can remove the WordPress URL references from frontity.state/FRONTITY_CONNECT_STATE.

  • I’m running WordPress in SiteGround, having the source code on Github and using DeployHQ for the continuous integration/delivery.

  • I’m running Frontity in Vercel, having the source code on Github and using Github+Vercel integration for the continuous integration/delivery.

Everything seems to be working fine on my process. I was just wondering how I can make sure the WordPress URL/domain is not searchable on the front-end.

Thank you in advance, Fernando

2

Hi @nandotess85

Frontity is a framework to help build isomorphic React apps that are connected with Wordpress data. So this React app will be used to generate HTML from the server but also to add JS behaviour in the Client Side (hydration process) and to take control of the routing once the first page is loaded

So, it will be very difficult (I would say almost impossible) to completely hide your WordPress (source of data) URL from the final user → at some point there will be requests being done from the Client Side (browser) to your WordPress (server) that can be checked from the Developer Tools inspector in any browser

My question here would be… What are your concerns about the final user being able of seeing the URL of your WordPress? Security?

2 Likes
3

Hi @juanma,

Thanks for the complete and detailed answer.

When I read the Frontity documentation explaining the concept of SPR, I thought this would result in 100% rendered content on the back-end. I thought Frontity would never expose the source of the data - like a standard WordPress installation, that renders the data and doesn’t expose the database information or any other Web Service URL (if used on the back-end).

Anyway, it was just my expectation, and now I got it this is not the case. I will do some small changes to my architecture to make sure this is not a problem.

Why I would like to hide this information? Security, for sure. In my opinion doesn’t matter the number of security layers I add to WordPress, there is always a door to someone hack your system. For a moment I thought “if the WordPress URL is never exposed, I can have a very different domain for the WordPress site and so no one will never find it and try to hack it”.

If Frontity also needs to do some requests from the browser to the WordPress, I can’t block the request by IP or only for logged in users. I will need to have some REST API endpoints open so Frontity can do its work, but that means one more door open (even with CDN, cache, G7 firewall, …).

Anyway, I don’t want to complain. I’m just starting my journey of learning with Frontity. I’m sure I will find a solution.

Thanks once again for the support and quick response.

Have a great week!

1 Like
4

Can you please point out which part of the documentation you’re referring to. I’d like to have a look at that and check if it can be improved to be more precise.

1 Like
5

https://docs.frontity.org/about#frontity-features

Rendered dynamically : the HTML does not have to be rebuilt each time the content is edited or new content is published. Our preferred approach is SPR, although there are other ways to configure it.

So this links to https://vercel.com/blog/serverless-pre-rendering where there…

How does that work?

  1. When an end-user accesses your website, we always serve a static version
  2. A serverless Vercel Lambda function computes a new copy querying dynamic APIs in the background
  3. No matter how much traffic you are serving, only one background invocation is made at an interval you decide

What this means for you:

  • No more hard decisions between static and dynamic. SPR marries both paradigms
  • If your backend is slow, your responses are still always fast
  • Your backend functions and datasources can go down, and you will likely tolerate their downtime
  • Traffic to your backend is minimized, which results in massive cost reductions

When I read all this text, for me it’s clear the back-end/WordPress will be “protected” behind the first layer.

I hope this helps… and thanks for the support.

1 Like
6

Thanks a lot for the feedback @nandotess85!

2 Likes