Gelegentlich sind Fehlermeldungen auf "toten Seiten", die Joomla anzeigt, nicht ausreichend, um die Fehlerquelle zu identifizieren, also die Erweiterung, die einen Fehler verursacht.

Um mit etwas Glück die Fehlerstelle zu finden, tue Folgendes:

Gehe in die Joomla-Konfiguration.

- Im Reiter "Server" findest du die Einstellung "Fehler berichten". Setze sie auf "Maximum".

- Im Reiter "System" findest du die Einstellung "System debuggen". Setze sie auf "JA".

- Speichere die Joomla-Konfiguration.

Solltest du die Joomla-Konfiguration im Backend nicht bearbeiten/speichern können, weil sich dort der Fehler eingeschlichen hat:

Prüfe, ob du die Datei configuration.php in deinem webspace mit FTP bearbeiten kannst.

Die Schreibrechte (Dateiattribute) auf die Datei configuration.php muss auf (644) gesetzt werden, wenn diese per FTP überschrieben werden soll, z.B. wenn sie mit einem Editor "lokal" bearbeitet wurde. Ansonsten reichen, die bestehenden Rechte (444).

- Bearbeite die Dateie configuration.php im Joomla-Hauptverzeichnis mit einem geeigneten Texteditor (z.B. Notepad++).

- Ändere darin diese 2 Zeien wie folgt:

public $error_reporting = 'maximum';
public $debug = '1';

- Unter Joomla 4 änderst du die 2 Zeilen so:

public $error_reporting = 'maximum';
public $debug = true;

Da einige Templates blöde sind und auf ihrer Fehlerseite ungenügende Daten anzeigen, ist es empfohlen, die Datei error.php im Templateordner, falls vorhanden, vorübergehend umzubenennen, z.B. zu errorxxxxxx.php. So ist gewährleistet, dass die Fehlerseite von Joomla verwendet wird.

Gehe dann noch mal auf die "tote Seite" und sieh nach, ob sie jetzt mehr anzeigt.

Von besonderem Interesse ist der so genannte "Call stack", eine Liste, die den Weg zum Fehler von unten nach oben anzeigt.

Beachte, dass, nicht unbedingt die oberste Zeile die Ursache für den Fehler ist, nicht unbedingt die Code-Stelle ist, die man korrigieren muss. Häufig findet man in den Zeilen darunter einen Hinweis auf eine Erweiterung, die den Fehler auslöste, z.B., weil sie eine falsch formulierte Anfrage abschickte, mit der Joomla etwas später nichts anfangen kann.

Aber auch ausführlichere Datenbankabfragen-Fehler werden vielleicht in diesem Bereich ausgegeben, die Joomla im Normalfall nur verkürzt ausgibt.

Vergesse nicht oben gemachte Einstellungen, vor allem "System debuggen", nach Problemlösung wieder zurückzusetzen.

Es geht dabei nicht um Notices und Warnings, die dann vielleicht zuhauf angezeigt werden, sondern um die Liste, die dann ca. so aussieht, wie in diesem Post:

Problem bei PHP Update 7.0.28 -> 7.1x

Also dieser "Call stack"

In der Joomla-Konfiguration:

"Fehler berichten" auf "Maximum".

Debug-Modus (System) aktivieren.

Auf der Fehlerseite siehst dann eine Liste, die den Weg zum Fehler anzeigt.

Später, wenn Fehler behoben, nicht vergessen, alles wieder zurückzusetzen.

Zitat von Neewmla

Hab aber einen Account mit Adminrechten bei Joomla.

Dann kannst du, wenn du damit Super User meinst (Administrator-Gruppe weiß ich nicht), die Dateien auch via Template-Manager im Joomla-Backend bearbeiten. Vielleicht macht aber die Template-error.php eh schon was sie soll und zeigt die besagten Daten auch an. Gelegentlich halt nicht. Kommt aufs Template drauf an. Wenn du Protostar verwendest, ist das gegeben.

Zitat von axl-g

die über weblinks erfast wurden

Wie immer wäre halt ein Link zur Seite ein schnellerer Weg zum Ergebnis.

Hier mal die Vorstufe. Setzt voraus, dass die Seite jquery lädt, was Joomla 3 ja fast immer macht:

<script>
;(function($)
{
    $.fn.addTargetBlank = function()
    {
        $("a[href^='http://'], a[href^='https://']")
            .attr('target','_blank')
            .addClass("externerLink");
    }

    $(document).ready(function()
    {
        $.fn.addTargetBlank();
    })
})(jQuery);
</script>

Jetzt musst halt noch rauskriegen, welche eindeutige Klasse ein alle Links umgebender Container der Weblinks hat. Ich fantasier jetzt mal, das ist ein DIV mit Klasse "weblinks"

Dann musst so ergänzen

...
        $(".weblinks a[href^='http://'], .weblinks a[href^='https://']")
...

Wenn dann für JS

JHtml::_('script', 'mod_test/blah.js', array('version' => 'auto', 'relative' => true));

Einen 500-Fehler mag ich mir eigentlich nicht vorstellen, da diese Zeilen einfach nix tun, wenn die Datei nicht existiert.

Stelle in solchen Fällen "Fehler berichten" auf "Maximum" (Was man beim Entwickeln eh machen sollte) und aktiviere den Debugmodus in der Joomla-Konfiguration. Letzterer zeigt dann oft den Weg zum Fehler. Wenn du dann noch die error.php deines Templates durch Umbenennen deaktivierst, kannst sicher sein, dass alles ausgegeben wird, was Joomla eben an Fehlerhinweisen auf solchen toten Seiten ausgeben kann.

Nicht nur Gräußlichkeiten, sondern auch schlicht Falsches. Gestern hatte ich ein Beispiel, wo eine englische Kernaussage in das exakte Gegenteil übersetzt wurde.

Wer z.B. das Plugin JCH-Optimize verwendet, die Ihre Deutschen Sprach-Dateien von Google Translate übersetzen lassen, weiß ein Lied davon zu singen, was für Quark dabei herauskommen kann. Selbst, wenn man weiß, wozu eine Einstellung da ist, weiß man es spätestens nach lesen der DE-Übersetzung nicht mehr

Es gibt ja auch Dienstleister für Übersetzungen.

Zitat von hajo808

Nach der Änderung war die Seite nicht mehr aufrufbar.

Dann hast du was falsch gemacht. Ich poste solche Vorschläge erst nachdem ich sie selbst getestet habe. Sieht man auch an deinen Fehlermeldungen. Aber ist ja jetzt alles gut

Es ist einfach Konvention, dass (nicht nur) Module Ihre CSS, JS in Joomlas /media/-Ordner ablegen. Dein <media folder="media" destination="mod_test"> ist also die empfohlene und richtige Art.

Warum?

1) Wenn du dir die Standard-robots.txt von Joomla anschaust, findest du eine Zeile "Suchmaschinen sollen nicht im Ordner /modules/ rumsuchen". Z.B. Google meckert dann aber, wenn deine CSS und JS darin für Bots gesperrt sind.

2) firstlady hat dir oben eine Zeile geliefert, die

a) die Eingabe für dich vereinfacht.

b) es Usern erleichtert Overrides der CSS und/oder JS in ihrem Templateordner zu hinterlegen.

c) dir die Kontrolle insofern etwas erleichtert, weil in deinem Seitenquelltext die CSS nicht erscheint, wenn sie gar nicht existiert (du was falsch gemacht hast).

Am Beispiel einer blah.css deines Moduls in /media/mod_test/css/. Der Ordner wird angelegt, während du das Modul installierst!!

JHtml::_('stylesheet', 'mod_test/blah.css', array('version' => 'auto', 'relative' => true));

Das relative=true sorgt dafür, dass erst im Template des Benutzers gesucht wird, ob eine Datei

/templates/TEMPLATENAME/css/mod_test/blah.css

existiert. Wenn ja wird diese gezogen. Wenn nein, wird automatisch die

/media/mod_test/css/blah.css

genommen.

Lässt du das relative=true weg, musst du den ganzen Pfad zur CSS in der JHtml-Zeile angeben. Verbaust aber Nutzern die Möglichkeit von Overrides.

Diese JHtml-Zeilen kannst du (nahezu) zu jedem Zeitpunkt in jeder PHP-Datei des Joomlas bzw. deines Moduls angeben.

Wenn du dich rantraust:

In der Datei

modules/mod_icemegamenu/helper.php

und Datei

modules/mod_icemegamenu/libs/menucore.php

alle Vorkommen (ich zähle 4) von

&JSite::getMenu()

austauschen gegen

JFactory::getApplication()->getMenu()

Fehler berichten auf "Keine".

Dann hast etwas Ruhe denke ich. Aber Rest wurde dir ja schon gesagt, dass das icemenu total veraltet ist und von alleine irgendwann sterben wird, falls die Macher kein Update rausbringen.

EdIT: Ah, sehe gerade da war Indigo66 schneller

Mir ging es ausschließlich um die Fehlerseite auf der dir

Zitat

Die angeforderte Seite konnte nicht gefunden werden!

Fehler: 0 - Using $this when not in object context

angezeigt wird und dort auch nur der Teil der auf die Fehlermeldung folgt. Da sollten dann einige durchnummerierten Zeilen erscheinen:

0 - irgendwas

1- sonstwas

2 - irgendsonstnochwas

Die ganzen Notices und Warnings sind nicht von Interesse.

Deshalb auch der Hinweis, die error.php umzubenennen, da dann sichergestellt ist, dass die keine Menüs und Kram lädt, die zu viele andere Meldungen produzieren.

Du weißt, dass ab/auf Joomla 3.8.13 nur noch Super Users Joomla aktualisieren dürfen? Vielleicht deshalb?

Stelle fehler berichten in der Joomla-Konfiguration auf Maximum.

Aktiviere den Debugmodus (für System).

Deaktiviere vorübergehend die error.php in deinem Templateordner durch umbenennen.

Dann sollte dir ein ausführlicher Weg bis zum Fehler angezeigt werden.

Vergiss nicht alles wieder rückgängig zu machen, wenn Problem gelöst.

Nach einem umfassenderen Sicherheits-Audit, das auch andere Punkte bzgl. Privatsphäre und Nutzerwünschen beleuchtete, wurde gestern u.a. diese Entscheidung bekannt gemacht:

https://www.sueddeutsche.de/di…r-dicht-gemacht-1.4162352

Mit Folgen für APPs, die mit Zugriffen auf Google-Services arbeiten ("granularer einstellbare Berechtigungen"):

https://www.blog.google/techno…-security/project-strobe/

In einem Override des mod_menu/.../default_component.php nach Zeile defined('_JEXEC') or die;

Beispiel: Artikel nicht älter als 2 Tage (Zeile 18 anpassen).

$Query = $item->query;
if ($Query['option'] === 'com_content' && $Query['view'] === 'category' && $Catid = (int) $Query['id'])
{
    $db = JFactory::getDbo();
    $query = $db->getQuery(true);
    $query->select($db->qn('created'))
    ->from('#__content')
    ->where($db->qn('state') . ' = 1')
    ->where($db->qn('catid') . ' = ' . $Catid)
    ->order($db->qn('created') . ' DESC');
    ;
    $db->setQuery($query);
    $lastDate = $db->loadResult();
    
    $lastDate = strtotime($lastDate);
    
    // nicht älter als 2 Tage
    $intervall = 2 * 24 * 60 * 60;
    
    if ($lastDate > (time() - $intervall))
    {
        $item->menu_image = 'images/powered_by.png';
    }
}

Wenns dann noch für ein bestimmtes Menü sein soll, kannst noch so was

$item->menutype === 'aboutjoomla'

im if in Zeile 2 verwenden.

Wenns nur die oberste Menuebene sein soll

$item->level == 1

Und je nach Art deiner Menüs, musst wohl noch Fehlerprüfungen einbauen if !empty(xyz) - Gechichten vor dem if in Zeile 2. Siehst ja dann, wenn du "Fehler berichten" auf "Maximum" setzt, ob Warnings angezeigt werden.

Keine Ahnung, welche Auswirkungen das Feld "Zugriffsebene" in den Schlagworten hat, aber wäre mein erster Versuch.

Setze in der configuration.php

public $error_reporting = 'maximum';

Schau, ob Meldung kommt.

Deaktivier dann mal alles von AutoTweet (Extly). Denke, da läuft es drauf hinaus. Falls AutoTweet nicht aktuell ist, aktualisieren. Hab jedenfalls vor 2 Tagen eine Email bekommen, dass da "ganz duftes", neues Update gibt.

[4.0] XAMPP727. Template Manager. Saving of files fails. #22535

Zitat von Re:Later

Weiß nicht, ob das schon gemeldet ist?

https://github.com/joomla/joomla-cms/pull/22534

Ein Debuggen ist mir leider nicht möglich, da mich bei Betreten der Konfiguration ein

Class 'Joomla\CMS\Form\Field\JText' not found in JROOT\libraries\src\Form\Field\PluginsField.php:173

EDIT: Sehe gerade deinen Post. Das fällt unter

Zitat von Re:Later

(Kommen dann zwar ein paar andere Bugs durch kürzliche "Improvements" neu hinzu, die noch in der Warteschleife hängen, aber in anderen Bereichen. )

Änderst in o.g. Datei Zeile 173 von

if (count($this->options) === 1 && $this->options[0]->text === JText::_('JOPTION_DO_NOT_USE'))

nach (Text statt JText).

if (count($this->options) === 1 && $this->options[0]->text === Text::_('JOPTION_DO_NOT_USE'))

Weiß nicht, ob das schon gemeldet ist?

Zitat von chr-hl

Recoverable fatal error: Object of class Joomla\Component\Admin\Administrator\Service\HTML\PhpSetting could not be converted to string in C:\xampp729\htdocs\j4a520181007\libraries\src\HTML\HTMLHelper.php on line 149

Das kannst du durch installation des Patchtesters "Patch Tester 3.0.0 Beta 4" und installieren des PRs "22512" beheben.