Was für eine Datenbankvesion?
Eine sinnvolle Lösing ist hier zu finden:
Im Bereich "Converting the Table to the DYNAMIC Row Format"
Das Problem taucht bei mariaDB auf, wenn von Version kleiner 10.3 hochmigriert wird. Dabei ändert sich die Default-Einstellung des innoDB Stricht-Modus.
Ich denke nicht das die verschiedenen PHP-Versionen unterschiedliche Websites liefern, wenn alle Script mit den PHP-Versionen kompatibel sind. Du kannst das ja einfach mal vergleichen, in dem der erzeugte html-Code verglichen wird.
Vielleicht hast Du irgendein Plugin/Modul laufen, welches inkompatibel ist und daher keine Ausgaben macht - ohne das es zu einem Scriptabbruch kommt.
Das solltest Du feststellen können, indem mal das Error-Reporting auf "maximum" gestellt wird und die Ausgaben unter verschiedenen PHP-Versionen verglichen werden.
Also naja, ich konnte mir unter der "Tourenfunktion" auch erst nichts vorstellen, aber wenn man sich 10 sek Zeit nimmt, einmal draufklickt und eine "Tour" startet, sieht man doch sofort worum es geht.
Also ich finde so eine Funktion klasse! Das sollte Anfängern wirklich helfen sich zurecht zu finden.
Ich glaube die Frage war nicht ernst gemeint. Falls doch, dann Brille kaufen 
Ist Joomla von Hause aus unsicher?
Nein, aber es gibt dennoch sinnvolle zusätzliche Absicherungen, wie ein vorgeschalteter .htaccess-Passwortschutz, der sehr empfehlenswert ist. Weiteres wie Captchas oder ähnliche Anti-Bot-Schutzmaßnahmen ebenso.
HTTrack ist ein "SelfDOS-Tool" ....
Diesen Lösungsansatz verstehe ich nicht. Es sind genau 2 Dateien (eine im Root und eine im Administrator). Und die Dateien sind ja deshalb dort weil es Probleme gibt?
Vielleicht gibt es ja noch weitere Files, die Du noch gar nicht gesehen hast. Entweder innerhlab der Ordner oder auch in übergeordneten Verzeichnissen.
Ich würde mal alle im Account vorhandenen php.ini und user.ini entfernen, damit die Hostereinstellung wirkt und nicht überschrieben wird.
Das Erzeugen diverse php.ini-Files in verschiedenen Unterzeichnissen ist eh ein Unding. Habe schon Installationen gesehen, wo in jedem Ordner so eine php.ini lag. Das ist mehr oder weniger sinnfrei. Es gab mal solche Anleitungen mit solchen "Tipps" und vermutlich auch Tools, die das dann erzeugt haben.... 
Das ist auch provider- und serverabhängig. Meistens ist es so, das bei Verwendung von phpmail() die Absenderadresse nicht als Return-Path gesetzt wird, sondern eine Systemadresse. Allerdings kannman das nicht verallgemeinern, weil das eben stark mit der Serverkonfiguration zusammenhängt. In diesen Fällen können dann keine Bounce-Mails empfangen werden.
Es sollte immer ein SPF, DKIM, DMARC-Record gesetzt werden.
Wie das geht, sagt Dir Dein Provider.
Bei uns so: https://www.fc-hosting.de/supp…q_mail_spf-dkim-dmarc.php
Da gibt es auch noch Erklärungen was das eigentlich ist.
Joomla auf jeden Fall auf SMTP einstellen. Dabei ist es wichtig das die Absenderdomain zum SMTP passt und der SPF-Record diesen SMTP auch beinhaltet.
Weil das alles sehr unterschiedlich je Provider und Situation sein kann, sollte Dein Provider hier der erste Ansprechpartner sein.
Offenbar bist Du dann bei einem Hoster, der nicht vom Joomla-Security-Teams über Core-Lücken informiert wird. Es wurde bei Erscheinen der Sicherheitslücke entsprechende Filterregeln verteilt, um solche Angriffe bereits auf Firewall-Ebene zu blocken.
Allerdings würde ich mich wundern, wenn Strato nicht informiert wird. Andererseits kann ich mir vorstellen, das denen das schei***egal ist.
Das ist ja fatal, wenn Ionos seine Server so konfiguriert, das lokale .htaccess oder Headereinstellungen nicht eine globale Konfiguration überschreiben können. Möglicherweise ist allowoverride deaktiviert.
core - Apache HTTP Server Version 2.4
Eine zentrale Konfiguration ist zwar performanter, aber auf Shared-Hostingserver hat ein Kunde ja keinen Zugriff auf die zentrale Apache-Konfigurationsdatei.
BTW:
Die Aussage des Supports zeigt mal wieder die gesammelten Kompetenzen der Call-Center-Agents bei solchen Massenhostern. Aber das schreib ich lieber nichts zu .... gerade erst einen Volldeppen aus dem GMX-Support gesprochen, wegen einer anderen Geschichte.
Google entscheidet bei Recaptcha auf Grundlage des Nutzerverhaltens, ob eine explizite Aufgabe abgefragt wird, oder ob der Nutzer auch ohne Aufgabe vertrauenswürdig genug ist.
Google geht mit dem Tracking sogar noch viele Schritte weiter, als bei der "normalen" Verlinkung mit einem Googleserver. DSGVO konform - klares Nein.
Tatsächlich gibt es momentan nicht viele Erweiterungen, die Bots erkennen. ECC+ ist aber auf jeden Fall eine guter Ansatz.
Typische Virenscanner finden nur selten auf PHP basierten Schadcode. Kann man als Teil einer Untersuchung mit versuchen, aber normalerweise würde eine Untersuchung direkt auf dem Server stattfinden, sofern alle benötogsten Mittel wie mindestens ein SSH-Zugang zur Verfügung stehen. Im Fall eines Hacks sollte der Datenbestand nach Vermutung eines Hacks auf keinen Fall verändert werden, weil all das die Untersuchung erschwert.
Hier haben wir eine FAQ-Seite bei uns, die ein sinnvolles Vorgehen zeigt.
Es gibt hier im Forum einige gute Fachleute, die Deine Seite untersuchen können. Du findet einige davon auch in unserer Partnerliste.
Nochmal zur Klarstellung: Die genannte Website muss nicht zwangsläufig kompromittiert sein. Viele Schutzdienste orientieren sich auch an der Webserver-IP. Die IP 178.254.10.204 ist auf jedem Fall bei mehrere Reputationsdiensten gelistet.
Z.B. hier: https://www.abuseipdb.com/check/178.254.10.204
Das heisst von dem Server aus wurden oder werden Hackversuche unternommen. Das kann nun die hier besprocherne Seite sein, aber auch eine andere auf dem Server.
Ob die eigenen Seite gehackt ist, sollte man leicht erkennen, indem man diese mal fachmännisch prüft. Ansonsten wäre mal der Provider zu infornieren. Sofern er das noch nicht weiss, sollte er drüber informiert werden, das von seinem Server aus gehackt wird.
Nur mal so an Rande: Ein Test bei Virustotal macht nur eine Aussage, wenn Schadcode gefunden wurde. Wird nichts gefunden, bedeuted das GAR NICHTS.
Zur Info:
Malwarebytes blockiert die Seite und meldet eine Kompromitierung.
Das kann sein das dies von früheren Hacks stammt oder auch von Hacks auf dem betreffenden Server.
Die IP des Servers zeigt auf jeden Fall relativ aktuelle Einträge:
Leider viel zu viel Prosa Text. Denkbar schlechter Text - wer soll das alles lesen?
Solche Hilfeseiten sollten sich auf die nackten Fakten beziehen und so kurz wie möglich geschrieben werden.
Sofern ein Hoster keine überlasteten Server einsetzt oder (bei vielen Massenprovider leider Fall) zentrale Datenbankserver (oftmals Flaschenhals), ist der Webserver selbst meistens nicht die Ursache für zu langsame Seiten. Viele der heutigen Scripte und Templates sind extrem komplex, laden massenhaft JavaScript und CSS-Files, basieren auf komplexen Frameworks und bremsen damit die Verarbeitung auf dem Server und (das ist meistens noch viel krasser) den Aufbau der Seiten im Browser.
Server- und scriptseitige Optimierungstools müssen mit entsprechender Fachkenntnis eingesetzt werden. Da hat JoomlaWunder vollkommen recht, denn blinder Einsatz ohne wirklich zu wissen wo man was optimieren kann, enden dann tatsächlich im Desaster.
Es ist nicht möglich hier den universell geltenen Performancetipp zu posten - zu unterschiedlich ist die Ausgangssituation.
Wenn nichts anderes hilft, installiere xampp neu - in derselben Version.
Vorher das htdocs und das data-Verziechnis von MySQL sichern (Mysql darf aber nicht laufen). Dnan kannst Du das zurücksichern.
Ggf. auch die php.ini, sofern Du dort Einstellungen verändert hast
