Changes to WordPress apps

[jdaviescoates]

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

[marcusquinn]

@Lonk Cool - I've never made any inroads in the WP & Woo community TBH, found it quite cliquey and in self-denial with many woocommerc.com plugins we had to fork and fix in desperation from their lack of quality-control.

I've got a fair few core improvement recommendations that fell on deaf ears too - but I'm certain we could make it the operating-system for any organisation.

I guess what we're doing is kinda like all the Cloudron Apps but as WP plugins. It is opinionated and anti-microservices though, so not for everyone - yet.

If you have any contacts that want to get serious about this kind of ambition, I'm always available to talk with fellows that aren't afraid to shoot for the moon.

[Lonkle]

@jdaviescoates said in Changes to WordPress apps:

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?

Yes, a real domain alias so that Wordpress sees it and routes it accordingly. It's a built in feature of Wordpress in Multisite. It's unbelievably useful.

[marcusquinn]

@jdaviescoates In the meantime, people can reproduce most of what multi-site does with these plugins for those wanting each site to stay contained and portable for resources:

• https://distributorplugin.com
• https://en-gb.wordpress.org/plugins/wp-cfm/
• https://managewp.com

I do intend to have another look at multi-site at some point as a way of quickly firing up demo instances, so I agree on the need, we just wanted to solve the same things in a more segregated way to keep options open.

[Lonkle]

@marcusquinn And that's the one area you and I diverge in which, I think, is good. You keep me thinking of the benefits of single site and I'll keep you thinking of the benefits of multisite.

[marcusquinn]

For interest, these aliases are all the same Cloudron app:

• https://healthshop.net
• https://healthshop.co.uk
• https://healthshop.eu

I'll ask the team for more details while we wait for an official option.

[girish]

I have pushed the fixes for the WordPress (Developer) app. See https://forum.cloudron.io/post/16775 . It now has LDAP support as well. New doc pages is at https://docs.cloudron.io/apps/wordpress-developer/

[Lonkle]

@girish said in Changes to WordPress apps:

I have pushed the fixes for the WordPress (Developer) app. See https://forum.cloudron.io/post/16775 . It now has LDAP support as well. New doc pages is at https://docs.cloudron.io/apps/wordpress-developer/

Can you activate LDAP post-installation or would I have to re-install? I broke Cloudron rn so I can't test an app to try and see if it's in the configuration settings.

[girish]

The SFTP issue is sorted out now. There is a config option in Services -> SFTP. By default, only admins can access files via SFTP. So, this is a breaking change in the next release.

[jdaviescoates]

@Lonk said in Changes to WordPress apps:

Can you activate LDAP post-installation or would I have to re-install?

Exactly what I'm thinking... I'll go and see...

[imc67]

@jdaviescoates I’ve updated one of my wp apps, installed the ldap plugin used the managed ldap settings and (just to be sure) after a restart of the app ldap works!

[jdaviescoates]

@imc67 said in Changes to WordPress apps:

installed the ldap plugin used the managed ldap settings

Aha, I also just updated and didn't see any LDAP support, but this is the step I'm missing!

@girish be nice if updating Unmanaged to the new Developer version auto-magically installed the LDAP plugin and settings!

[jdaviescoates]

@imc67 said in Changes to WordPress apps:

@jdaviescoates I’ve updated one of my wp apps, installed the ldap plugin used the managed ldap settings and (just to be sure) after a restart of the app ldap works!

When you go to Access Control in your updated app are you now seeing this? (as per how it looks if you install and choose LDAP on install)

[Lonkle]

@jdaviescoates said in Changes to WordPress apps:

@imc67 said in Changes to WordPress apps:

installed the ldap plugin used the managed ldap settings

Aha, I also just updated and didn't see any LDAP support, but this is the step I'm missing!

@girish be nice if updating Unmanaged to the new Developer version auto-magically installed the LDAP plugin and settings!

I would have missed that necessary step myself. The only reason I didn't check on my own install is because @girish made a "hot fix" for me for my development and I had a VM issue so I re-installed and was refusing to go through the setup because I was afraid cloudron-machine wouldn't work after setup. But @girish confirmed today it does work after setup so I'm going to have fun testing out this LDAP integration with WP and figure out how cloudron-machine works later.

[girish]

@jdaviescoates What @imc67 did should not be possible, so I am not sure how it works for him. The LDAP will only be available for new installations since this flag is chosen at install time and there is no way to change it post installation without tinkering with the database. Might be easier to export/import into a new install. Just backup current app, make a new LDAP based install and import that backup into new app.

[imc67]

@girish it was really as easy as the steps I’ve mentioned before.

[girish]

@imc67 Ah, "installed the ldap plugin used the managed ldap settings". I missed this. So you put the credentials of managed LDAP app into this existing unmanaged app? Note that this will stop working when the managed app goes away!

[Lonkle]

@girish said in Changes to WordPress apps:

@jdaviescoates What @imc67 did should not be possible, so I am not sure how it works for him. The LDAP will only be available for new installations since this flag is chosen at install time and there is no way to change it post installation without tinkering with the database. Might be easier to export/import into a new install. Just backup current app, make a new LDAP based install and import that backup into new app.

Oh, gotcha, it can only be set at install time. So, do you think your suggestion to "set the flag without DB voodoo" (which I'm gonna do because I can't get the cloudron app db to work with remote sql, I've tried a lot). Do you think that method will clash with multisite database URL location changes (Wordpress storing the URL in a different place than single site)?

[imc67]

@girish huh why? These “codes” / settings are even from a managed app on another Cloudron, aren’t they the same for all?

[Lonkle]

@girish Yes, also curious to understand what you mean by @imc67's hack will stop working...at some point (that I didn't understand "when the managed app goes away" when the managed app isn't going away)?

[robi]

@Lonk credentials are generated per app, he copied one app's LDAP credentials.

If that app goes away, so do the unique credentials.

[imc67]

@robi but there are no credentials in the settings of the LDAP plug-in at WP, only settings/code

(I tried to upload a 'scrolled' screenshot of the settings page but it's too big)

[girish]

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

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

[Lonkle]

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

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

1. Backup current app. Download the backup config
2. Make a new install of WordPress (Developer), you can keep the existing app running.
3. Then import the backup config into this new app. App -> Backups -> Import. Upload the config from step 1.
4. Login to WP of the new app and install authLdap plugin. After doing so, Restart WordPress. Cloudron will configure the LDAP plugin on restart.
5. If all looks good, you can switch the location

[girish]

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

[Lonkle]

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

That 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. ️

[jdaviescoates]

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

Just did that. Worked a treat!

[imc67]

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

just did that but the authLdap plugin is not installed after restoring the backup (a backup from before I manually added it).

[girish]

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

@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)?

[Lonkle]

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

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

@girish clear and of course that changing of user rights worked. In this restore case there is no default admin anymore (admin - admin123) but of course the backed up admin user(s).

[Lonkle]

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

[girish]

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

[Lonkle]

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

[micmc]

@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

[micmc]

@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

[jdaviescoates]

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

@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/wpmudev

This 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-domains

However, 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-provisioning

Here's WPMUDEV's announcement for the "retiring" of their plugins.
https://premium.wpmudev.org/retiring-our-legacy-plugins/

Regards,
Andy

[Lonkle]

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

[micmc]

@Lonk said in Changes to WordPress apps:

There's only 3 caveats on Cloudron right now as it stands:

Yep, that is why I discussed about the above plugins and mentioned it was working prertty well at the time, Now that they are retired and GPL as well one can update and use them. And maybe just study them and see how ut was done so one can find the solution to adapt it to WP multisite on CLOUDRON.

Andy

[marcusquinn]

@micmc Cloudron on Hetzner (Germany). The speed is the same on any spec as it can only use one CPU at a time anyway. Hardware won't fix unoptimised software. Much of the optimisation is selective plugin unloading per page, so that only the plugins actually used on any page are loaded. The shop is Elasticsearch, again on a pretty small VM.

[Lonkle]

@micmc said in Changes to WordPress apps:

Yep, that is why I discussed about the above plugins and mentioned it was working prertty well at the time, Now that they are retired and GPL as well one can update and use them. And maybe just study them and see how ut was done so one can find the solution to adapt it to WP multisite on CLOUDRON.

The three caveats I mentioned.

• URL / Location changing without crashing the site. It’s a fix that needs to be done on Cloudron’s side but I think I can patch it to make this work pretty easily.
• WP-Cron could be made as a primary or network activated plug-in to trigger all of the other sub-site Crons. So that’s possible. But more ideal would be to edit Cloudron’s custom CRON to support sub-sites which should be pretty easy and I’m sure the devs would let me.
• Sub-sites have to be subdirectories, no TLDs or subdomains. This also can only be fixed by adding domain aliases in box and dashboard (the two parts that make up Cloudron). This would be the hardest to add for me though @girish heavily implied he wants to add them himself (he didn’t promise anything tho)

[MooCloud_Matt]

@girish said in Changes to WordPress apps:

Make WordPress plugins should just work

I believe it is okay to have a greylist of unsupported plugins anyway, all providers that use docker or other forms of LVM have it, because there are plugins that cannot work on some platforms by their nature, due to lack of a PHP library or for security and stability reasons.

For example you can't use a server with LS, OLS or Nginx and WP-Rocket Cache, they go into conflict.
this for example is the list provided by Kinsta (some plugins are there because they use too many performances others because they are incompatible).

all-in-one-wp-migration
allow-php-execute
backupbuddy
backwpup
better-wordpress-minify
cache-enabler
codistoconnect
dynamic-widgets
eww-image-optimizer
exec-php
inactive-user-deleter
jch-optimize
litespeed-cache
login-wall
p3
p3-profiler
pagefrog
rvg-optimize-database
snapshot
updraft
updraftplus
wonderm00ns-simple-facebook-open-graph-tags
wordpress-gzip-compression
wordpress-popular-posts
wordpress-rss-multi-importer
wp-db-backup
wp-db-backup-made
wp-optimize

[girish]

@MooCloud_Matt Thanks, this is a good list to keep in mind for support.

[jdaviescoates]

And here's WPengines list of disallowed plugins too just fyi

https://wpengine.com/support/disallowed-plugins/

[mdreira]

I want to trust in Cloudron developers and therefore I am going to use Wordpress Managed for our clients.

Having said that, I would like to ask about @girish wrote at this point: "Make many of the security plugins which do all sorts of crazy things like adjust the admin URL, modify files etc work. While we personally don't" vouch "for such security practices, we can't deny that WP is still the most installed app in our platform and most people install these plugins. In the spirit of picking our battles, we grant this one to the existing WP ecosystem ".

As I see in that text the words "crazy things", "personally don´t vouch for such security practices" or "picking our battles" I understand that Cloudron developers do not like this type of plugins very much. So I would like to ask:

1-Is a security plugin necessary in wordpress managed?
2-If the answer is yes, what would be the plugin that Cloudron would recommend and that works well in WP Managed ?. I know that wordfence may be the best, but this plugin requires a waf file in the WP root, so it may be discarded (I don't know).
3-If there is a recommended plugin, are there any configuration tips for cloudron? What security features should we activate and which ones are not necessary?

Thanks

On the other hand, I see that there is talk of cache plugins. I usually use "Fastest cache". At the moment it has not given me problems in Cloudron.

[jdaviescoates]

@mdreira said in Changes to WordPress apps:

I want to trust in Cloudron developers and therefore I am going to use Wordpress Managed for our clients.

Everyone has different needs, and whilst I also trust the Cloudron developers I still don't really see the point of WordPress Managed.

IMHO there are just so many instances where a client will want or need a plugin that isn't compatible with managed that it makes it pointless (also, even aside from clients, I like to always install WordFence because it makes my life so much easier, and that doesn't work with Managed as you've noted).

[mdreira]

@jdaviescoates Yes, I understand you perfectly. I am not questioning whether WP managed-developer is better or worse.

I'm just asking about the topic of a security plugin with WP Managed.

I just want some advice from the Cloudron developers, because I don't have enough knowledge to discern this.

[girish]

I should probably not have been negative about the WP Developer app In the past, the app was called "WP Unmanaged app" and some of the wording is from the times when we tried to discourage people from using it.

From a security perspective, the managed WP app is better because the WP core code is readonly. This means plugins you install or some bug in some PHP code cannot tamper with the core code base. The downside is that some plugins don't work with a readonly WP. If you already know the plugins you will ever need in advance, I would go with managed WP app and only use the Developer app if something doesn't work.

[mdreira]

@girish I understand.

So..

1-Is a security plugin necessary in wordpress managed?
2-If the answer is yes, what would be the plugin that Cloudron would recommend and that works well in WP Managed?
3-If there is a recommended plugin, are there any configuration tips for cloudron? What security features should we activate and which ones are not necessary?

Thank you!

[d19dotca]

@mdreira said in Changes to WordPress apps:

1-Is a security plugin necessary in wordpress managed?

I use the Developer package for WordPress so can't speak for the Managed version too much, but my general advice would be the following:

• Generally speaking, it'd best to only install plugins when you know you have a need that isn't already addressed in the system. Thus, knowing your exact needs would come before choosing any particular plugin. My rule of thumb personally is not to install a plugin unless I understand why I need it and what I want to achieve with it.

• Security is a huge umbrella with probably hundreds of different sub-categories / uses. So for example, it'd be good to know if you are wanting to be notified of any irregular file changes, block specific functionality in WordPress, lockdown user accounts with custom permissions, change the login page URL, rate limit logins, or a mix of those or a whole bunch of other ones.

• It's good to copy an existing WordPress site (or a default one) to test new plugins on to see if they will interfere with your current setup, avoiding testing in any live production website.

Aside from the above, I'd honestly recommend just using the Developer package of WordPress. I know that goes against Girish's recommendation but there are at least several of us "power users" in Cloudron that feel there's no real upside to the Managed package other than a little bit more security by default. Eventually, whether it's sooner or later, you'll likely have the need to use a particular plugin that will need to modify files or access certain files, in which case you'll then have to do a bunch of work to migrate from the Managed package to the Developer package, so IMO you may as well just start on the Developer package to begin with unless you have very basic needs for WordPress and don't plan on growing it at all. And you won't want to be caught in a project that's time-sensitive to then find out you need to now also migrate an entire website to a new app instance type. I learned that lesson the hard way myself.

By the way, every app has its own category in the forum. You may be better served to create a separate and dedicated post in the WordPress (managed or developer) categories. This thread in particular is pretty old and is generally on a different topic than "security plugins" for WordPress.