Thomas@iThemes

Which version of PHP and which version of WordPress do the sites use? Because it’s usually best to be using the latest version of WordPress and following their recommendations here:

Requirements

It might be a plugin/theme conflict. Like perhaps an anti-spam plugin and/or security plugin.

It looks like you’re blocking access to /wp-admin/admin-ajax.php

https://www.internationalacademy.ge/wp-admin/admin-ajax.php

You’ll need to remove the block (whitelist, etc.) as plugins, themes, even WordPress itself needs to access that file. (Or as someone previously mentioned, you may need to check the file permission/ownership setting for that file and possibly other files in that directory. Though I’m able to access at least one other PHP file directly, in the web-root, without any issue.)

The easiest way to find out what files are getting 403’d (Forbiddens) is to look at the server access logs. if the server access logs are very long, you’ll have to refine the search to 403 or/with something additional.

The exact server and/or WordPress time shouldn’t matter here. Basically if you schedule a post to be published ten minutes later, it should be published ten minutes later.

It usually helps if you can provide a URL to the site. As there are a couple of things that can be looked at directly. Like what happens when you try to access the /wp-cron.php file directly in a browser? As it should immediately return a blank white page. Also, what happens why you try to access this file directly /wp-admin/admin-ajax.php? As it should immediately return a blank white page with a small 0 (zero) in the upper left.

Also, providing the URL allows us to look up the domain to see if the site is behind a CDN like Cloudflare, Incapsula, Sucuri Firewall, etc. And that may be part of the issue. And/or the site is hosted with a host that is known to disable the WordPress cron.

The first thing to do would be to check for a plugin/theme conflict, by deactivating all plugins and switching to a default theme like TwentyTwenty. Then schedule a post to be published ten minutes later and see if that works.

Also, check in the site’s wp-config.php file to make sure there isn’t a ‘define’ disabling the wp-cron and/or a ‘timeout’.
define('DISABLE_WP_CRON', true);
and/or:
define('WP_CRON_LOCK_TIMEOUT', 120);

Editing wp-config.php

Unfortunately BackupBuddy doesn’t have a section here at WordPress dot org. As it is a commercial plugin. If you have an issue with BackupBuddy and you have a valid BackupBuddy subscription, you will need to log into your iThemes account and create a ticket here:
https://members.ithemes.com/panel/helpdesk.php

Você precisará considerar um desses plugins como uma possibilidade: https://www.ads-software.com/plugins/search/job+requests/

This is just a guess, but you mentioned that you are using A2 Hosting. I believe by default they use MariaDB. And it’s possible that it’s configuration needs to be adjusted as I’ve seen issues with their MariaDB setup that caused high memory usage.

You need to contact A2 Hosting so that they can enable the “ND (Native Driver) extensions”. In other words they’ll need to enable the nd_mysqli extension as default in PHP 7+ configurations rather than the mysqli extension (MariaDB developers also claim it has better performance anyway).

It usually helps if you can provide the URL of the site in question. That way anyone trying to help you can inspect the site themselves. For this instance, I would check to see if I could access either of these files directly:

/wp-cron.php
/wp-admin/admin-ajax.php

As your WordPress site needs to connect back to itself at those files. And when it cannot connect back to itself at those files, you will see loopback warnings like that.

If it reports loopback warnings like that sporadically, also make sure that you are not disabling the WordPress cron in the site’s wp-config.php file with one or both of the following defines:

define('DISABLE_WP_CRON', true);
and/or:
define('WP_CRON_LOCK_TIMEOUT', 120);

Editing wp-config.php

Also, sometimes caching and/or security implementations can cause those errors. So if you are doing any of those, whether by plugin, host, or at the server level, they may need to be cleared and possibly inspected as well.

Could be a plugin/theme conflict. Easiest way to check for that is to install this plugin and follow its instructions on how to check for a plugin/theme conflict:
https://www.ads-software.com/plugins/health-check/

As that plugin was created by the WordPress community for situations like this. It allows you to deactivate all plugins and switch to a default theme without it affecting anyone else visiting/viewing the site.

You’ll have to find a some sort of front end editor plugin:
https://www.ads-software.com/plugins/search/front+end+editor/

But you might also have to utilize a plugin that controls access as well.
https://www.ads-software.com/plugins/user-role-editor/

The best thing would be to contact the support channels for those specific plugins that are causing the conflict(s). As they would be able to assist you quicker than anyone else. As they may have knowledge on the conflict(s) that you are experiencing.

For the loopback error/issue. It means that your site cannot connect back to itself at /wp-cron.php and/or /wp-admin/admin-ajax.php. If you had supplied the URL of the site in question, I may have be able to help determine what is causing that. But without that I can only suggest that you make sure that you’re not using any security implementations to block access to either of those files.

It could also be caused a plugin. To check for a plugin conflict you can temporarily deactivate all other plugins, and then see if it works better. If so, then you now know that one or more of the plugins were conflicting and you can reactivate the plugins one at a time to find which one(s) causes the conflict. Check any maintenance mode, safe mode, calendar, security, cron control, minifying, or caching plugins first (for caching plugins you may need to also clear its cache when deactivating it to make sure it counts).

Also, check in the wp-config.php file to make sure there isn’t a ‘define’ disabling the wp-cron and/or a ‘timeout’.
define('DISABLE_WP_CRON', true);
and/or:
define('WP_CRON_LOCK_TIMEOUT', 120);

Editing wp-config.php

Finally, if your host uses mod_security, please check with them to make sure they are not blocking the cron loopback. Another thing to check would be if you’re using a CDN like Cloudflare. Cloudflare may be blocking the connection/process and you may need to seek their support to verify. Another example is that some people like to password protect their wp-admin directory with .htaccess but forget to allow HTTP access for admin-ajax.php, which is located in the wp-admin directory and required for WordPress and plugins to utilize the WordPress cron task scheduling system correctly.

You’ll have to create a new account with WordPress.com. And make sure that you use the same email address for WordPress.com that you have with your www.ads-software.com site. www.ads-software.com will then automatically “pull” the avatar from WordPress.com that is associated with that email address. WordPress.com and www.ads-software.com are sort of two separate entities.

It looks like the login page is accessible. So your issue could be a plugin/theme conflict. If you deactivate all plugins does it appear then? If not, what happens when you activate a default theme like TwentyTwenty or TwentyNineteen?

The .dat files you are seeing in the same location as the local backups created by BackupBuddy are legitimate files used for the new “Restore Backup” feature (from within the WordPress dashboard) which is done directly within the site on the BackupBuddy -> Backups -> Restore Backup tab.

The .dat files enable additional restore features and are used to quickly get information about local and remote backup files when using the new “Restore Backup” feature.

If the .dat files are causing an issue, you can always disable them here:
wp-admin (dashboard) -> BackupBuddy -> Settings -> Advanced Settings/Troubleshooting -> Technical & Server Compatibility -> Disable .dat file creation

By checking that option then saving the settings.

But doing so, may keep restores from working as effectively when using that new “Restore Backup” feature from within the WordPress dashboard. So please keep that in mind.