Custom php.ini / my.cnf / nginx.conf files?

filliph

Considering 100% of the target audience are developers, I don't think you have to worry too much about scaring us with config files or right clicking a bundle file 😉

That being said, for PHP and MySQL specifically, it might make sense to have a simple textarea where we can dump extra config directives. I'm not 100% sure about MySQL, but I know PHP won't complain about a directive being overridden by a later area.

You would then dump the contents of the textarea into php_A969/etc/php/conf.d/zzzz-override.ini and using this compile-time variable to tell PHP to load additional ini files from that directory: https://www.php.net/manual/en/configuration.file.php#configuration.file.scan

That way, you don't have to ask us to override the entire php.ini file 🙂

For Nginx, you already have the /conf/conf.d/*.conf; and /conf/sites-enabled/*; include directives, which means you only have to add a general textarea (to go into /conf/conf.d/zzzz-override.conf;) and a per-site textarea. The per-site textarea needs to default to

    root "/<userpath>/.indigo/welcome";
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

(with a "Reset to default" button) and allow us to completely rewrite this block.

The reason why we need to be able to completely rewrite this block is that different sites may have different URL rewrite requirements. Here's an example of a /conf/sites-enabled/site.conf block for a XenForo 2 devboard:

location /devboards/xf22/ {
    try_files $uri $uri/ /devboards/xf22/index.php?$uri&$args;
    index index.php index.html;
}

location /devboards/xf22/install/data/ {
    internal;
}
location /devboards/xf22/install/templates/ {
    internal;
}
location /devboards/xf22/internal_data/ {
    internal;
}
location /devboards/xf22/library/ { #legacy
    internal;
}
location /devboards/xf22/src/ {
    internal;
}

(This goes above the location ~ \.php$ { part in the sites-enabled config.)

pocahontasdividends

Indigo that should definitely be noted outside the forum, as that is extremely useful to know! in addition it would possibly help to have the xampp approach to have basic config editing of the most burning config files as textboxes and the rest as the overlays you described, possibly even as a "if you need to configure anything else" link to the documentation that explains the process

Indigo

Brilliant! Love this idea. I'm tempted to prioritise implementing this idea above even simple config editing (eg editing PHP memory with GUI) because it exposes a simple UI enabling any config imaginable. I can always add a friendlier UI for specific config later if demand is there.

The one thing in my mind is that this idea allows adding (and only in some cases overriding) config but not in any case removing existing config. Your idea for the per-site config allows complete removal of existing rules, where it's most likely to be needed, and I suppose the complete filesystem-level override mechanism described above does provide the ability for complete removal / overwrite of any config at all if needed. Your thoughts?

filliph

Indigo I'd say removing existing config shouldn't be necessary for anything other than nginx as you noted, because (at least in php.ini) you can always just do some_config_directive= and if that's the "latest" value (i.e. stored in php_A969/etc/php/conf.d/zzzz-override.ini), it should effectively "delete" the existing config.

I would imagine the same kind of "override with blank value" exists in my.cnf for MySQL.

If someone needs even more advanced-er editing than this feature would offer, they can always revert back to the "full config file override" method you detailed above 🙂

Indigo

@pocahontasdividends ok, thanks for the feedback, I'll add the above to the documentation on the site.

Indigo

(the documentation is now at https://indigostack.app/docs/how-to/advanced-configuration/)

@filliph that's cool! I did not actually know you could override PHP config with an empty directive.

Overall, I'm liking where this discussion has gone, thanks to you and the others who've participated! Just need to allocate the time to build this now... 🙂

filliph

Sounds good, once this + the XDebug thing is done, I can begin testing in earnest 😃

Indigo

Indigo 1.0.0-beta.10 has just been released which provides a UI to override the configuration of PHP services. Once any wrinkles are ironed out I will roll out a similar mechanism throughout the other services and sites config.

filliph

Indigo Saving the zzz-override.ini via the GUI doesn't cleanly shut down the system stack, giving us the "Port is already in use" error.

Indigo

@filliph interesting... thanks for the heads-up that you've seen this. I've also seen it occasionally, but not been able to reliably replicate it. I am actually thinking it's a race condition whereby sometimes nginx hasn't released the port back to the system by the time the process indicates it has exited. I'm planning to monitor previously-used ports for availability before declaring the service as fully shut down, rather than relying only on the process termination & exit code.

One question for you — do you happen to have a non-"auto" port specified? ie in the UI have you hard-coded a specific port for a service to always use? That seems to be the trigger for me getting this error, but I don't have enough perspective to confirm that.

filliph

Indigo Everything is set to auto, the only ports I've actually changed are inside Preferences -> Ports, as I'm still running Docker instances of these services 🙂

Indigo

So much for that theory then 🤪 I'll implement the port-monitoring on shutdown anyway, and see if it catches any still in-use.

Indigo

This issue should be resolved in beta 11 which has just been released.