Frontend OK, Backend weis, Ich will's wissen

Zitat von Trubadix

besagte Liste kann ich natürlich nichtt öffentlich machen

Da bin ich aber froh. Kannst eh nix mit anfangen.

Falsche Textkodierung ist nur dein Browser. Musst in solchen Fällen entsprechend umstellen.

Geh in die configuration.php. Ändere folgende Zeilen wie folgt:
public $error_reporting = 'maximum';
public $debug = '1';

Dann lade Backend neu.
Werf ggf. auch Blick in Quelltext, ob doch irgendwas drin.
Prüfe auch auf JavaScriptfehler.

Zitat von Trubadix

Debug Maximum ist wenig hilfreich, hat für Front und Backend einen Fehler 500 zur Folge.

Da hast du wohl einen Fehler beim Bearbeiten der configuration.php gemacht. Falscher Editor? Hochkomma vergessen?

Außerdem: Man muss diese in configuration.php bereits vorhandenen Zeilen anpassen. Nicht neue Zeilen hinzufügen!

Zitat

könnte ich mich mit var_dump weiter ranarbeiten

Du hast keien Vorstellung wie lange du auf diesem Wege var_dumpen wirst

Hast Du die configuration.php in utf8 "ohne" BOM abgespeicher?

Das Debugging ist eine Joomla-Funktionalität. Tritt zuvor ein PHP-Fehler auf, kann diese natürlich nicht mehr ausgeführt werden.

Error reporting.
Setze in der /administrator/index.php NACH den require_once-Zeilen, in denen auch framework.php vorkommt (kann grad nicht nachsehen, wo exakt):

error_reporting(E_ALL);        ini_set('display_errors', 1);

Und gleich danach zum Testen ein

exit('Hallo. Habe Exit.');

Sollte vor dem exit(...); durch die Zeilen ein Fehler auftreten, rührt z.B. der 500 daher, dass dein Server diese Manipulation hart blockiert und damit "ungenügend konfiguriert ist" für anständiges Arbeiten mit Joomla.

$app->execute();

$app ist ein Objekt, in diesem Fall eine Klasseninstanz. (Die gelernten Programmierer hier werden mich korrigieren bzgl. Begrifflichkeiten ...)

execute(); ist eine Methode dieser Klasse (oder z.B. parent Klasse). Keine Eigenschaft der Klasse.

Deshalb versteh ich nicht, was du mit deiner DEBUG-Zeile $app->execute eigentlich erreichen wolltest.

Im besten Fall kann man $app selbst debuggen, nachdem die Zeile gelaufen ist. Kommt zuvor ein Fehler, weiß ich, dass innerhalb Methode execute() ein Fehler aufgetreten ist. Pure Theorie: Hier $app zu debuggen, macht wenig Sinn, da $app->execute(); irgendwo auf den langen Wegen durch die Eingeweide Joomlas einen Redirect durchführt. Die Debug-Zeile wird so niemals ausgeführt, wenn sie nach $app->execute(); steht.

Steht sie davor ist $app sowieso nicht aussgaefähig, außer für die Fälle, wo bereits hier ein Fehler auftritt. Dann ist nämlich schlicht der Joomla-Core zerschossen, meist Dateien unvollständig oder gehackt oder so was. Installierte Erweiterungen können zu diesem Zeitpunkt nahezu beliebige Fehler haben. Wird nicht auffallen, sondern erst während execute().

Wenn du wirklich schrittweise debuggen willst, beginnend am Urknall-Punkt Joomlas, musst also in die richtige Methode execute() gehen und dort schrittweise Debugzeilen setzen, die dich auf den Weg in andere Klassen und Methoden bringen, in denen der Fehler vorliegt, die du dann weiter schrittweise debuggen kannst, die dich auf den Weg in andere Klassen und Methoden bringen, in denen der Fehler vorliegt, die du dann weiter schrittweise debuggen kannst, die dich auf den Weg in andere Klassen und Methoden bringen, in denen der Fehler vorliegt, ... Dann hast noch hunderte extended Klassen, musst also die Parent-Klassen debuggen usw. usf.

Mein Tipp: Stell einfach das geupdatete Subdomain-Verzeichnis auf die Hauptdomain um. Oder mach export/import mit Akeeba Backup und Space und Datenbank zuvor ordentlich platt.

Nur nebenbei: Versteh auch nicht, wenn Datenbank händisch kopieren, wozu du das if exists brauchst. Löscht man die alte komplett und importiert die neue komplett oder ändert halt einfach in Domain die Datenbankdaten in configuration.php.

Kopier das gesamte Stable-Paket drüber ohne Ordner /installation/ und /templates/. Genereller Tipp. Wenns nix hilft, schadet's auch nicht, aber man hat was ausgeschlossen.

Pech gehabt. Weil, nicht der com_login macht hier den Fehler, sondern du müsstest zurück gehen, in früheren Code, um zu ermitteln, warum

$this->input

NULL ist ("Undefined property") und nicht wie erwartet ein Objekt, genauer: joomlaspezifisch ein Registry-Objekt, dessen Eigenschaften und Werte man dann mit zugehöriger Klassen-Methode set(...) definieren kann.

Ganz vermutlich findest im parent Controller JControllerLegacy einen Hinweis wie $this->input definiert wird, vielleicht aber auch erst in dessen parent Controller. Ganz vermutlich aus der $app (JFactory::getApplication()) geholt. Musst also schauen, warum dies $app->input null ist und weitere Schritte zurück gehen. Vielleicht ist aber schon $app oder $this "kaputt", obwohl dann die Meldung vrmtl. etwas anders lauten würde.

Sag ja, das sind labyrinthische Wege, die meist an Rom vorbeigehen.

Es riecht einfach nach unvollständigen Core-Dateien, wenn tatsächlich auf Domain und Subdomain exakt die selben Erweiterungen aktiv sind etc.
Auch, dass du das error_reporting nicht umstellen kannst in der configuration.php.

Ansonsten röche es vielleicht erst mal nach einem System-Plugin, das an falscher Stelle einsteigt und die $app kaputt macht / blockiert, sozusagen.

Oder Erweiterungen, die ebenfalls unvollständig vorliegen oder auf Domain abweichend konfiguriert gehören (gibt ja so Blödelsicherheitstools).

Da ist der schnellere Weg, Erweiterungen via DB zu deaktivieren (mit vorher Backup der extensions-Tabelle, natürlich).

Und die schnellsten Wege hab ich dir ja schon genannt.
Zusätzlich fällt mir noch ein: Beide Webspaces lokal runterladen und Unterschiede mit z.B. winmerge rausfinden. Fehlende Dateien etc.