Beiträge von Re:Later

    Na ja, die Seite wurde großflächig gehackt. Mehrere Dateien, in die unterschiedlichster Schadcode eingesetzt wurde, der sich überall befinden kann und nicht nur in diesen paar, die mit Sicherheit gehackt wurden.


    Joomla 3.5 ist eben eine bekanntermaßen unsichere Joomla-Version und Hacker hatten viel Zeit bei Euch Lücken zu nutzen und eigene Hintertüren (neue Lücken) in den Webspace Joomlas einzubauen.


    Hier findest du erste Schritte: Mein Joomla wurde gehackt! Was kann ich tun?

    Was kann ich machen?

    Nachdem du die Seite sofort per .htaccess geschlossen hast, selber bereinigen (nicht einfach und keinesfalls so einfach wie es scheinen könnte, wenn man die "Anleitungen" liest!), bereinigen lassen oder die Seite komplett neu aufsetzen. Dabei bei der Übernahme alter Dateien wie z.B. /images/-Ordner immer daran zu denken, dass in jedem Ordner und in jeder ausführbaren Datei (js, PHP usw.) Schadcode sein könnte und neue Dateien hochgeladen sein könnten, die bei flüchtigem Blick komplett harmlos aussehen vom Dateinamen her. Z.B. scheinbar Bilder...

    Dafür musst du bei deinem Provider anfragen. Bei meinem war der Wechsel umsonst (und zufällig, weil ich eigentlich nur die Datenbank-Version erhöhen wollte).


    Bezüglich "Server Push"-Features, die damit auch möglich sind, dort dann ggf. tatsächlich mit weiteren Tools, sollte man sich sehr gut informieren, weil hier nicht gilt "Viel hilft viel".

    In der alten Seite wurde eine CSS-enthaltende Datei

    http://www.nmmse.at/plugins/ed…ypography/typography2.php

    geladen.


    Auf der neuen nicht mehr. Wie schoin vermutet, ist also der JCK-Editor nicht mehr kompatibel. Der ist zuständig für das Laden. Welches der gefühlten 2000 Plugins, die der dabei hat, kann ich dir leider nicht sagen.


    Aber es ist bekannt, dass der JCK mit neueren Joomlas nicht mehr kann. War mir anfangs nur nicht sicher:

    "JoomlaCK-Editor ". Bin nicht ganz orientiert, aber gehört der nicht zu "Leichen" und wurde schon lange vom ARK-Editor abgelöst?

    Gib uns einen Link zum Problem. Riecht ja dann eher danach, dass eine CSS-Datei nicht geladen wird.


    Interessant wäre deshalb auch von welcher Version du das Update gestartet hast. Es gab da nämlich mal eine Änderung, die das verursachen könnte, wenn man veraltete Erweiterungs-Versionen und/oder Templates verwendet.


    "JoomlaCK-Editor ". Bin nicht ganz orientiert, aber gehört der nicht zu "Leichen" und wurde schon lange vom ARK-Editor abgelöst?

    1.) ist das Updaten von Joomla 3 auf Joomla 4 nicht so dramatisch wie von 1.5 auf Joomla 2. So grundlegende Daten wie Beiträge sollten problemlos "rübergehen". Du musst also gar nicht ganz neu anfangen, sondern updatest die Seite auf Joomla 4, ggf. eine Kopie davon, nachdem du alles an zuinstallierten Erweiterungen, Templates etc. vorher deaktivierst, und entrümpelt die Seite danach durch Löschen und Deinstallieren, abgesehen von Beiträgen, Kategorien, Menüs usw.


    2.) Ob Tools wie J2XML, mit denen du auf jeden Fall in allen Joomla-Versionen auch Beiträge exportieren, sogar direkt von Joomla nach Joomla "rübersenden" kannst unter Joomla 4 bzgl. Import noch funktionieren werden, weiß nur der Entwickler ;)

    Aber was müsste ich tun, wenn ich die Url´s dort ändern möchte?

    So wie ich Joomla kenne, muss man da gar nichts sonst tun.


    Du legst einen Menüeintrag, z.B. vom Typ "Benutzer > Benutzername erneut zusenden an", den du ja auch verstecken kannst im Frontend-Menü. Dann sollte der Link "Benutzername vergessen" nach meiner Denke gehübscht sein, also den Alias deines Menüeintrags drinnen haben statt index.php?undsoweiter .

    Indem du für die betreffenden Seiten Menü-Punkte anlegst.


    Aber anstatt sie "suchmaschinenfreundlich" zu machen, gebe ich so Menüeinträgen eher ein robots: "noindex,nofollow", weil Suchmaschinen die gar nicht im Suchindex, in Suchergebnissen anzeigen sollten. Ja nur verschwendet.

    Der margin-bottom wurde von dir im Editor für das Bild eingesetzt. Das nennt sich dann "Inline-Stil".

    Code
    <img style="margin-right: 20px; margin-bottom: 20px; vertical-align: top; float: left;" src="/images/union/Radsport/2019_Beiträge/Flachau_01.jpg" alt="News Rad" width="150" height="101">


    Das Template lädt Bootstrap-4-CSS, aber im HTML sehe ich fast nichts, was das dann auch nutzt.

    Ah OK, das mit dem Piktogram hab ich überlesen. Ist meins natürlich hinfällig ;)

    Ist mir schon klar - unklar ist mir aber woher diese willkürlichen Einzüge kommen.

    Die verursachst du selber durch deine Inline-Stile, die du individuell in jedem dieser Blöcke setzt.


    Siehe mein Bild: Du hast ein Bild mit reichlich Inline-Stilen bestückt. Darunter z.B. ein margin-bottom (gelber Rand im Bild) Zusätzlich floatet das Bild links. Heißt für folgende Elemente, sie "hakeln am gelben Rand fest".


    Dein altes Template hat sich darum gekümmert, dass die Blöcke genügend Abstand haben und das float auflösen.


    Beim neuen wundere ich mich gerade, dass das zwar einige CSS-Klassen im HTML gestreut sind, aber im CSS-Datei und Inspektor gar nichts davon zu finden ist, was formatieren würde. Bist sicher, dass alle nötigen CSS-Dateien geladen werden? Schaut für mich jedenfalls komisch aus.


    Jetzt kommt halt der Rattenschwanz, weil Artisteer mit Java-Script dazwischenpfuscht und eigene Breiten per Inline-Stilen reindingst. Auch deshalb ist Artisteer so beliebt ;)


    Geh mal auf die tipps und teste mit kleineren Browserfenster-Breiten. Also Fenster zusammenschieben. Dann siehst, dass plötzlich die Bilder die 200px nicht mehr einhalten und der Kratzbaum riesengroß wird.


    Könntest du vermutlich mit einem zusätzlichen, unschönen !important

    CSS
    max-width: 200px !important;

    in deinen Blöcken verhindern.


    Die 2-spaltigen:

    Code
    .blog .items-row.cols-2 img {
     width: 100%;
     max-width: none;
    }

    Der Block sollte nach deinen beiden bisherigen stehen.

    Wahrscheinlich brauchen beide Zeilen jetzt auch ein !important.


    Und zusätzlich

    Code
    .blog .items-row.cols-2 .img-intro-left {
    float: none;
    }

    Gibt es irgendwo Einstellungen die dieses Verhalten verursachen?

    Hat einfach was mit Schriftgrößen, Zeilenhöhen, Margins usw. der beiden Blöcke (Bild und Text zu tun). Bei deinem Original hast halt "Glück", dass du eine Bildschirmgröße verwendest, wo der Text rechts gerade noch eben so am linken Block festhakelt.


    Hier z.B. Smartphone-Ansicht der Originalansicht:



    Deshalb bevorzuge ich (wenn ich darf) Bilder rechts (EDIT: oder drüber/drunter) statt links, um den Text-Lesefluss nicht zu stören..


    EDIT: Immer mal wieder im Firefox Extras > Web-Entwickler > Bildschirmgrößen testen verwenden, um Überraschungen und sinnloses Detailgefrickel zu vermeiden.

    1.) Menüs > Verwalten > Neues Menü: Benennung beliebig, z.B. "Test".

    2.) Menüs > Menü "test" > Neuer Menüeintrag

    3.) Titel "Übersicht" oder sonstwas.

    4.) Menüeintragstyp: "Menüeintrag-Alias"

    5.) "Verlinken mit": der echte Menüeintrag der übergeordneten Kategorieliste oder Blog oder was.

    6.) Neues "Navigations-Modul"

    7.) "Menü auswählen": "test"

    8.) Modulstil: "System > none"

    9.) Menüzuweisung: "der obige echte Menüeintrag der Kategorieliste"

    10.) Modulposition: was erfundenes, z.B. "zur-uebersicht-pagination"


    11.) Override erstellen:

    - In's Template gehen (nicht Stil, sondern Template)

    - Override für Plugins > Content > Pagenavigation

    - Neu erstellte Datei im Templateordner html/plg_content_pagenavigation/default.php bearbeiten


    - Zwischen diese Zeilen 25 und 26 (https://github.com/joomla/joom…/tmpl/default.php#L25-L26) reinschieben:

    PHP
    <?php
    $uebersicht = JHtml::_('content.prepare', '{loadposition zur-uebersicht-pagination}');
    if (trim($uebersicht))
    {
        echo '<li class="uebersicht">' . $uebersicht . '</li>';
    }
    ?>

    Ergebnis:

    Sieht im Bild so puristisch aus, weil ich ein Template verwende, das halt jetzt noch CSS-Nacharbeit benötigen würde, um das zu hübschen. Ist dann halt der nächste Schritt, der im Normalfall mehr Arbeit ist als die Aktionen oben. Der berühmte Rattenschwanz.


    Oft ist es dann praktischer gleich noch ein Eigenes Layout / Alternatives Layout für das mod_menu anzulegen. Weiß man nicht.

    Wie kann man dann trotzdem die Benutzerdaten ändern ?

    Durch Eingabe eines direkten Links im Frontend. Ich schätze (habe gerade kein passendes Joomla zum Testen) z.B.

    Code
    www.examplae.org/index.php?option=com_users&view=profile&layout=edit

    sollte im Frontend für angemeldeten Benutzer sein Profil anzeigen.


    Es gibt mehrere Varianten, die irgendwie in Frage kommen könnten. Je nach Joomla-Seite.

    Wenn ich beim anmelden auf Passwort vergessen drücke fragt er ja nach der Email die im Backend hinterlegt ist und schickt zum ändern des Passwortes einen Link oder so.

    Im Backend habe ich allerdings da nur Kauderwelsch eingegeben - also existiert quasi keine Email dafür.

    Wie kann man dann trotzdem die Benutzerdaten ändern ?

    Auch hier "habe gerade kein passendes Joomla zum Testen". Ich weiß nicht genau wie das Prozedere in Joomla im Hintergrund abläuft. Ob vielleicht durch so eine Aktion der User in der Datenbank blockiert wird. Egal, ob nun Email geschickt wird oder nicht. Eigentlich wärs ja blöd, wenn dem so wäre ;) Ich weiß es halt nicht gewiss.

    Habe das Plugin installiert und hoffe das Problem ist damit gelöst.

    Einfach ausprobieren. Wenn du die Einstellungen so gesetzt hast, dass du im Backend als Super Admin das betr. Konto trotzdem ändern darfst oder generell aus Backend erlaubt ist, kannst ja die Daten wieder zurücksetzen, falls du jetzt wider Erwarten doch was ändern darfst.


    Wenn's nicht funktioniert, gib Rückmeldung. Dann korrigiere ich das.

    Ein angemeldeter Benutzer kann seitens Joomla immer im Frontend seine Benutzerdaten ändern. Siehe meinen einleitenden Texte unter dem Link von mir, warum ich mich zu diesem Plugin entschlossen habe.

    Zitat

    Joomla bietet bzgl. Profiländerungen diverse Wege und Schliche, was das Blockieren ohne Plugin entsprechend aufwendig macht. Man muss an mehreren Code-Stellen ansetzen, für mehrere Dateien Overrides erstellen oder in der Datenbank einen so genannten Trigger anlegen, der aber das Speichern von Nutzerdaten auch für SuperUser blockiert, also auch der Administrator muss den Trigger erst wieder entfernen, bevor er die "getriggerten" Benutzerdaten ändern kann, dann den Trigger wieder anlegen. Zwischenzeitlich ist die Blockierung nicht mehr aktiv und es kann doch wieder ein Spielkind was ändern. Nervt irgendwann.

    Es gibt also weitere Möglichkeiten, die aber aufwendiger sind, wenn nur 1, 2, 3 Accounts blockiert werden sollen.

    Das müsste jetzt der Schreiber doch genauer definieren. Was ist denn das Problem dabei, wenn ein User sein Passwort ändern kann? Eigentlich ist das sogar gut so, wenn User ihr Passwort immer mal wieder erneuern. Die wenigsten machen das. Halt unpraktisch.


    Und sollte es um ein konto gehen, dass mehrere User verwenden, wo dann jemand die anderen durch Änderung aussperrt, ist das grundlegend eh eine schlechte Idee.


    Ich hab dam mal ein Plugin geschrieben: https://www.ghsvs.de/programmi…ten-nicht-aendern-duerfen

    (Download am Ende der Seite.)


    Es verhindert zwar nicht, dass jemand ins Bearbeitungs-Layout kommt, wenn er angemelkdet ist, aber alle "Änderungen" werden geblockt. Zu blockende User kann man im Plugin einstellen.


    Wenn ein nicht angemeldeter Benutzer in irgendein Bearbeitungs-Layout kommt... gut, dann ist das vermutlich ein Problem, wenn der dann irgendwas unerlaubt bearbeiten kann.