Changes to WordPress apps
-
@imc67 Ah yes, I see why it works.
From a security perspective, each app gets it's own addon credentials (database, redis, ldap etc). When app is installed/uninstalled, we create/destroy a separate username/password/database for each app. Now, Cloudron could have gone a step further and implemented a security measure that these credentials will work only when the specific app uses it. This can be done because each app has it's own IP address internally (via Docker). We haven't implemented this, and as a result, the credentials of one app (say mysql username/password/database) can be copied over to another app and it will work. But it will only work until the other app exists. When the other app is uninstalled or repaired/restored etc, the credentials are regenerated.
In the case of LDAP addon, there is a so called "bind" password which allows apps to make LDAP queries. We generate a bind password per app. However, currently, we don't enforce this password since some apps do not support it. This WordPress LDAP plugin we use is one such case (probably one of the remaining 3-4 apps in Cloudron). Because, it doesn't use a bind username/password, all you are copying over is the LDAP server credentials (server name/port which is the same across all cloudrons). So, this happens to work now. But later when we fix the plugin to use LDAP credentials, it will stop working.
Also, you will see inconsistency in the UI since Cloudron is not aware that LDAP is enabled for the app. You will see a different access control view than what @jdaviescoates posted. You also can't control which users have access to ldap from the Cloudron UI. In fact, I am going to guess only admins can access your WP install (since they are allowed by default).
-
@imc67 Ah yes, I see why it works.
From a security perspective, each app gets it's own addon credentials (database, redis, ldap etc). When app is installed/uninstalled, we create/destroy a separate username/password/database for each app. Now, Cloudron could have gone a step further and implemented a security measure that these credentials will work only when the specific app uses it. This can be done because each app has it's own IP address internally (via Docker). We haven't implemented this, and as a result, the credentials of one app (say mysql username/password/database) can be copied over to another app and it will work. But it will only work until the other app exists. When the other app is uninstalled or repaired/restored etc, the credentials are regenerated.
In the case of LDAP addon, there is a so called "bind" password which allows apps to make LDAP queries. We generate a bind password per app. However, currently, we don't enforce this password since some apps do not support it. This WordPress LDAP plugin we use is one such case (probably one of the remaining 3-4 apps in Cloudron). Because, it doesn't use a bind username/password, all you are copying over is the LDAP server credentials (server name/port which is the same across all cloudrons). So, this happens to work now. But later when we fix the plugin to use LDAP credentials, it will stop working.
Also, you will see inconsistency in the UI since Cloudron is not aware that LDAP is enabled for the app. You will see a different access control view than what @jdaviescoates posted. You also can't control which users have access to ldap from the Cloudron UI. In fact, I am going to guess only admins can access your WP install (since they are allowed by default).
@girish said in Changes to WordPress apps:
In the case of LDAP addon, there is a so called "bind" password which allows apps to make LDAP queries. We generate a bind password per app.
Where might I be able to find this bind password? I made up my own tiny PHP library for LDAP in the VPN Client and I did not use a bind password even though it's not required "for now". So, I would def like to fix that preemptively.
But later when we fix the plugin to use LDAP credentials, it will stop working.
Did you write this pugin yourself or do you need to make the fix upstream with another team?
-
@girish that's sad, as the expectations with "upgrading" the app to 'developer' suggested all the long awaited new functionality.
So what's the best, step-by-step approach?
@imc67 said in Changes to WordPress apps:
@girish that's sad, as the expectations with "upgrading" the app to 'developer' suggested all the long awaited new functionality.
Yeah. For LDAP, we don't have a mechanism to easily to turn it on/off dynamically ie after an app installed. Let me discuss this with @nebulon to see if this is something we should do for Cloudron 6 because it's easy to do on Cloudron side (but we have to test with all the apps to check how well they cope).
If it's urgent, the easiest way is to just:
- Backup current app. Download the backup config
- Make a new install of WordPress (Developer), you can keep the existing app running.
- Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
- Login to WP of the new app and install authLdap plugin. After doing so, Restart WordPress. Cloudron will configure the LDAP plugin on restart.
- If all looks good, you can switch the location
-
@girish said in Changes to WordPress apps:
In the case of LDAP addon, there is a so called "bind" password which allows apps to make LDAP queries. We generate a bind password per app.
Where might I be able to find this bind password? I made up my own tiny PHP library for LDAP in the VPN Client and I did not use a bind password even though it's not required "for now". So, I would def like to fix that preemptively.
But later when we fix the plugin to use LDAP credentials, it will stop working.
Did you write this pugin yourself or do you need to make the fix upstream with another team?
@Lonk said in Changes to WordPress apps:
Did you write this pugin yourself or do you need to make the fix upstream with another team?
It's authLdap. We have contributed patches in the past like this one. So, have to invest more time into adding bind password support.
-
@imc67 said in Changes to WordPress apps:
@girish that's sad, as the expectations with "upgrading" the app to 'developer' suggested all the long awaited new functionality.
Yeah. For LDAP, we don't have a mechanism to easily to turn it on/off dynamically ie after an app installed. Let me discuss this with @nebulon to see if this is something we should do for Cloudron 6 because it's easy to do on Cloudron side (but we have to test with all the apps to check how well they cope).
If it's urgent, the easiest way is to just:
- Backup current app. Download the backup config
- Make a new install of WordPress (Developer), you can keep the existing app running.
- Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
- Login to WP of the new app and install authLdap plugin. After doing so, Restart WordPress. Cloudron will configure the LDAP plugin on restart.
- If all looks good, you can switch the location
@girish said in Changes to WordPress apps:
If it's urgent, the easiest way is to just:
Backup current app. Download the backup config
Make a new install of WordPress (Developer), you can keep the bet existing app running.
Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
If all looks good, you can switch the locationThat answered my question, this won't support multisite yet, but I can make some manual DB changes to still make this work and understand Cloudron better, win-win.
️ -
@imc67 said in Changes to WordPress apps:
@girish that's sad, as the expectations with "upgrading" the app to 'developer' suggested all the long awaited new functionality.
Yeah. For LDAP, we don't have a mechanism to easily to turn it on/off dynamically ie after an app installed. Let me discuss this with @nebulon to see if this is something we should do for Cloudron 6 because it's easy to do on Cloudron side (but we have to test with all the apps to check how well they cope).
If it's urgent, the easiest way is to just:
- Backup current app. Download the backup config
- Make a new install of WordPress (Developer), you can keep the existing app running.
- Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
- Login to WP of the new app and install authLdap plugin. After doing so, Restart WordPress. Cloudron will configure the LDAP plugin on restart.
- If all looks good, you can switch the location
@girish said in Changes to WordPress apps:
Backup current app. Download the backup config
Make a new install of WordPress (Developer), you can keep the existing app running.
Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
If all looks good, you can switch the locationJust did that. Worked a treat!
-
@imc67 said in Changes to WordPress apps:
@girish that's sad, as the expectations with "upgrading" the app to 'developer' suggested all the long awaited new functionality.
Yeah. For LDAP, we don't have a mechanism to easily to turn it on/off dynamically ie after an app installed. Let me discuss this with @nebulon to see if this is something we should do for Cloudron 6 because it's easy to do on Cloudron side (but we have to test with all the apps to check how well they cope).
If it's urgent, the easiest way is to just:
- Backup current app. Download the backup config
- Make a new install of WordPress (Developer), you can keep the existing app running.
- Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
- Login to WP of the new app and install authLdap plugin. After doing so, Restart WordPress. Cloudron will configure the LDAP plugin on restart.
- If all looks good, you can switch the location
@girish said in Changes to WordPress apps:
Backup current app. Download the backup config
Make a new install of WordPress (Developer), you can keep the existing app running.
Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
If all looks good, you can switch the locationjust did that but the authLdap plugin is not installed after restoring the backup (a backup from before I manually added it).
-
@girish said in Changes to WordPress apps:
Backup current app. Download the backup config
Make a new install of WordPress (Developer), you can keep the existing app running.
Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
If all looks good, you can switch the locationjust did that but the authLdap plugin is not installed after restoring the backup (a backup from before I manually added it).
@imc67 said in Changes to WordPress apps:
just did that but the authLdap plugin is not installed after restoring the backup (a backup from before I manually added it).
You can just install it from WP Admin and restart WordPress (Cloudron will configure the plugin on restart). I will edit the instructions.
-
@imc67 said in Changes to WordPress apps:
just did that but the authLdap plugin is not installed after restoring the backup (a backup from before I manually added it).
You can just install it from WP Admin and restart WordPress (Cloudron will configure the plugin on restart). I will edit the instructions.
@girish that worked, I even saw already the settings in the ldap plugin but still restarted the app to be sure.
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
-
@girish that worked, I even saw already the settings in the ldap plugin but still restarted the app to be sure.
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
@imc67 said in Changes to WordPress apps:
@girish that worked, I even saw already the settings in the ldap plugin but still restarted the app to be sure.
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
So the LDAP plugin "syncs" the WP user database with Cloudron's then? I wonder if it sync both ways.
And also, what did all of your Cloudron users import as in Wordpress with the "official" non-hack-ed way of enabling LDAP?
-
@girish that worked, I even saw already the settings in the ldap plugin but still restarted the app to be sure.
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
@imc67 said in Changes to WordPress apps:
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
For consistency, this behaves similar to other apps. There is a default admin user. And then the admin user has to decide who else becomes admin or not. You can go to WP users and make specific users admin. The LDAP plugin actually has a DefaultRole field in it's settings but I noticed now that the setting is not preserved across restarts. I will get this fixed shortly.
I will be fixing the managed WP to behave the same way (it doesn't even have an admin user at this point...).
-
@imc67 said in Changes to WordPress apps:
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
For consistency, this behaves similar to other apps. There is a default admin user. And then the admin user has to decide who else becomes admin or not. You can go to WP users and make specific users admin. The LDAP plugin actually has a DefaultRole field in it's settings but I noticed now that the setting is not preserved across restarts. I will get this fixed shortly.
I will be fixing the managed WP to behave the same way (it doesn't even have an admin user at this point...).
-
@imc67 said in Changes to WordPress apps:
one thing: I expected a ldap logged in cloudron admin also should become admin in WP (in my previous but wrong setup this was the case)?
For consistency, this behaves similar to other apps. There is a default admin user. And then the admin user has to decide who else becomes admin or not. You can go to WP users and make specific users admin. The LDAP plugin actually has a DefaultRole field in it's settings but I noticed now that the setting is not preserved across restarts. I will get this fixed shortly.
I will be fixing the managed WP to behave the same way (it doesn't even have an admin user at this point...).
-
@girish Does the LDAP plugin used sync users one way from the Cloudron User DB to the Wordpress one? Does this sync happen at intervals or as soon as a user gets created on Cloudron?
@Lonk said in Changes to WordPress apps:
@girish Does the LDAP plugin used sync users one way from the Cloudron User DB to the Wordpress one? Does this sync happen at intervals or as soon as a user gets created on Cloudron?
@Lonk It doesn't sync users, no. Users have to login first to be known to WordPress.
-
@Lonk said in Changes to WordPress apps:
@girish Does the LDAP plugin used sync users one way from the Cloudron User DB to the Wordpress one? Does this sync happen at intervals or as soon as a user gets created on Cloudron?
@Lonk It doesn't sync users, no. Users have to login first to be known to WordPress.
@girish said in Changes to WordPress apps:
@Lonk It doesn't sync users, no. Users have to login first to be known to WordPress.
Understood. That actually sounds like the perfect flow, I'll integrate it that way with my apps - is that how all of your LDAP integrations currently work with Cloudron store apps (no syncing, just adding LDAP users on demand with login hooks)? Just asking so I make sure to code my apps in the same way.
-
We've just switch https://healthshop.net to run on Cloudron. 6,000 products, multilingual, multi-everything — and I know we still have a bunch more optimisations to go.
If ever anyone says WP & Woo can't scale, send them my way
Looking forward to getting into more Cloudron App optimisations.
Honestly, must have tried every other WP hosting on the planet by now - and none of them are truly optimised or even transparent about what they consider optimisation beyond their caching plugin masquerades.
Performance is about uncached code optimisation, and I still can't imagine any of the other so-called enterprise ecommerce platforms being able to do what we can with good old WP and it's community.
@marcusquinn said in Changes to WordPress apps:
We've just switch https://healthshop.net to run on Cloudron. 6,000 products, multilingual, multi-everything — and I know we still have a bunch more optimisations to go.
I'm impressed at how fast that loads, the front page, and how fast we can start seeing those products' thumnails coming in. swift...
That's great opti man
Mind to share the box config this site's running on? Where physically in the world is the box located?If ever anyone says WP & Woo can't scale, send them my way
Yeah, that I know for a long time
Honestly, must have tried every other WP hosting on the planet by now - and none of them are truly optimised or even transparent about what they consider optimisation beyond their caching plugin masquerades.
So much so...
Thanks bro.
Andy -
@Lonk said in Changes to WordPress apps:
The only think beyond those two things (which I could code easily to integrate with Cloudron) is real domain aliases (not redirections) would be needed.
I'd love to see WordPress Multisite on Cloudron.
As I understand it (one of) the problem(s) is that I don't think it's currently possible to have multiple domains pointing to the same Cloudron app, and imho we'd need that to work for Multisite to be useful (so that all the subsites within the multisite can be mapped to their own TLD).
I guess that is what you mean by real domain aliases?
@jdaviescoates said in Changes to WordPress apps:
@Lonk said in Changes to WordPress apps:
The only think beyond those two things (which I could code easily to integrate with Cloudron) is real domain aliases (not redirections) would be needed.
I'd love to see WordPress Multisite on Cloudron.
As I understand it (one of) the problem(s) is that I don't think it's currently possible to have multiple domains pointing to the same Cloudron app, and imho we'd need that to work for Multisite to be useful (so that all the subsites within the multisite can be mapped to their own TLD).
I guess that is what you mean by real domain aliases?
I can for sure confirm that WPMU, or multisite, works pretty well in cloudron for a start. It works pretty smooth and well in /directory mode as this is how I've set it up for my own needs. For example, each of the demo sites in the portfolio you see on this website https://marketingtechnology.agency/web-design-folio is running on its own full wp instance on a multisite install on cloudron.
Of course this is manually installed and setup. I do not remember if it was possible to at least install the sub-domain version, but I think not and it might have been discussed with @girish that this is still a wall to bust.
I'm using and dev on wp for I think almost since it exist and as far as I can see there's only one plugin that I know of that was able to manage WPMU with TLD for each sub-instance on a mulisite and it was at wpmudev.com for whom I've been working a few months btw, but that was back in 2014. And I think they've since then released all there plugins and themes to "public domain" or something I can't recall lol ... however if that plugin is still available somewhat since it is GPL there certainly something that could be pur out of this, i believe.
Andy
Ignorance is not an excuse anymore!
https://AutomateKit.com -
@jdaviescoates said in Changes to WordPress apps:
@Lonk said in Changes to WordPress apps:
The only think beyond those two things (which I could code easily to integrate with Cloudron) is real domain aliases (not redirections) would be needed.
I'd love to see WordPress Multisite on Cloudron.
As I understand it (one of) the problem(s) is that I don't think it's currently possible to have multiple domains pointing to the same Cloudron app, and imho we'd need that to work for Multisite to be useful (so that all the subsites within the multisite can be mapped to their own TLD).
I guess that is what you mean by real domain aliases?
I can for sure confirm that WPMU, or multisite, works pretty well in cloudron for a start. It works pretty smooth and well in /directory mode as this is how I've set it up for my own needs. For example, each of the demo sites in the portfolio you see on this website https://marketingtechnology.agency/web-design-folio is running on its own full wp instance on a multisite install on cloudron.
Of course this is manually installed and setup. I do not remember if it was possible to at least install the sub-domain version, but I think not and it might have been discussed with @girish that this is still a wall to bust.
I'm using and dev on wp for I think almost since it exist and as far as I can see there's only one plugin that I know of that was able to manage WPMU with TLD for each sub-instance on a mulisite and it was at wpmudev.com for whom I've been working a few months btw, but that was back in 2014. And I think they've since then released all there plugins and themes to "public domain" or something I can't recall lol ... however if that plugin is still available somewhat since it is GPL there certainly something that could be pur out of this, i believe.
Andy
@micmc said in Changes to WordPress apps:
I'm using and dev on wp for I think almost since it exist and as far as I can see there's only one plugin that I know of that was able to manage WPMU with TLD for each sub-instance on a mulisite
In the olden days you could always use https://wordpress.org/plugins/wordpress-mu-domain-mapping/ but that finally broke with a recent WordPress update...
...but that didn't matter because as of WordPress 4.5, WordPress includes multisite domain mapping in the core.
-
@micmc said in Changes to WordPress apps:
I'm using and dev on wp for I think almost since it exist and as far as I can see there's only one plugin that I know of that was able to manage WPMU with TLD for each sub-instance on a mulisite
In the olden days you could always use https://wordpress.org/plugins/wordpress-mu-domain-mapping/ but that finally broke with a recent WordPress update...
...but that didn't matter because as of WordPress 4.5, WordPress includes multisite domain mapping in the core.
@jdaviescoates said in Changes to WordPress apps:
...but that didn't matter because as of WordPress 4.5, WordPress includes multisite domain mapping in the core.
Yep, that was one as well I'd forgot.
I'd glanned back to one of my old memory drawers and found what I was talking about.
So for interested folks you might find very useful this github tresory
https://github.com/wpmudevThis one might be the one we'd be interested in to create multisite with proper TLDs. (wirking from it because since this is retired I doubt it would still work.
https://github.com/wpmudev/multi-domainsHowever, I remember it was working pretty well, they even had a plugin with which you could sell hosting space with TLDs on your own multisite nertwork.
A few more that could be interesting on the multisite side.
https://github.com/wpmudev/multisite-content-copier
https://github.com/wpmudev/blogs-directory
https://github.com/wpmudev/multisite-theme-manager
https://github.com/wpmudev/simple-sitemaps
https://github.com/wpmudev/multi-db
https://github.com/wpmudev/whmcs-multisite-provisioningHere's WPMUDEV's announcement for the "retiring" of their plugins.
https://premium.wpmudev.org/retiring-our-legacy-plugins/Regards,
Andy -
@jdaviescoates said in Changes to WordPress apps:
@Lonk said in Changes to WordPress apps:
The only think beyond those two things (which I could code easily to integrate with Cloudron) is real domain aliases (not redirections) would be needed.
I'd love to see WordPress Multisite on Cloudron.
As I understand it (one of) the problem(s) is that I don't think it's currently possible to have multiple domains pointing to the same Cloudron app, and imho we'd need that to work for Multisite to be useful (so that all the subsites within the multisite can be mapped to their own TLD).
I guess that is what you mean by real domain aliases?
I can for sure confirm that WPMU, or multisite, works pretty well in cloudron for a start. It works pretty smooth and well in /directory mode as this is how I've set it up for my own needs. For example, each of the demo sites in the portfolio you see on this website https://marketingtechnology.agency/web-design-folio is running on its own full wp instance on a multisite install on cloudron.
Of course this is manually installed and setup. I do not remember if it was possible to at least install the sub-domain version, but I think not and it might have been discussed with @girish that this is still a wall to bust.
I'm using and dev on wp for I think almost since it exist and as far as I can see there's only one plugin that I know of that was able to manage WPMU with TLD for each sub-instance on a mulisite and it was at wpmudev.com for whom I've been working a few months btw, but that was back in 2014. And I think they've since then released all there plugins and themes to "public domain" or something I can't recall lol ... however if that plugin is still available somewhat since it is GPL there certainly something that could be pur out of this, i believe.
Andy
@micmc said in Changes to WordPress apps:
I can for sure confirm that WPMU, or multisite, works pretty well in cloudron for a start.
I also run Wordpress (non-production) Multisite on Cloudron. There's only 3 caveats on Cloudron right now as it stands:
• WP-CRON only works for the primary sites, not "sub-sites".
•Location/ URL can't be changed from the Cloudron side without crashing the site (only way back in is manual SQL edits).
• The biggest one for me (but is of no issue to someone like you with a subdirectory install which has no issues): Cloudron doesn't support Wordpress' feature of domain name mapping (including TLD and subdomain support which can be mapped on a site by site basis within Wordpress). All of Cloudron's "other" URLs are redirections and don't pass the URL to Wordpress to it knows which sub-site to route to.
