Support

You should ask your host about the best way to schedule a CRON job on your site. If they do not support CRON jobs at all you can still use the legacy frontend backup URL with WebCRON or the JSON API with either a third party service Akeeba Remote CLI — the latter if you have an always on, Internet connected computer at the office or at home which could be used to trigger the CRON job. That's why we have several scheduling options, to make sure you will have an alternative which works on your host.

Regarding SocialLogin I am not entirely sure what you mean? Like, logging in with an email instead of a username? Or sending a unique login link by email? I have considered both but I am not interested in implementing either. I can tell you the reasons.

Using an email address instead of a username is problematic as long as Joomla does not forbid the @ character to be part of the username. Let's say that your email is [email protected] and someone else registers a user account with the username [email protected]. Which one do I block from logging in, you or the other account? What about resetting your password, where we have no say and Joomla requires a username? If you start hiking about all the details it becomes a very counter–intuitive thing to implement and I don't want to do support for all of the problems that are obvious to me but not to mod tother people.

Using a login link sounds good at first but it's woefully insecure. If someone can read your email they can impersonate you. Now, you're thinking that if they can read your email you're screwed anyway — they can ask for a password reset. Well, no, it's not a big deal if you have Two Factor Authentication (TFA) or Two Step Verification (2SV) enabled on your account. Joomla would not log you in without going through the secondary authentication. However, SocialLogin bypasses that on the assumption that your social media accounts are more secure than your Joomla login and more well protected with user verification methods that may exceed TFA/2SV. Adding an insecure method to the mix would violate your account security.

1. No. You need a real CRON job. Something that triggers with site access will never work for backups. A long time ago we tried that (“Akeeba Backup Lazy Scheduling” plugin) but it was not working very well — and that was with a purpose–built plugin, not a generic pseudo–CRON system. Joomla's upcoming pseudo–CRON is the same as WordPress: great for infrequent, FAST (under 0.1 second) tasks, not for long–running tasks like taking a backup or sending newsletters to hundreds or thousands of recipients.

As I said, your best bet is using something like WebCRON. It's between 0.50 Euros to 7 Euros a year to schedule weekly backups, depending on how long your backup takes.

2. WordPress allows you to use the username and email address interchangeably since at least 2014 when I first got involved with it. Joomla doesn't. Between the two, Joomla is right as a matter or preserving user privacy. Plus everything else I said.

If you go to SocialLogin's GitHub page you will see there's an issues tab. You can check the closed issues. That said, the feature you requested isn't even in the purview of the plugin. Email is not a social network.

3. The problems with capital letters in table names (be it the prefix or the table name itself) stem from the way MySQL itself works on case–insensitive filesystems such as NTFS, FAT, FAT32, exFAT, HFS+ and APFS. It is not something that depends on us.

No, you will NEVER be able to mute the environment checks (that's what you refer to as “warnings”). They are there for a reason. The report things which WILL cause issues taking or restoring a backup. Last time we let lower priority issues, like the prefix case sensitivity, be hidden we got inundated with support requests about things we have already documented will affect your backup. Worse than that, we had people SWEARING there are no warnings — even though the Backup Now page always displayed them anyway — and sent us a backup log file which showed right there that the warning was displayed and the user ignored it. So, no, these are not going to be hidden.

I see that you have not done much end user support :) Ask any IT support person what is their experience dealing with people, from the first level support desk workers all the way to senior engineers where the most difficult cases escalate and everyone in between. We all have horror stories to tell you.

As I jokingly say to my wife, I didn't use to be a misanthrope until I started doing tech support. No, I am not a misanthrope — far from it, I write software because I enjoy helping people — but I have become jaded to a certain degree by the abuse that's doled out on me every week.

The warnings are there for the majority of people who'd be quick to blame us for something that's beyond our control or something that's already documented. The uppercase table prefixes is a prime example and the reason it will shout at you until you fix it. The vey obtrusive ANGIE password is another prime example of something that should be dead obvious. Yet, we have had so many people being irrationally angry at us for “locking their backup” and “holding their site ransom” even though a. it was their browser auto–filling the ANGIE password and b. our documentation explicitly states that deleting the installation/password.php file after the extraction removes the password protection. You'd think people would at the very least pause and think before starting accusing developers for committing a felony. You'd be wrong. People always assume they are dealing with crooks. That's what the late stage capitalism we live in has conditioned them to do.

Every warning you see has many horror stories behind it. We know that as soon as we give people the ability to dismiss them forever they will do so without thinking twice or reading the warning and we will be back dealing with horror stories; been there, done that. So, to protect our sanity and preserve our time for constructive work — maintaining our software and helping our users who have an actual problem — we made these warnings impossible to dismiss.

I am sorry that we implemented warnings to annoy you personally. It's not like the lack of warnings led to people having broken restorations with their only backup of their site, making it impossible to recover their site. It's not like I explained this. It's not like there's literally no other software in Joomla like ours. I mean, sure, a bloody weather module and a backup software must have the same level of complexity.