Beiträge von phob

    Heute morgen habe ich wieder "neues" Joomlawissen mir angeeignet. ;) Diesmal: Versionsgeschichte.


    Apropos Geschichte: Man hat mich gefragt, seit wann ich einen bestimmten Beitrag mit einem bestimmten Text versehen habe. Keine Ahnung, irgendwann Anfang des Jahres wohl. Nun möchte ich das doch genauer wissen, allerdings kann ich es nicht durch das Bearbeitungsdatum sehen, da ich diesen Beitrag schon einige Male bearbeitet habe (zeigt nur die letzte Speicherung an). Durch Googlesuchen stieß ich auf "Versiongeschichte", mit ein paar englischen Texten und Bildern (Joomla-Version 3.2.x oder so).


    Jetzt meine Frage an euch: Kann ich eine Versionsgeschichte auch nur für einzelne Beiträge aktivieren, oder geht das nur über die Optionen->Beiträge->Bearbeitungslayout, wo es dann heißt "entweder alles oder nichts"?

    Danke zero24 , dein Hinweis mit dem Link vom Joomla-Magazine hat mich zum Ziel geführt. Hatte nicht in die Plugins gesehen, da gibt es unter den Schnellstartsymbolen eben den Hinweis mit dem EOS der 3.10. Also deaktivieren, schon tauscht es links im Kontrollzentrum nicht mehr auf, perfekt.


    Thema ist erledigt

    Seit dem letzten Update auf die aktuelle 3.10.2-Version wird links im Kontrollzentrum eine Update Information zu Joomla 4 angezeigt. Eine Kleinigkeit natürlich, aber mich persönlich stört es ein wenig und würde es gerne entfernen. Ist das ohne den Core zu bearbeiten, möglich? In den Admin-Modulen konnte ich nichts finden.


    Natürlich weiß ich, dass J!4 draußen ist, aber ich möchte das Update noch ein wenig verschieben.

    Danke Sieger66, auch wenn mich die beiden Seiten nicht so richtig weitergebracht haben in der Beantwortung meiner TE-Frage bzw. der Frage nach der Erklärung Sitzungsspeicher. Bei meinem Glück hätte ich wohl auf der dritten Seite eher Erfolg gehabt - ausgerechnet die wurde nicht archiviert. Das nenne ich "Glück". ^^


    Die Sitzungslänge habe ich erstmal von 100 auf 25 heruntergesetzt, vielleicht hilft das etwas.

    Ich habe etwas mehr gegooglet und etwas interessantes zum Thema Sitzungsdauer/-speicher gefunden: https://openbook.rheinwerk-ver…mla_3/13_002.html#u13.2.8


    Auf meiner Website habe ich bei Sitzungsspeicher auf "Datenbank", und Sitzungslänge auf "100" stehen. 100 Minuten sind wohl etwas viel, werde ich herunterdrehen (vielleicht schon die Lösung für meine Frage?). Allerdings bräuchte ich beim Thema Sitzungsspeicher eine Begriffserklärung um abschätzen zu können, ob für meine Website PHP oder Datenbank besser wäre. Auf der Suche nach einer Erklärung bin ich bei Konfigurationseinstellung - System - Sitzungsspeicher leider auf einen "toten" Link (innerhalb des damaligen Themas) gestoßen. Auch über die Wayback-Website komme ich nicht mehr auf die Erklärung.

    Folgendes Phänomen tritt schon sehr lange auf, aber jetzt möchte ich der Sache doch auf den Grund gehen.


    Auf unserer Website gibt es einen Login-Bereich mit verbandsinternen Informationen, Formularen, etc., die nicht für den "normalen" Besucher bestimmt sind. Mit Klick auf den Loginbutton erscheint das Anmeldefenster. Bei der Eingabe der Zugangsdaten passiert es durchaus und regelmäßig, dass die Website einem "WARNUNG: Die Sitzung ist abgelaufen, bitte erneut anmelden!" ausspuckt, obwohl man die korrekten Daten eingegeben hat. Gibt man die Logindaten nochmal ein, ist man "drin". Woran kann das liegen? Das passiert nicht nur mir, dass passiert bei mindestens 20-25 weiteren Personen, und wer weiß we sich nicht gemeldet hat und dieses Problem kommentarlos hinnimmt.


    Ausprobiert mit Firefox und Opera, Cookies werden akzeptiert, aber passiert auch wenn die Cookies abgelehnt werden.

    Leg dir eine custom.css an. Die wird bei Joomla-Updates nicht überschrieben.

    Achja, da war ja was. Danke, daran hatte ich komischerweise nicht gedacht.


    #offtopic: Früher, gaaaanz früher, wo der FF noch ein Geheimtipp war, hatte dieser Browser wirklich nur das nötigste im Core, alle Gimmicks musste man sich a la Baukastenprinzip zusammenstellen. Glaube, damit hat man sogar den FF angepriesen, schlanker Browser usw. Heute hat das Ding im Core schon viel zu viel KLimmbimm, was kaum jemand benötigt (und erstmal mühsam deaktiviert) und Ressourcen frisst. Wieso nicht mal einen Browser, der nur das Grundlegendste installiert und dann den Hinweis gibt, dass weitere Features im Installer auszuwählen gibt, bzw. als Addon. Damit kämen sicherlich auch weniger internetaffine Menschen klar.

    Die selbe Anweisung habe ich auch im CSS. Und auch seit dem Website-Launch (5 Jahre her) nie verändert. Aber erst seit ein paar Wochen zeigt Joomla das alles mit Helvetica an, die ich schon Jahre auf meinem Rechner installiert habe, sonst immer mit Arial. Das verstehe ich halt nicht, wieso auf einmal der Wechsel, ohne Zutun meinerseit, zu stande gekommen ist.

    Also muss ich wohl oder übel doch die CSS-Angaben umstellen, ist ja gottseidank keine größere "Geschichte". :saint:

    #Offtopic: Das "neue" Firefox gefällt mir auch nicht wirklich, besonders die größeren und hellgrauen Tabs nerven. Aber das kann man (noch) manuell über about:config (browser.proton.enabled)

    Seit ca. 3 Wochen wird mir das Backend (getestet bei zwei unterschiedlichen Joomla-Sites, J!3.9.26 und auch 3.9.27) mit einer anderen Schriftart (Helvetica Neu, war vorher Arial) angezeigt. Anscheinend ist das nicht nur bei meinen beiden Websites so, sondern auch auf der Joomla-Website selber. Zuerst dachte ich, es liegt mit dem generalüberholten neuen Firefox zusammen, aber auch mit Chrome und Opera ist es ebenfalls die "neue" Schriftart. Am Template habe ich ebenso nix geändert. Dass jemand meine Seiten gehackt hat, glaube ich nicht (habe nachgeschaut, nix verdächtiges), zumal, wie erwähnt, auch die Website von Joomla selber mit der "neuen Schriftart" angezeigt wird.


    Klar, ist irgendwie eine Frage des Geschmacks, aber es würde mich interessieren, wie dieser klammheimliche Wechsel zustande gekommen ist. Die Fonts auf meinem Rechner habe ich nicht geändert, und auch auf einen anderen Rechner werden ebenfalls das Backend mit Helvetica-neue angezeigt.


    1.) Woran liegt der stillheimliche Wechsel der Schriftart?

    2.) Könnte man dieses selber lösen? Wenn ja wo?

    Okay, wie Re:Later geschrieben hat, so ist es doch auch bei mir. Der MJ12bot liest tatsächlich nur noch die robot.txt. Ich habe nur den Namen gelesen, aber nicht weiter den Eintrag betrachtet.


    Aber zum eigentlich Thema: In der .htaccess die veralteten Seiten sperren (damt sie später irgendwann nicht mehr gecrawlt werden), ist klar. Wäre ja auch kein Problem wenn es nicht massenhaft wäre. Denn ein Jahr hat 12 Monate, und die Bots (habe nachgeschaut, der Ahrefs-Bot macht ebenfalls mit) variieren anscheinend auch mit der entfernten Zukunft. Denn es werden auch 2030 o.ä. angegeben. Das alles zu berücksichtigen, zumal der Kalender auch über andere Kategorien anzusteuern versucht wird, sprengt jede .htaccess-Datei. Von meiner Arbeitszeit ganz zu schweigen.

    Deshalb habe ich gehofft, dass man irgendwie, vielleicht auch in der htaccess, eine oder ein paar wenige Regeln einträgt die sinngemäß aussagen: alles was in der URL "modjemcal" trägt, bitte nicht crawlen.

    EDIT: Gerade wo ich meinen Beitrag geschrieben habe hat ReLater mir wohl die Lösung gepostet. :thumbup:


    Ich werde den Tipp von Relater nun testen. Danke dir, danke an alle.

    Ich sehe gerade im Accesslog, dass der BingBot immer noch irgendwelche URL-Pfad-Angaben aufsucht, die auf den Terminkalender der Komponente JEM zugreifen. Lustigerweise habe ich den JEM schon seit einem Jahr nicht mehr installiert. Gebe ich jetzt die vom Bot gecrawlte URL ein (z.B https:/www.gartenfreunde-braunschweig.de/?el_mcal_month=6&el_mcal_year=2016&modjemcal_id=166&modjemcal_month=9&modjemcal_year=2012), gelange ich zur Startseite (mit einem HTTP Statuscode 200, manchmal auch 303)


    Wie kann ich in diesem Fall dem Bot sagen, dass er diese Adresse, sowie weitere mit ähnlichem Aufbau, nur andere Monats und Zeitangaben, nicht mehr crawlen soll?


    Und vielleicht könnt ihr mir auch einen Tipp geben, wie ich einen bestimmten Teil der Bots aussperren kann. Denn sowas in der robots.txt wie

    User-agent: MJ12bot

    Disallow: /

    klappt wohl nicht.

    Vor einigen Jahren, zu "Hochzeiten" eines anderen Joomla-Hilfeforums, gab es ein Team inkl. Homepage, wo man Joomla-Fehler in deutscher Sprache melden konnte und dort wurde es händisch, sofern es tatsächlich ein Fall für die Bugliste war, ins englische übersetzt und an die offizielle Stelle gesendet. Leider weiß ich nicht ob a) dieser Service noch existiert, noch b) den Link dorthin.


    Ansonsten gilt für Joomla 4: Lieber etwas länger warten, aber dafür von Start an kein extrem verbugtes Produkt, was einem die Freude auf Joomla nimmt.