Bink

Perhaps the default delete time should be one?

A person, or a bot, could quickly establish that Backup Scheduler is installed as a plugin on a website. For example:

https://www.[insertdomainhere].com/wp-content/plugins/backup-scheduler/readme.txt

If I can read that file or one of the many other .txt, .png, .nfo, .css, .js files that exist in every Backup Scheduler installation, it’s a sure sign the site is using Backup Scheduler.

The first 22 characters of the backup filename are easily predictable to the month:
BackupScheduler_20160201021729_abcde12345.zip

It’s not uncommon for backups to occur on the first of the month, but the date range is presumably 01 – 31:
BackupScheduler_20160201021729_abcde12345.zip

By default they start at midnight, but the range is presumably 00 – 23.
BackupScheduler_20160201021729_abcde12345.zip

May take a few minutes for a backup, so probably a low number. Range is presumably 00 – 59.
BackupScheduler_20160201021729_abcde12345.zip

Seconds. The range is presumably 00 – 59 also.
BackupScheduler_20160201021729_abcde12345.zip

Predictable underscore.
BackupScheduler_20160201021729_abcde12345.zip

It would not be hard for a bot to very quickly establish the filename up to this point, through a relatively small brute force test. At a rough estimate, approx 300 to 9300 attempts if defaults are used. Best case scenario for us with more random backup times and dates, up to 2678400 attempts, a figure that’s not unrealistic with bot attacks.

So I’m not sure I feel confident considering the characters up to this point part of the random password. Certainly not the first 22. That leaves now only 10.

The random string, vastly improves our odds. However, it too is to some extent, predictable. It’s always 10 lowercase/numerical characters. It’d take time and luck for a bot to brute force it, but I would not say it’s especially difficult. By default it has 42 days to find the file before it’s removed, or if one misunderstands the meaning of that setting like I did, they may change it to a higher number, like 365. (I thought it represented the length of time the file would stay on my FTP server.)
BackupScheduler_20160201021729_abcde12345.zip

I contacted Crossway support for this plugin via email, and the response I received Feb 21 2015, was that they will be working on using only HTTPS in a future update.

For the time being, I’ve left this plugin installed but disabled, hopeful of the HTTPS update.

With the guidance of this article, I was able to successfully display English posts by default.

This method will supply a translated version of the post, if it exists.

I was able to integrate this into X-Theme by copying theme-folder/framework/views/global/_index.php to the child theme and applying just some of the necesarry customisations. I’d imagine it’s fairly theme specific so I won’t post my exact code here.

Baswazz, you’re not the only one. I too would like this feature.

The website I’m looking after caters to 7 languages, all manually translated by teams around the world. It presently has 105 blog posts all in English and it’s not feasible to translate all of those into the 6 other languages.

I don’t think duplicating those posts to each language and leaving it in English is a reasonable option either. That’s 630 posts, duplicates, that wouldn’t need to exist if there was a simple way to always present posts for the default language, perhaps in addition to any translated versions that may or may not exist for the active language.

I needed to set the PHP version on the server to PHP 5.4. Higher versions than that resulted in issues with SermonBrowser.

Source of solution:

My apologies w9hdg. I turned on debugging in my WordPress install to try and figure out an issue I’m experiencing, and I’ve got the same error as you now.

So it’s not an issue with the database details.

In your web hosting control panel, check the details of your SQL database and make note of the database name and database user. Assuming the user exists (create the user otherwise), reset the password for the user: wesleyum

Edit your wp-config.php file in your sites root directory, and make sure the following lines match the database name (DB_NAME), database user (DB_USER) and supply the newly set password (DB_PASSWORD).

/** The name of the database for WordPress */
define('DB_NAME', 'your-database-name');

/** MySQL database username */
define('DB_USER', 'wesleyum');

/** MySQL database password */
define('DB_PASSWORD', 'your-new-password');

Unfortunately, I have the same issue with 3.9.