@girish I was actually going to post this before too... that trailing slash is important. However, this behaviour only seems to impact the managed app. The unmanaged app doesn't require that trailing slash. Any ideas why these are different?

@ice said in Wordpress has stopped working: Jul 27 17:20:01 [Mon Jul 27 16:20:01.042734 2020] [php7:error] [pid 41] [client 172.18.0.1:48468] PHP Fatal error: Cannot redeclare authLdap_send_change_email() (previously declared in /app/data/wp-content/plugins/authLdap-2.4.2/authLdap.php:849) in /app/data/wp-content/plugins/authldap/authLdap.php on line 849, referer: https://my.removed/ This is the problem. I think the issue was because the LDAP plugin was updated by you (?). The fix is to remove wp-content/plugins/authldap directory using the File Browser (do not remove the authLdap-2.4.2 directory). Does that work?

@ice Let's discuss in https://forum.cloudron.io/topic/2947/wordpress-has-stopped-working

@imc67 I wish there was a way to track WP Mail SMTP package updates. I have fixed up the package by hand now but it's something I need to keep in mind everytime I update WordPress. I have also fixed up the package to install the latest plugins/themes (on first run only). Thanks for reporting!

Yeah, we made changes specifically to preserve the mail from. If you find that it doesn't work, please report back.

Update: It is thankfully as easy as removing the data from the users table in the user_pass column. Removing the value from the user_pass column on each user who you want to only authenticate using LDAP/Cloudron, will force that expected behaviour. If there is a password in the database, authentication will succeed with the local password OR the LDAP/Cloudron password, so removing that password will force it to rely only on LDAP/Cloudron authentication.

Dear @Captain-Kirk @girish @jdaviescoates @scooke appreciate very much your suggestions! I'll check which one fits for my needs. What about security. Did you have any security related issues? I mean something like privilege escalation, or login attempts from external users. Many thank's

Thanks! The migration went super smooth and fast with the "All In One" plugin.

@yusf I wish you luck!

@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.