Is there or can there be a "production" flag setting?

[lgedgar]

• Version of CORE?

"latest"

• Issue with Office, Lane, or both?

Office (primarily?)

• Is this [mostly] a bug report, feature request, or question?

question and/or feature request

My real aim here is to make development "safer" to the extent it can / needs to be. I would propose a global flag in Fannie settings which would indicate whether it's running in "production" mode. I would propose adding some callable function to determine the flag setting, as opposed to checking it directly.

Since most installs should be considered in production mode already, function return value should be true unless the setting was present in config, with false value.

Things this flag might affect, when false:

• do not send emails to customers, or perhaps send them to developer/admin recipient instead
• do not push data to 3rd parties, e.g. Instacart, Mailchimp, SPINS
• do not overwrite crontab for scheduled tasks, or perhaps write commented-out lines

Maybe something related already exists in which case please enlighten me. But if not this should be pretty easy to define the setting, and API for checking it. Going forward then could modify logic as/when needed, to leverage the flag. I'm happy to work toward that but wanted to check in first in case I was missing something.

[lgedgar]

I should add, one assumption of mine here is that I'm working with a clone of production DB, within my dev setup. Maybe that is the only reason I need to be careful in the first place? And if settings in config.php aren't part of the cloned DB then maybe I have little to worry about. But I have always liked the idea of a production flag, e.g. Rattail has one.

[gohanman]

I think this mostly makes sense although I'm a little unclear on the 3rd crontab point.

The way I'm picturing this is you would clone the whole environment including data & configuration as well as the code, and then turn off the production switch (or turn on the dev mode switch?). It makes sense to me that you wouldn't want it inadvertently interacting with the outside world via email or 3rd party services. But I think the only thing that would travel back to the original environment would be code in the form of commits. In that case it seems harmless what crontab says in the dev environment.

The settings in config.php are not part of the database, although if you're trying to make an exact replica of production it'd make sense to bring along a copy of that file - possibly with a few seds to adjust a detail or two like DB credentials.

[gohanman]

I'm tempted to do it like ^ both because there's not an obvious home for it on any of the configuration pages and because it's a bit of a dangerous user-facing feature. The effect is mostly invisible so someone turning it on inadvertently might not notice for quite a while.

[lgedgar]

Cool, and yeah agreed that keeping DEV_MODE outside of the normal config.php is probably easiest and safest.

In practice I'm still not sure if I can copy config.php from production, or at least I've not looked too closely yet. I suppose I've avoided precisely because there was not a production mode shut-off switch. It would contain lane defs that I don't want at all perhaps; but there are plenty of desirable things in there, e.g. which modules and plugins are enabled. Anyway that's for another day, this much gets us on the right track.

Regarding crontab, I may be conflating issues a little, but some things I've ran up against in dev were:

• there is only one crontab file (/var/spool/cron/crontabs/www-data in my case) which all dev installs "share" (overwrite)
• i rarely want to leave scheduled tasks enabled at all, but do find it handy to know what the "normal" schedule is

So if each of my dev installs used a separate "crontab" file (per some obscure setting not exposed in admin UI), and if those files did not exist where cron would actually find them, that might work well. Then each dev install could maintain a "complete" crontab file with full schedule details, but cron would never actually run them. And that probably makes more sense than "automatically" doing something based on DEV_MODE / production flag.

[lgedgar]

I just peeked at fannie/cron/management/CronManagementPage.php and see that it uses crontab -l when reading current schedule. I think that means we can't really specify alternate file path? So anyway I'll just leave all that alone for now and revisit later if I think it really needs improvement.

Thanks for the production flag though.

[gohanman]

RE: cron:

crontab -l doesn't support a file parameter. Each user account just has one crontab. To have multiple installs play nice together you'd either have to put them into VMs/containers, or do something like Apache virtual hosts each configured to run as a different local user.