WordPress Unmanaged & LDAP users

[jdaviescoates]

@girish said in WordPress Unmanaged & LDAP users:

We have many users giving access to consultants/external people and they are normal users on Cloudron. They don't to make those users as Cloudron admins (since they become admin of all apps).

Ah, yes, that make sense, don't know why I didn't think of that.

Is there a way admins could add more SFTP users within Cloudron without making them admins. Like you often can on shared hosting accounts.

[d19dotca]

@jdaviescoates @girish - I think one way may be to add a flag to each application on the appropriate tab where it shows the SFTP credentials, and have it list all users with access to it with a spot to add users too (and to clarify, I mean specifically for SFTP access, not just the users who have app access).

So it'd be say only "admin" role by default for SFTP access, for example, plus any Cloudron users which are added by an admin as having SFTP access. That way I can have one freelance developer have access to the one project they need, without giving them access to anything else.

Would the above be doable perhaps?

[d19dotca]

@girish Hi Girish, just wanted to see if this was being tracked anywhere in your Git repository, so we can move this forward in the future. I'd love to see this sooner than later, but realize you guys have a lot on your plate right now too.

PS - I am pondering my own solution of essentially making some changes to your Managed one and deploy my own version of it as a custom package, which would probably give me the "best of both worlds", as there are things I want from the Managed one and Unmanaged one, but can't seem to have them all.

[jdaviescoates]

@d19dotca said in WordPress Unmanaged & LDAP users:

there are things I want from the Managed one and Unmanaged one, but can't seem to have them all.

Out of interest, what things do you want from each one?

[d19dotca]

@jdaviescoates Good question! I'm still playing around a bit before concluding how I want to approach it, but a summary (for today anyways, haha) is this:

• I want the LDAP part of the managed version
• I want the redis part of the unmanaged version (though the whole Redis thing I'm still figuring out, as I am not entirely sold it's beneficial to me yet versus the additional memory it will take off my system)
• I want the ability to update core WordPress myself. Though I have seen @girish be pretty awesome at quickly updating apps when new versions are out, so this isn't necessarily a true requirement, just a preference to have more control of it for my own testing purposes.
• I prefer the sizing of the managed version, though not sure how I can achieve that if adopting parts from unmanaged (also not sure yet what makes up the sizing difference to begin with). In my tests, a brand new managed deployment is about 53 MB when I have the base plugins and things I want. That same list of plugins and such on an unmanaged one seems to be more like 95 MB, and that's just the base-difference. From what I've seen when I went recently from Unmanaged to Managed, there is a much higher savings on disk space (in some cases it was a difference of about 300 MB). Unclear why, not sure what is consuming it in the unmanaged version and it could have to do with the way I migrated too. But either way, I found there to be a decent difference in size (especially when I'm multiplying this by about 16 hosted sites).
• SFTP access from unmanaged one is nice and was a requirement at one point earlier on, but now not so much and also with the new file manager built-in, I don't think it's necessary anymore.

So my ideal custom WordPress app would basically be based on the managed one for LDAP and such, but with redis added and also without that disabling of core updates, I think that'd be the ideal version for my clients. And maybe the SFTP part, not sure yet.

I think I'm also just surprised at the sheer differences between unmanaged and managed. Why does unmanaged not work with LDAP? Why does managed not have redis integration? Also file system permission differences. There are others but can't remember off the top of my head. It just surprises me. To me, I think the unmanaged one should simply be the managed one with just more control over updating of the core WordPress app, otherwise should be no other real difference IMO. I'd love to see these be better aligned with each other, but unfortunately that's not the way it is yet. I'm sure there are valid reasons for the major differences, but I also think we're probably at a point (as we can see from the primary discussion on this thread) that some things were maybe overthought earlier or assumed to be risks when they aren't really risks. In other words, we seem to be at a point where we can better manage these risks and align them closer so it's not so difficult for people to choose which version to go with.

Side note (for context on the "difficult for people to choose"...): I have used up a lot of time myself flipping between unmanaged and managed, migrating 16 sites to each one multiple times. Started with Managed, went to Unmanaged, and now I've basically arrived back at Managed as I find it to be a bit more performant somehow (this may be in my head, lol), but now I'm wanting redis for caching purposes for at least a few of the 16 sites so I think I may just give up on the distributed versions and use my own custom solution. OCD me wants to keep them all on the same package to make maintenance easier. One good thing to come out of that though was a lot of experience in migrating now, haha, learned a ton from it increasing my WordPress knowledge.

Hopefully that gives a bit of insight into my plans and reasoning for a custom app. A little long-winded, it's how I tend to write. hahaha.

[marcusquinn]

@d19dotca All good ideas and I'm just trying to free up time with my team to start looking into contributing here too.

We have 10 WP & Woo devs on our team and a load of experience, so be happy to collaborate and probably share our stack here as well.

https://brandlight.org for interest, and forever a WIP!

And the first sites we've built with it:

https://brandlight.org/i/partnerships/clients/

Having been in ecommerce for 20 years now, I feel for everyone with all the pain-points that comes with scaling needs and the balance between all the plugins and all the hazards, hence we're aiming to open-source our curated stack to help solve that and gather more feedback and interest.

Initially it started because we just wanted to have the stack we needed to use - but then became apparent that there's so many problems everyone has with dev-ops and plugin conflicts, duplicate data etc, it seems it could be something the community might like too.

Prob be a few weeks before we can do something tangible but we're definitely here for the ride and the long-term, so happy to share and collaborate on needs and ideas because we definitely want to make it work with Cloudron and the API for quickly launching new copies.

[girish]

@d19dotca Thanks for your input. Just wanted to leave a note that we are discussing how to address many of the points that you have mentioned. I think some of the topics you brought up like the SFTP access are repeated pain points and I want to solve it properly for 6.0.

[d19dotca]

@girish Hi Girish. Just wanted to check in on this. Is this still something saved for after 6.0? Or is this perhaps able to happen now that 5.6 has been released? Not certain what parts of the app updates would be requiring updates to Cloudron first although I'm sure there's something.

[marcusquinn]

@girish I wonder if this thread is asking the same thing: AuthLDAP seems to be installed and has settings pre-populated for the Wordpress (Developer) app, but it doesn't seem to be working?

[girish]

@marcusquinn I think this thread was about adding LDAP to WordPress Developer. We added that long time ago. But @d19dotca reported recently that LDAP plugin is not managing the roles properly - https://forum.cloudron.io/topic/6625/logging-in-resets-role-to-editor-instead-of-administrator-or-shop-manager . I have to investigate that.