@lonkle I forgot I turned automatic updates off, Domain Aliases are supported in v6.1.2. 🤦
But on top of that, you should note that you only enabled Domain Aliases on subdomain multisite installs, not subdirectory multisite installs. Both of those types of Multisite Modes support multi-domains. That's important to note since many like to use subdirectories and still use multiple domains.
@lonk That's a totally valid, effective way to do it. Probably the most instantaneous of all the things mentioned, since it seems speed/latency is a priority for you. Lambda's not that bad to write code for - if you get pretty advanced with it, you can really run nearly any language on the platform, though the officially supported Java, Go, PowerShell, Node.js, C#, Python, and Ruby are the easiest options. You've got a lot of choices there.
@girish Oh, absolutely with a custom app, I mentioned in the original post that I'm going to build my own Wordpress Stack to simply and only add this. But I saw benefit to other user's being able to script something post-update as that's literally the only thing my stack will do differently than the default Wordpress app (I'll have to integrate your updates into my stack manually each time so I still wish there was a way to run an external custom sh script post-installation).
As you can see my custom script simply uses the CLI to upgrade all databases with any new required formatting if and only if any updated Wordpress core or updated plugin require it. When you update from the Cloudron interface, it simply updates all the files and Wordpress has this really annoying tendency to not upgrade the databases post-upgrade invisibly. The script above is the only way to make sure file versions and database versions stay in sync 100% of the time every update.
This becomes nearly unavoidable if you want to support multisite in the future since the problem becomes more convoluted in that installation type so my script detects multisite installations and runs database upgrades accordingly with WP CLI commands or single site only commands if it's a single site.
I actually think the script below should be an optional "automatic upgrade plugin and themes checkbox when updating Wordpress core" option for Wordpress installations as well, here's the WP CLI code for it:
@lonk Yeah I figured we had the same issue but apparently not, my bad. Didn't mean to hijack the thread earlier. haha. Mine was actually caused by v6.0 due to a breaking change in how SFTP works - by default for admins only, meaning any non-admin users are rejected out of the box. But I think yours was different as you filed it before v6.0.
They can’t acknowledge that they don’t validate their input fields properly without acknowledging the need for a filter to be added while fixing that same validation code (and they should fix it tbh).
But if they don’t fix it, I’ll keep hacking their validation form (my WP Plugin works), and if they do fix it - they’ll add that filter for me I’m next to positive which allows me to code a less hacky solution. Win-win. Just took me forever to realize it. 😅
Currently, you cannot change this, no. You have to use the LAMP app if you want to change the apache configs. In the LAMP app, there is an app.conf which gives you control over logging.
You'd expressed interest in more fine-control over logging in another thread. If that's still true, I'll deal with the Apache over-Logging for now looking forward to a time where we figure out a solution for a way to best configure logs for the end-user.
Going to LAMP would just feel like I'd be contributing less and less to the Wordpress (Developer) and (Managed) codebase(s) and that's my real goal. To make Wordpress (Developer) the best it can be in Cloudron.
So maybe, one day, those access logs will be configurable. 😉
I agree we should visit this at some point for better logging
This fixes the Wordpress "custom log path issue". But I do think we should revisit in the future about other apps and how we might be able to symlink the logs together. Anyway, you got me 75% there on this one, so thank you for that! ☺️
Don't forget that it's not the forum users that decide this, but actually @girish and @nebulon. And that should purely be on what they see value in and can see themselves maintain and support in the future.
That's exactly my point, by being able to see what they like, I have a much better idea of what could make it into master. If a bunch of app devs or consumers like it, I know @girish and @nebulon are at least going to look into it. But if a Feature Suggestion even only has 2 likes, if I can see it's girish and nebulon, then I know it's much more likely going to happen in the future over 5 regular users upvoting. Does that make sense?
@girish I started getting Gitlab build errors in the docs fork I made from something called pipelines (likely how you guys deploy). So I def contributed to this incorrectly. I'll just edit it locally until I'm able to merge request the API docs properly (can't wait to get to the File Manager API, haven't RE-ed that one yet).
I also hope there's some secret API calls that you don't even use in Dashboard or Cloudron CLI. I love hidden API endpoints like that. It's like getting to see the beginning of an abandoned (or yet to be implemented) idea.
What do you mean with Cloudron's App DB? Like the main platform database?
That would be simply available on your host system only on localhost. You can access it with mysql -uroot -ppassword box (password is literally password) Of course you are on your own if you tinker with that database, changing things there might break the system.
I honestly never would have figured out the password (not joking), thanks, that worked! ☺️
Is there only one cloudron database which is "box"?
Oh, that’s easy. It’s already there in the environment variables. Cool, I’ll adjust my library to include it so that the app doesn’t break when Cloudron starts enforcing the bind password (which it’s only not for 4 apps I guess - so when / if they ever support it, Cloudron will require the password).
Thank you so much @mehdi. Sometimes I miss the easiest of things.
Got the tool fully working on macOS. Worked like a charm after I figured out everything the tool wanted.
I had to make a small commit to dashboard since macOS doesn't support the timedatectl CLI tool so I converted that command into a universal one that returns the same values on either Ubuntu and Macs. But that was literally the only thing that didn't work in the entire tool and I've already committed a change for that (locally, of course).
So, thanks for your help @girish, this will allow me to build a cloudron-master Cloudron install that's, ofc, unstable - but it will be just to test my apps in before you turn your new commits into a release to make sure my apps are always compatible with your newest changes! ☺️
@nebulon That’s the exact answer I was hoping for but couldn’t test. Thanks again for the clarification. Trying to avoid any potential bugs even in situations where I can’t test directly so your info really helps out!
@mehdi That’s what I’m thinking it must be - it’s happening with my VPN Client since that’s what I’ve been working. But the box code treats the OpenVPN Client like normal and only treats the apps connected to it special.....wait, what if the cache of the domain exists because an app was connected to my OpenVPN Client app so it’s still “somewhere” in memory even though technically that container is no longer referencing an active container.
That’s a great idea and I think that may be the cause. Because it would persist reboots even, the app connected to the VPN Client attempting to connect. I’m just hoping I can get some advice on how to access Cloudron’s internal app DB via Remote SQL (like you can with individual apps) so I can debug this issue entirely.
I want to release the OpenVPN Client on the store in 2021. So I gotta make sure it’s perfect - and your comment just sparked a thought process that very likely could be the problem and I was dismissing it in my head for silly reasons. Thanks. I’ll reproduce it now that I know it’s just me, and see if I can fix it.
I really just needed one other person on the latest Cloudron perform those steps and have it go perfectly for me to know it was my app (and box changes).
I like how well thought out "sideloading" apps is. That's one of it's biggest benefits for me as a developer, but I see that from a user side too. Maybe that's why I like this. I've always liked sideloading apps.
PSPS. I hope no one takes any disrespect when having opposing ideas on here. I always try to debate in good faith. I view us, the forum members, as needing to decide on important infrastructure aspects like this. So it’s us vs the problem. Not my idea vs anyone else’s. The problem is that sometimes users have to repair their apps manually. It usually happens after auto-updates / reboots (the only two times I’ve experienced it or read about others experiencing it on here). So what’s the solution? My solution is to auto-repair apps like that until we get enough data to fix the underlying problem. Meaning, we need not only an auto-repair so we’re not punishing users for a bad update (that will always happen), but also despite automatic repairs, easier log reporting of these errors to us.
So, it’s us vying for more logs to fix underlying issues, and automatic repair when something really is a one-ff situation which sometimes don’t have an explanation. Or they do but an average user couldn’t find it. But if they hit the “Send us crash logs” button then we might be able to fix it or find the issue.