Thoughts on Settings Module and Laravel configuration?
Created 7 years ago by ryanthompsonIt's been a few times during the release cycle that the settings module have had fields tied to the Laravel mailer and debugger amongst other things. In and then out and then finally again for the release.
What do you guys think about removing settings for email driver / host / etc and debugging from the system settings? Instead, you would set them like a native Laravel app. This way they are picked up properly during Laravel's boot cycle.
Here's what I am concerned with.
It's messy.
I have to mimic a lot of Laravel's service provider work in order to set up a NEW mailer with the provided settings.
It's fragile.
Currently, I have discovered that this doesn't properly work either. Unless you of course configure Laravel natively through config / env.
It's none of the users business.
This had previously been my primary concern. It's no business of a person in the control panel to configure the app(s) email settings / debug settings. That's up to a qualified dev / person. Separation of concerns here.
Let Laravel be Laravel.
I feel like this has been overstepping the boundaries between Laravel and PyroCMS and kinda stepping on toes as a result.
Alternatively...
You would just configure email settings with config files / .env just like you would any other Laravel application.
Thoughts?
Let me clarify - I will most certainly keep settings. They'll still be needed for localization amongst other things. But the Email settings need ripped out.
Yes, an .env file would be generated to resources/REF/ since that's the .env override directory.
I would suggest looking into the Envoy SSH Task Runner. It can make things super easy by automating SSH tasks. I use one for example like: envoy run env --set=APP_DEBUG=true to debug and what not on remotes.
The task runner is nice for sure, but it essentially acts as a macro, but still requires you to SSH to the server. However, I usually will have my servers setup through AWS and I use their security rules to only allow SSH to my personal IP address at home. So if I'm on the road, I have to go into AWS and open up the port to allow me to SSH from there. Then I have to remember to close that SSH port up again. While this likely isn't common to the community at large, others may have similar SSH restrictions. So, it would be pretty cool if there was a way to manage settings that are controlled via .env using some form of interface. Even if that interface was just as simple as looking for all files in that folder and simply listing variable -> value in input text boxes with the ability to add new setting rows. Of course take this suggestion/request with the knowledge that I haven't yet had a chance to build anything on P3 so it may be that I'm just over-suggesting 😄.
Agreed - and I don't think the mass majority of end users will miss it lol
I always recommend others to set Laravel mail send functionality through config files and .env. This method is really easy to implement.
I kind of lean toward the settings file functionality. However, it can often be a big PITA to have to connect into the server, change the settings etc. What about integrating that as part of the multi-site admin (if that exists anymore). Since the business owners generally won't be the ones provisioning sites, it would make sense that the management of settings is done from a higher level. Then perhaps have php create/regenerate the .env? Not sure if this is at all possible...
The downside I see to this is what happens when you add a module that has some settings that need to be set? Where does the user go? Would we go down the path of a more truly modular approach and have the settings for each module be inside the module admin screens? (like in a mobile app) This might actually be better. Then have the global stuff be separated out (such as in the multi-site) or somewhat sequestered in the main admin in a place that you have to really WANT to get to or something.