@girish Thanks for confirming! Glad to know I wasn't totally crazy or messed something up. hahaha. I was worried I was in a bit of an unsupported state. As long as it's expected behaviour that's okay, I'll find a way to approach it down the road. 🙂

Probably better to use a subdirectory under /tmp and not /tmp itself.

There's a bunch of plugins like WP Crontrol, Advanced cron, Simple cron. You can use them to setup a custom pattern and call a custom function. Your PHP function can just shell exec your script (or maybe you can even write PHP depending on your use case).

@imc67 Thanks!

The backups also contain the sql dump and all the data files nicely structured, if required.

@girish Ah, of course it’d be writable, my mistake. I am away from my computer but I know that in the past I had a plugin installed specifically to keep themes and other plugins up-to-date. And they worked before I migrated all my sites to Cloudron. So I just made an assumption that it had to do with some limitation within WordPress. I uninstalled it a while back since it wasn’t working and just sort of got around to thinking about it again. I will try again and see if it works and if not then I’ll report back with specifics of what plugin I was using to keep everything else updated so we can try to reproduce it. Thanks for the help! 🙂

@johnbolt For all apps, the email setup is automated and managed in the cloudron packages. So for both the managed and unmanaged apps, they are already setup to send mail via Cloudron. If you are looking to change how mail is being relayed, do it in the Cloudron dashboard in the Mail -> Outbound view. That way, all apps will send via that relay automatically.

@affinity Ah, okay, that makes more sense now. Thanks for clarifying. I had forgotten about the “unmanaged” WordPress app not having the recommended plugins for LDAP auth and SMTP and stuff.

@realjohny

For the my.example.com exposing real IP, you can simply turn on Cloudflare HTTP proxying (i.e click on the cloud icon in cloudflare dashboard to make it become orange). Cloudron will automatically adapt to this change. For the wordpress issue - Delete the www CNAME record in namecheap. Then go to Cloudron dashboard and click on wordpress app's configure button (the wrench icon that appears when you hover over the app). Then in the Location tab, there is a redirections section. Add www there as a redirection. With that done, you will be able to access www.example.com.

Please let me know if that helped.

You can also try in anonymous mode or another browser to quickly check if it's a caching issue.

No worries, at least now we know what happened.

@murgero Thanks for your suggestion! I have put the new healthcheck url in https://git.cloudron.io/cloudron/wordpress-app/commit/45dc91cd7868bd2e66ea726f0968c4752279812e . Will push out the update slowly and see if it causes any issues

@mariadjohnson0 On Cloudron, the code of all the apps are "read-only". We do this because rolling updates is an important feature of Cloudron. For example, if you change the code of an app, Cloudron cannot know how to update the app.

We followed the same approach for WordPress. The code was read-only. WordPress itself could be extended by installing plugins. When a new WP release comes out, we push an update. We call this "Managed WordPress". This app does not have SFTP access.

However, many users have requested that WordPress code be modifiable. For example, they use WP as the starting point for building web sites. For this case, we created a new app called "Unmanaged WordPress". In this app, the WP code is modifiable. This comes with the restriction that cloudron will not update the WP code by itself. You, the sysadmin, has to track and update WP (using the WP dashboard, for example). This app also has SFTP access.

(You can view the Unmanaged WP, by going to Settings -> Enable Community apps).

@ruihildt It's a wordpress update

We have published a blog post with more detailed migration instructions at https://cloudron.io/blog/2018-11-05-wordpress-migration.html

@ahkg the reason for whitelisting 172.18.0.1 give access to all requests, is that this is the ip of the Cloudron internal gateway into the subnet where all apps are running.

Unfortunately for your case the cloudron healtcheck also comes via this gateway. I think your htaccess file needs to check for the X-Forwarded-For header to check against the correct inbound address.

I will mark this as solved, since it is tracked on the issuetracker already.

This should be possible to adjust in the smtp settings of the wordpress instance. You can find those at https://<domain>/wp-admin/options-general.php?page=wp_mail_smtp.php