Completely disable the staging site (delete files and disable cron job)

[Bronislawsky]

Hi!

This is not really an issue but more a feature request. Since most of the site I admin would never require a staging feature as they are always updated on different machines, I would like to have an option in ss-config to disable it beside settings its cronjob to never and wiping the staging directory.

Thanks

[jessuppi]

Thanks for the suggestion @Bronislawsky

It seems like a great idea, and probably would need to be added in multiple places e.g.

• ss-clean
• ss-sync
• ss-install-wpconfig
• etc...

I'll review core scripts and post back here when it's updated.

[jessuppi]

Okay there are now if statements in ss-sync that will skip copying files to staging if explicitly disabled in ss-config ... likewise there is a new if statement in ss-clean that will delete all staging files if explicitly disabled as well:

Ref: https://github.com/littlebizzy/slickstack/blob/master/ss-sync.txt Ref: https://github.com/littlebizzy/slickstack/blob/master/ss-clean.txt

Note that if STAGING_SITE option is missing from ss-config or set to anything besides false then both these scripts will assume staging is still desired and the staging site will continue to exist/sync.

Disable by setting: STAGING_SITE="false"

Still working on support for ss-install-wpconfig and the MU plugin xxx-staging.php (hiding the staging menu)...

[jessuppi]

This is another staging/dev site related Issue that simply has too many related commits to reference here.

So much work has been done on staging/dev and adding "if statements" in many different bash scripts, so that if you disable the staging site in ss-config those files should be deleted entirely now via ss-clean-files...

Eventually we may have ss-clean-database delete the staging database as well (if staging is disabled). Pretty much we want users to be able to safely run any given SS bash script without messing anything up, so that every single bash script checks settings in ss-config first to be sure it's "allowed" to do the task in question.

So like if you run ss-install-wordpress-core it shouldn't be installing WordPress to the dev site if DEV_SITE="false" as one example, among many others.

[jessuppi]

Also the cron job you refer to is probably ss-sync-staging and that script also checks ss-config first now:

Ref: https://github.com/littlebizzy/slickstack/blob/master/bash/ss-sync-staging.txt

## only if staging site is enabled ##
if [[ "$STAGING_SITE" == "true" ]]; then
...

Keep in mind this is different from the cron job itself. If you want to totally prevent ss-sync-staging from running at all, you can now set the interval to e.g. "never" like: INTERVAL_SS_SYNC_STAGING="never"

For the geeks who want to fully understand, the SS core cron jobs (/var/www/crons) are still going to run no matter what because they are hardcoded in the root crontab during ss-install. But if certain intervals in ss-config are set to e.g. "never" then those cron jobs will see that and simply not run the SS bash script in question.