App Submission: WordPress

[al-lac]

App Submission

WordPress

256x256 SVG icon

https://en.m.wikipedia.org/wiki/File:WordPress_blue_logo.svg

Gallery images

I have tested my app on:

• umbrelOS on a Raspberry Pi
• umbrelOS on an Umbrel Home
• umbrelOS on Linux VM

Notes

Port mapping needed as the app_proxy seems to remove headers set by nginx or other proxies.

[nmfretz]

Excellent, thanks for yet another app submission @al-lac! We'll start on gallery assets.

This looks really good. Here's one consideration:

Port mapping needed as the app_proxy seems to remove headers set by nginx or other proxies.

Ah yes, here's some extra info on that:
#1037
getumbrel/umbrel#1428

One option here that could be worth testing is:

• Include the app_proxy in the compose file
• This would mean that the wordpress admin dashboard would sit behind the proxy
• Then when exposing the public site (not the admin dashboard) to the internet, you could proxy/tunnel to the app container directly, bypassing the proxy.
• As an example, using a Cloudflare Tunnel you would set the service to http://wordpress_app_1 (port 80 is default).

It's possible though that this doesn't do everything we need.

[al-lac]

Hey @nmfretz!

Yeah that could also make sense. But as the admin dashboard is running on the same port, I don't think you can protect it that way. Probably with a special reverse proxy config though.

Whatever you think would be for the best here!

[nmfretz]

Gallery assets done:

[nmfretz]

@al-lac, ah yes you're right. Re-reading my comment I'm not sure what I was talking about regarding exposing the public site but not the dashboard... sorry about that.

So essentially our two options are:

1. Don't put it behind the app_proxy.

In this configuration a user could tunnel or point a reverse proxy to the host at port 8567 or they could also choose to point to the wordpress_app_1 container directly (internal port 80).

2. Put it behind the app_proxy.

In this configuration, you wouldn't be able to point to the host at port 8567 because of the app_proxy container, but you could still use the Cloudflare Tunnel app or Nginx Proxy Manager app and point directly to the wordpress_app_1 container.

Right now, the precedent is that we are always using the app proxy container unless an app needs to run in host networking mode. Since WordPress does not need host networking mode, I don't think that we should break that precedent.

Let's place this behind the app proxy container for the initial release. We can then gauge the reaction to it and make a decision on whether the proxy should be removed.

I'll make the required changes and include some instructions in the app descriptions and then we can test.

[nmfretz]

@al-lac - could you please give this a test with the recent changes and let me know what you think? It's important that we don't reduce the functionality of the app needlessly so please let me know if I have accidentally done so and we can revert.

I have added the app proxy and have also added /wp-admin as the path in the manifest. This makes it so that when a user clicks on the app from the umbrelOS homescreen they are taken to the sign-in page if they are currently logged out. Without this path, if a user signs out of WordPress and then clicks on the app they'll be taken to the site page that has no option for signing in and they may be confused as to how to sign back in.

[al-lac]

Hey @nmfretz!

Everything seems to work fine, also really nice that you direct users towards the admin page!

Was able to get the reverse proxy working by entering wordpress_app_1 as the nginx forwarded hostname, together with the linked nginx config from the wordpress documentation.

The only thing that the app_proxy limits, is that you cannot use a proxy that is running on a different umbrel or other system. But I am not sure how many users would take advantage of this.