Support

This does not make any sense. We are having this conversation on this site running Akeeba Backup Professional 9.9.9, thereby proving there is no problem – if the several thousands of people using it wasn't obvious proof already.

Moreover, the Schedule Automatic Backups is essentially a static page.

Further to that, the RunPluginsTrait.php file was last changed in August 2023, predating version 9.9.5 by a full year. Therefore, the notion that this file magically started doing something since 9.9.5 is void.

And the cherry on top? Line 75 of the RunPluginsTrait.php file IS A COMMENT (NON EXECUTABLE).

Is it possible that your site has been hacked, and whatever nastiness runs on your site is just messing up with our code? Because what you're describing doesn't make any sense in any other context.

No attack perceived, but it is awfully strange that you get an error message from what is a comment line! By definition, comments are non-executable. Are you SURE that the error line is 75? Remember, I can only operate on the information you provide, and you are giving me an impossibility.

I am positive this line is a comment line since, as I already told you, this file has not been changed in well over a year. Yet, you say that 9.9.5 works and 9.9.6 or later doesn't. All of these versions have the exact same file. This creates a further impossibility, that the same file works in one version and magically doesn't in another. It's not a matter of perceived attack, it's a matter of stating something that is objectively impossible to occur. The code itself is unaware of the version number; that's something us humans use to describe a collection of source code files. It doesn't matter if I call you Matthew, or Mr. Meehan, you are still the same person.

Because of that fact, it also rules out having an OPcache issue, e.g. having opcache.revalidate_freq=0. First of all, the file is identical, so even if it was forever cached it wouldn't matter. Moreover, Joomla does run opcache_invalidate() against the installed files when an update takes place, exactly because servers with  opcache.revalidate_freq=0 exist. So, that's a dead theory.

Another piece of information I have is that nobody has reported such an issue, which makes it extremely unlikely that there is a bug in the code. Our software runs on hundreds of thousands of servers. A major bug like that could not have gone undetected for more than a few hours after releasing 9.9.6, let alone several months. We have so many clients that people will hit even minor bugs within a month from release. So, here's another data point which indicates something is wrong on your server, and your server only.

Operating on the assumption that you are giving me the correct line number, it is impossible for PHP to generate an error message telling you that an error comes from a comment line. By definition, comment lines are non-executable, therefore they cannot throw errors.

To put it into perspective, it's like someone telling you "there is a typo in this landscape photograph" when you know there is not text on said photograph. You'd have to think that this someone is stupid, trolling you, or holds a tampered copy of the photograph which has been defaced with (misspelled) text.

This is what I did here. You are a paying client politely asking for support so I reasonably assume you are not an idiot, and you are not trolling me. So, the only way the impossibility you came here with can possibly be true is if the software has been defaced.

I am further making the assumption that you cannot possibly be the person doing the defacement, because that would bring us back to the idiot / troll possibility, which I have ruled out. Therefore, the only remaining options are that someone or something has modified the software.

You said that this happens after updating. This has a further implication. When you update, this file gets overwritten. And yet, somehow, it ends up instantly tampered with.

You insist that the file has not been tampered with, yet somehow an error comes from a comment line. Sorry, this is impossible. I don't know how else to say it beyond stating that by definition it is impossible.

Beyond that, you claim that the our software somehow, magically, "starts triggering the constant communication to akeeba (so I have been told)". Not to put too fine a point on it, this is utter bullshit. There is no such thing in Scheduled Automatic Backups. This code only shows you the automation options you have for backups. It does not communicate with anything because, quite simply, it does NOT need to! Hence me calling this utter bullshit.

Further to that, they mention a wrong filename (akeeba_runPluginsTrait.php) and the line number (75) they mention on the only file with a similar filename (RunPluginsTrait.php) is a comment line. So, this is further bullshit coming from your host.

Clearly, your host does not understand what is going on and is feeding you lies. You inadvertently lie to me by conveying your host's load of crap, which is why nothing makes sense. I can only respond based on the information I am given. I also can and do tell you that the information you are giving me makes no sense. If it walks like a duck, quacks like a duck, but looks like a rabbit it's most likely Bugs Bunny, not Duffy Duck. You know what I'm saying?

Here's the thing. The code you seem to have a problem with calls Joomla! plugin events which are responded to by third party content and system plugins. If a third party plugin is broken, it will take down the application when it tries and fails to handle a plugin event. If I have the actual error message and the full PHP stack trace I can tell you how your host was lying to you, which third party software is to blame, and what you should do next.

Please provide the exact error message and PHP stack trace of the error. 

I would strongly recommend having a full trace of the error message before apportioning blame. As I explained, assumptions can get wildly off the mark. Having the debug trace helps identify the call stack and the exact file and line involved in the error. In 95% of the cases that's enough not only for identifying where the error comes from, but also to diagnose the error and start forming a plan for fixing it.