Beiträge von Re:Later

    Solche Subdomains hatte ich nie angelegt – auch nicht testweise. Beispiel für derartige URLs sind:
    https://praxis.lebenslust-jetzt.de/
    https://traffic.lebenslust-jetzt.de/
    https://www.www.lebenslust-jetzt.de/

    Na ja, zumindest finde ich sie auf archive.org. 2014/2015+ war, die erste zumindest, regulär online. Erst für 2019 wird dann ein Redirect auf den Provider erkannt:

    Die Praxis - Praxis für Beratung + Psychotherapie - Rottweil

    Auch/Selbst Google-Suche erfindet so Subdomains nicht (deren AI-Halluzinator vielleicht, aber den gabs damals noch nicht). Irgendwo wirst die schon selbst irgendwo verlinkt haben.

    aber warum, wenn es denn mal läuft, sehe ich jetzt immer die Seite "enquirer" wenn ich localhost/meineseite eingebe?

    Warum, weiß ich auch nicht. Was du da siehst ist das README einer Javascript-Bibliothek namens Enquirer. Siehe hier: https://github.com/enquirer/enquirer . Da findest exakt den Text der dir unformatiert angezeigt wird.

    Wird also wohl von irgendeiner Joomla-Erweiterung oder Xampp oder Joomla selbst verwendet und bei dir falsch eingestreut. Deine Seite rendert wohl nicht richtig, also die index.php wird nicht wunschgemäß angezeigt und der erzeugte Inhalt als HTML ausgegeben (vielleicht hilft eine Zeile mit DirectoryIndex index.php in der .htaccess:

    Weitere Infos findest hier (nur die ersten paar Absätze), weil das Gelaber in Github mir um diese Zeit so gar nichts sagt:

    https://www.perplexity.ai/search/was-ist-enquirer-Tz17BNsITziQ.Z_to65z2w?sm

    Vielleicht, wennst den gesamten XAMPP-Ordner (inklusive deiner Seiten) mal nach dem Datei/Ordnernamen enquirer durchsucht, um wenigstens zu wissen, wo das mit drin ist? Ich verwende für so Suchen unter Windows das Programm AgentRansack, weil die WIndowseigenen Suchen grottig sind ;) .

    Nur als Frage - warum sollte man das Erstellungsdatum ändern?
    Es bewirkt auch, dass die Sortierung nach id und erstellungsdatum nicht mehr konsistent ist und das veröffentlichungsdatum vor dem Erstellungsdatum liegen könnte?

    Na ja, da muss man eben aufpassen ;) Und im Backend darf man das Feld mittlerweile ja auch ändern.

    Ich pflege eine Seite, da werden die Artikel in einem Modul nach Erstellungsdatum sortiert und umsortiert (bei Bedarf). Auf der Seite werden halt auch Artikel eingepflegt, die inhaltlich länger zurückliegen, aber eben für November oder so letzten Jahres einsortiert, angezeigt werden sollen. Die einfachste Lösung in diesem Fall. Allerdings schicke ich die Pflegenden gleich ins Backend, weil Frontendediting in vielen Templates schrottige Formulare anzeigen. Bräuchte man also schon wieder ein Plugin, das auf z.B. Cassiopeia umleitet usw. usf.

    Vermutlich gaht das auch via Plugin, aber warum?

    Wenn ich mich im Frontend als SuperUser anmelde (Joomla 6), gibt es da das Feld Erstellungsdatum auch nicht. Ich muss also einen Override der Datei

    components\com_content\tmpl\form\edit.php

    erstellen, wo ich noch ein

    <?php echo $this->form->renderField('created'); ?>

    einbauen, um das Feld überhaupt zu sehen. Das ist bei den Artikeln leider so. Da wird eine Form nicht einfach durchgerendert.

    .

    Beitrag wird dann auch inklusive dieses Datums gespeichert. Und alles ohne Plugin.

    Dann habe ich mir einen User namens "autor" in der Gruppe "Editor" angelegt, im FE als dieser angemeldet, einen Artikel zum Bearbeiten geöffnet und sehe mit obigem Override das Feld ebenfalls, ändere es auf 10.12.2025, und es wird nach Änderung mitgespeichert und ist dann auch im Backend zu sehen: Hat also geklappt:

    Meint in diesem Fall (also Beiträge), dass das Feld created schon vorhanden ist und gar nicht durch ein Plugin manipuliert werden muss, um schön angezeigt zu werden. Kann man natürlich auch. Als Beispiel: Eine Zeile mehr für das fehlende Label. Sieht dann so aus:

    $this->form->setFieldAttribute('created', 'label', Text::_('JGLOBAL_FIELD_CREATED_LABEL'));

    echo $this->form->renderField('created');

    Man kann dann sicherlich auch noch eine Gruppenberechtigungsweiche um den Code herum legen, wenn man andere Benutzergruppen ausschließen will.

    ch habe vorhin auch diesen Wizard Fehler in Akeeba bei IONOS gehabt. Einfach ignoriert und Backup gemacht, es hat geklappt.

    Bei mir war halt so, dass ein Backup, dass am Ende 2GB ausmacht, von gestern auf heute mehrfach von Akeeba "hieroglyphisch" unterbrochen wurde und dann ist der Wizard halt die entsprechende Lösung fürs nächste mal. ANsonsten juckt mich der nur selten und ist Zeitverschwendung.

    RDS

    Interessant wäre noch:

    Welche Joomla-Version ist das exakt???: Riecht nämlich zusätzlich nach "veraltet". Riecht sogar nach Joomla-Version 2. Danach wurde die Datei

    libraries/joomla/environment/request.php

    komplett entfernt.

    Und wenns Joomla 2 ist und du die wirklich meinst weiter zu nutzen wollen, musst wohle den Provider wechseln und damit leben, dass dein Joomla ggf. unsicher ist,

    0 Class "JArreyHelper" not found

    Vermutlich meinst du JArrayHelper in der Meldung und nicht JArreyHelper (e statt a).

    So oder so ist das aber eine komplett veraltete Klasse und muss nicht unbedingt von Virtuemart kommen..

    Natürlich hat Elwood Recht mit den nötigen Updates, aber kannst vorher oder nachher dann probieren:

    Eine umfangreichere Fehlermeldung bekommst du, wenn du in der Joomla-Konfiguration "Fehler berichten" auf Macimum setzt und "System debuggen" auf Ja. Dann probierst noch mal, was du oben gemacht hast, kopierst die komplette Meldung (den sog. Backtrace) hierher.

    UND DEAKTIVIERST BEIDE EINSTELLUNGEN GLEICH WIEDER!!!

    Ich hatte gerade eben identisches Problem mit dem Akeeba-Wizard bei Ionos. Eine Änderung der max_execution_time via php.ini ändert gar nix bei mir bei der betr. Seite. Bin allerdings sicher, dass das mal bei anderer Seite geklappt hat.

    phpinfo-Ausgabe (wie von mir eingestellt) PHP8.4:

    Auch diverse andere, höhere Werte bis hoch auf 360 versucht. 6 Minuten "too low" (vom Wizard) ist albern.

    Man kann jetzt streiten, ob Ionos Schrott ist, was ich ja schon länger behaupte ;) oder, ob der Akeeba-Wizard.

    RDS

    Deine PHP-Version ist vermutlich zu hoch für dein Joomla 3.Um die geht es in diesem Thread. PHP 8 funktioniert nicht immer.

    Stelle aber erst mal das "Fehler berichten" in der Joomla-Konfiguration von maximum auf eine niedrigere Einstellung. Dann bist das meiste an Meldungen schon mal los.

    In der configuration.php sind das dann Werte für das error_reporting: default oder none oder simple. Musst ausprobieren. Also

    public $error_reporting = 'default';

    oder

    public $error_reporting = 'none';

    oder

    public $error_reporting = 'simple';

    Beide Versionen funktionieren fehlerfrei und administrator/cache/language ist Geschichte.

    Sisyphos sagt: "Ja, aber doch nur bis zum nächsten Joomla-Update. Andere, vielleicht wichtige Änderungen wirst regelmäßig durchsehen müssen."

    Wie gesagt, irgendeine "Magie" räumt die Dateien sowieso immer mal wieder auf. Die höchste Zahl an Dateien war bei mir übrigens 800, was wohl daran lag, dass ich Sprach-Overrides getestet habe und die Dateien dann mit einem Zeitstempel nochmals angelegt werden. 800 klingt viel, aber waren auch nur paar Popel-MB unter 10MB.

    Beachten muss man auch, wenn einen die Sache nervt: Es werden auch Sprachdateien von deaktivierten Erweiterungen gecachet (z.B. eine Komponente von mir). Wohl weil die Titel ja trotzdem unter "Erweiterungen verwalten" korrekt angezeigt werden sollen.

    Meint: Weniger "installierter Schrott" reduziert auch die Cache-Dateien-Anzahl.

    Mehrsprachigkeit erhöht sie.

    Aber, mir gefällt das auch nicht so wirklich, wie das jetzt ist und, dass es nicht dokumentiert wurde.

    Wie kann man das verhindern?

    Hatte ich ja oben schon erwähnt, dass man das nicht verhindern kann. Die Anzahl der Dateien schwanken halt. Mal gehts rauf, mal gehts runter. In welchen Zeitintervallen da wohl ein Teil automatisch gelöscht wird, weiß ich nicht.

    Warum das von Joomlas normalen Cacheeinstellungen abgekoppelt ist, wird im oben verlinkten GitHub-PR erwähnt, ich verstehs aber nicht. Nervig ist halt, dass es bei mir Fehler veursacht, die man nur schwer testen/debuggen kann, weil eben nicht deaktivierbar.

    Welchen Sinn hat dieser Speicherfresser und wofür wird er benötigt?

    Man spart sich, so nimmt man an, ein paar Millisekunden beim parsen (also einlesen) und aufarbeiten der vielen, vielen INI-Sprachdateien, die beim Laden einer einzelnen Seite geparst werden müssen. Ich selber ziehe die Messungen aber in Zweifel, da an der urspünglichen Language-Caching-Routine schon wieder geändert wird.

    [6.0] Cache language files by HLeithner · Pull Request #45289 · joomla/joomla-cms
    Summary of Changes Add a caching layer to the languageHelper::parseIniFile method. Benchmark the function on within the system is not easy the the performance…
    github.com

    Kann er abgeschaltet oder gelöscht werden?

    Ersteres nein, zweiteres Ja (geht auch aus dem Backend, indem man die betr. Cache-Gruppe wählt). Werden dann halt wieder erzeugt.

    Und scheint auch unter bestimmten Umständen nicht korrekt zu funktionieren bzw. ohne weitere, auszutüftelnde Codeanpassungen sonstwo bei Updates auf J6:

    Man muss aber leider einen neuen Titel vergeben und speichern.
    Den defekten Beitrag in den Papierkorb werfen und kann dann dem neuen Beitrag den früheren Titel geben.

    Du kannst auch eine neue Kategorie anlegen für die neu erstellten Beiträge. Dann solltest die Titel/Aliase nicht ändern müssen.

    Später kannst diese Beiträge dann in die richtige Kategorie verschieben, wo du die alten, defekten auch aus Papierkorb gelöscht hast.

    Muss es denn unbedingt der Artikel-Alias sein, weil für den müsste man eine extra Datenbankabfrage machen, vorher ermitteln, ob die aktuelle Seite überhaupt eine Artikel-Ansicht ist ... etc.

    Die Artikel-ID findet sich im $active-Dingens irgendwo. Ich glaub im $active['query']-Array. Vielleicht leichter?

    Oder andere Idee: Nimm den Beispiel-Code von https://ghsvs.de/programmierer-…n-eigener-codes. Also nur (Rest ist uninteressant für dich):

    $aktuellerSeitenPfad = \Joomla\CMS\Uri\Uri::getInstance()->getPath();

    Diese Variable kannst dann anhand der Schrägstriche zerlegen und der letzte Teil nach dem letzten Schrägstrich ist dann meist der Artikel-Alias.