Beiträge von Re:Later

    Im Joomla-Normallfall nimmt man die Datei htaccess.txt, nennt sie in .htaccess um und fügt die AddHandler-Zeile an den Anfang zusätzlich ein.
    EDIT: Sollte es dann zu Fehleranzeigen kommen, kann es sein, dass man noch einzelne (wenige) Zeilen, je nach Provider, deaktivieren muss.


    Die htaccess.txt ist immer inaktiv. Es ist egal, ob sie da rumliegt oder nicht. Nur explizit .htacces benannte Dateien tuen was.

    Zitat

    Was genau muss da aber drin stehen?


    Das hängt vom Provider ab. Gibt verschiedene Varianten für die notwendigen Zeilen in der .htaccess. Bei paar geht gar nicht.
    Also Hoster fragen. STRATO antwortet aber z.B. das ginge nicht. Geht aber doch.


    Ausprobieren. Wenn die Seite sich aufhängt (misconfiguration), falsche Zeile. Wenn nicht, in Joomla-Backend nachsehen unter Systeminformationen, ob PHP umgeswitcht. Sowohl im Tabulator Sys-Informationen als auch PHP-Informationen möglich.


    Paar Hoster bieten mittlerweile auch die Möglichkeit, das direkt pro Domain in der Domainverwaltung einzustellen.

    Würde ich nur meine alten Posts in den diversen Foren selber wiederfinden. Also noch mal:


    1) Versuche die URL in der Browseradresszeile aus. Der Updateserver ist seitens Betreiber tot. Kein SSL-Zertifikat. Weiters 404.
    Joomla deaktiviert dann den Server vorübergehend. Versucht ihn aber unter bestimmten Voraussetzungen erneut.


    2) Bei Updates einer Erweiterung, in der der Programmierer einen neuen Updateserver eingetragen hat, behält Joomla leider den alten bei, legt aber den neuen zusätzlich an, der dann (3x Holz) funktioniert.
    Das ist ein Joomla-Bug, bereits reportet, aber der Fix nicht so ganz trivial (an dem ich mich auch schon versucht habe, aber zu zeitaufwendig für den Moment.).


    3) Prüfe unter Erweiterungen > Verwalten > Aktualisierungsquellen, ob die Erweiterung einen weiteren, funktionierenden Updateserver hinterlegt hat. Wenn ja, bist du auf der sicheren Seite und hast halt nur nervige Meldungen bzgl. des alten.


    4) Wenn du durchsteigst, kannst du in der DB die defekten Updateserver löschen. Nicht ganz trivial, da mehrere Tabellen. Und gelegentlich ist ein solcher ja nur vorübergehend off, weil jemand vergessen hat, ihn korrekt umzuleiten. Und kein Nutzer der Erweiterungen es für nötig hält, den Programmierer zu informieren.

    Ich habe vorhin ein Tutorial angefangen und stelle ein Demo-Plugin mit ein, das ein Telefonfeld einfügt und sendet. Dauert aber wohl noch 1, 2 Tage bevor es online geht, da es noch gegengelesen werden muss, bevor ich freigeben darf (nicht meine Seite).

    Das geht nicht die contact.xml per Template-Override zu überschreiben. Sie wird ignoriert.
    Weitere Felder sind im JForm-Objekt ($this->form) also auch nicht vorhanden.
    Damit laufen deine Anzeigezeilen in's Leere.


    Du benötigst ein System-Plugin, das
    a) mit Plugin-Event onContentPrepareForm eigene Felder aus eigenem XML zulädt. (Dann werden sie im Override auch angezeigt.)
    c) mit Plugin-Event onSubmitContact die eigenen Felder nach Sendenklick ausliest und an den Message-Text (den body der Email) anhängt.

    Code
    1. public function onSubmitContact(&$contact, &$data)
    2. {
    3. $data['contact_message'] = 'Ich bin jetzt der neue email-Text.';
    4. }

    @petraki


    Die zeile dient dem Zweck eine derzeit vermehrt auftretende Hackerzeile zum Erschleichen von Anmeldedaten in veralteten Joomlas abzublocken (SQL-Injection). Ich finde diese Versuche die Lücken auszunutzen in allen Log-Dateien aller Joomlas, wo ich Zugriff habe.


    Scheint ja erst mal gut. Da du sie aber nicht eingesetzt hast, solltest du Provider und andere fragen, die ggf. Zugriff auf die Seite haben, ob die die Zeile eingesetzt haben. Um verlässlich zu blocken, sollte sie eigentlich zusätzlich in anderen Dateien ebenfalls gewesen sein.


    Theoretisch kann man sich auch eine "Schutzerweiterung" vorstellen, die man vielleicht installiert hat, die das gemacht hat. Kenne ich mich nicht aus, ob so was gibt.


    Wenn keiner es war, wurde deine Seite evtl. gehackt. Ich rätsele zwar noch, warum Hacker dann diese Zeilen einsetzen, kann mir aber auch da einen Grund von "echten Profis" vorstellen. Wurde sie gehackt, schützt dich das Update nicht mehr. Du solltest jedenfalls Joomla-Anmeldedaten neu anlegen und auch andere Nutzer dazu auffordern. NAchsehen, ob in der Benutzerübersicht weitere Unbekannte hinzugekommen sind und löschen. Nur ein erster Schritt...


    Dass du sie entdeckt hast, liegt wie gesagt an deiner PHP-Version. Bei anderer bleibt die Zeile verborgen und Seitenbetreiber bekommen nichts mit davon, dass da jemand manipuliert hat.


    EDIT: Und wie SniperSister sagt, ist die Zeile Gestümper. Bin noch nicht mal sicher, dass sie alleine funktioniert. Wäre jetzt noch ein Indiz mehr...


    EDIT2: Und natürlich einen Verzeichnisschutz für das Verzeichnis /administrator/ anlegen.

    Vielleicht: Die Menüzuweisung in den Modulen braucht NUR Häkchen im Schattenmenü, die Menü-Alais-Einträge anzuhaken tut zwar nicht weh ist aber unnütz. Oder Einstellung Auf allen Seiten.


    Selbiges gilt für Menüzuweisung im Templatestil, falls welche gemacht.


    Das neue Template bzw. den Stil als Standard-Stil gewählt? Im alten Menüzuweisungen entfernt, falls vorhanden?


    Und, wenn du im Template das Hauptmenü zuweist, gibt so Templates, wo man direkt im Template ein Menü auswählt, dann vielleicht zu blöd für Menü-Aliase?

    Kannst ja mal auf eine Seite schaun, die ich mit eingerichtet habe.


    ghsvs.de


    Klickst im Menü Schnipsel, das eine tote Menüberschrift "Schnipsel" enthält, z.B. auf "Joomla"


    Breadcrumbs zeigt "Schnipsel".


    Wie gemacht?


    Ein Schattenmenü eingerichtet (verstecktes Manü. Ohne Modul. Keine Anzeige im Frontend).
    Schnipsel (ein echter Menüeintrag)
    Darunter:
    -- Joomla (ein echter Menüeintrag)
    -- Sonstiges (ein echter Menüeintrag)
    -- Intern (ein echter Menüeintrag)


    Neues Topmenü angelegt (eigened Modul in Modulposition. Frontendanzeige).
    Teilbereich Schnipsel wie folgt


    "Schnipsel" = ein Systemlink vom Typ Menüüberschrift (tot)
    Darunter (2. Ebene)
    --- "Übersicht Kategorien" = ein Systemlink vom Typ Menü-Alias. Zeigt auf "Schnipsel" im Schattenmenü.
    --- "Joomla" = ein Systemlink vom Typ Menü-Alias. Zeigt auf "Joomla" im Schattenmenü.
    --- usw.


    Im Topmenü alle Aliase von Joomla vergeben lassen in der Art "2015-08-18-12-20-30", um doppelte Alias-Meldung zu vermeiden.


    Generelle Empfehlung für Joomla. Immer mit sauber strukt. Schattenmenü(s) anfangen. Macht vieles leichter.


    Zitat

    wenn ich auf mouseover einstelle


    Sowieso nicht mehr zeitgemäß. Mausgeführte Geräte verschwinden eh vom Markt wie... fällt mir grad nix ein... irgendwas sauschnelles.

    Das ist so, da Touchscreens kein MouseOver, kein Mit-Mauszeiger-Drüberfahren kennen.
    Beim ersten Tipp geht auf Mobilgeräten mit Touch erst das Untermenü auf,
    beim zweiten wird dann der Link betätigt.


    Ich mache es mittlerweile so, dass solche Menüeinträge mit Submenü keinen Link mehr unterlegt haben, sondern tatsächlich nur Menüüberschriften sind.
    Ich wäre ohnen deinen Hinweis gar nicht drauf gekommen, dass Einblicke ebenfalls eine Seite öffnet.

    Sammle zusammen, um welche Geräte, Betriebssysteme inklusive Versionen(!), Browser inklusive Versionen(!) es sich handelt. Kommst der Sache vielleicht einen Schritt näher. Wir hatten kürzlich mit vollkommen korrektem Formular bspw. ähnliches mit einem spezifischen IPhone-Typ. Leider nichts notiert. Es kamen Formulardaten einfach nicht im PHP und DB an und das Formular (Poll) gab Rückmeldung. Ich habe das dann über blöden Umweg via AJAX irgendwie hinbekommen.


    ----
    Den Benutzer speichert dieses EasySocial (kenn ich nicht)? Eigentlich sollte ja eine Mail erst rausgehen, wenn der Benutzer in der DB liegt. Das aber nur nebenbei.

    LESS verwendest du aber nicht versehentlich, oder?


    Hast du die betr. CSS-Datei nach kopieren mal verglichen?


    Ich habe auf 2 Seiten ausprobiert. Joomla 3.4.5 und aktuelle Entwicklerversion von Github.
    Protostar kopiert => protostar2
    protostar2: template.css geändert, Dateien in Unterordner hinzu und Kram. Frontend alle Änderungen zu sehen.
    Protostar2 kopiert => protostar3
    protostar3: Alle Änderungen übernommen.


    Nach 8 Kopien und Ändern kreuz und quer: Bei mir klappt alles wie erwartet.


    Einzige, was mir aufgefallen ist, weiß aber nicht, ob Einfluss. Das Standardtemplate hatte ein Häkchen bei Zugewiesen, obwohl ich alle Zuweisungen in anderen Stilen gelöscht hatte und es nie eine hatte. Musste ich 1x reingehen, den Toggle-Button 2x klicken, obwohl kein Häkchen drin, alle Häkchen weg prüfen und speichern. Dann erst waren alle Zugewiesen-Haken in Übersicht weg.

    OK, klang so.


    Wäre jetzt das wichtigste für mich zu wissen
    Du hast ausschließlich Änderungen in der Datei css/template.css gemacht?
    Dann probiere ich das mal aus.


    ------------------------
    Browser- und Joomla-Caches hast du gelöscht nach Umschalten des Stils?


    ------------------------
    Die Einstellungen im Template-Stil selbst werden bei Kopieren nicht übernommen. Sind ja nur ein paar im Protostar.


    Änderungen der Dateien, auch neue Dateien in den Unterordnern, sollten aber übernommen werden, falls du sie nicht in zusätzlichen, neuen Unterordnern angelegt hast. Also z.B. neben /css/ einen weiteren /meincss/.

    Hast du im ersten Template irgendwo Änderungen in Modulen gemacht in den Einstellungen Alternatives Layout und / oder Modulstil? Soweit die templatebezogen sind (sind ja so nach Template sortiert), packt das Joomla leider auch nicht und man muss alle diese Einstellungen ebenfalls neu machen mit neuem Template (nervt mich seit je her.)


    Oder in Menüeinträgen, wo man teils eine Einstellung Layout o.ä. findet? Selbes Spiel.

    Zitat

    Solange es dann nicht so abläuft...


    Da ließe ich es vermutlich drauf ankommen.



    Nachdem man bei
    einigen von Google angebotenen Diensten nicht abgemeldet wird, wenn man
    einen Browser schließt, der Cookies löscht und nach erneutem Öffnen
    immer noch unbewusst angemeldet ist (noch dazu ohne Häkchen
    "dauerhaft"), ist diese Entscheidung ein Eingriff in die Privatsphäre
    von Joomla-Nutzern oder -Dienstleistern, die auf fremden Seiten was zu
    tun haben.


    Liest man obigen Link (Google-Groups, wo sonst) aufmerksam, darf man feststellen, dass Befürworter noch weiter gehen würden

    Zitat

    We think a closer relation with Google is positive (Google Summer of code etc.)


    Letztlich
    geht es ja darum, dass ein managerartiger Klüngel hinter verschlossenen
    Türen diskutiert, der aber beleidigt und vehement bestreitet, ein
    solcher zu sein. Es wäre ein Leichtes "die Community" vorab über die
    anstehenden TOP so zu informieren, dass keine Zweifel aufkommen, ob
    etwas im Gespräch ist oder beschlossen. Muss eben verständlich und öffentlich bekannt gemacht werden.
    Und geht auch so, dass keine vertraulichen Daten öffentlich werden.
    "Wir überlegen(!) im BE Werbung einzubinden, um Kohle reinzubekommen, die wir für ... dringend brauchen."


    Den Satz habe ich mir gerade noch mal exakt übersetzen lassen:

    Zitat

    And
    to be clear, maybe you can define in that same topic who "the
    community" is exactly who should discuss the financial policy? Anyone
    interested in Joomla? Anyone on the forum? Anyone on twitter that might
    have on opinion about it?


    "Die Community" ist nur so lange "Community" = "wir alle", wenn es um Jubelmails, Nutzung und Zuarbeit geht. Als müsste er sich alle Posts zum Thema durchlesen. Könnte ihm doch egal sein. Öffentliche Diskussion ist einfach lästig...


    BTW: Keiner kann erwarten, dass Leute wie ich, mit mäßigem Englisch, sich durch den Google-Groups-Mail-Verhau quälen.


    Als sparsamer Mensch hinterfrage ich auch die eine oder andere Geld-Ausgabe im Projekt.

    Im Standard-Stil musst du keine Menüzuweisung machen. Nur in anderen Stilen, die für dort gewählte Menüpunkte verwendet werden sollen.


    Ob die anderen eine (unerwünschte) Menüzuweisung haben, siehst du am Häkchen in der Spalte Zugewiesen der Stileübersicht. Den Stil musst du dann öffnen und Menüzuweisungen entfernen.

    JEITA CP-3451C


    Nicht Standard sind für mich Daten, die von allgemeiner Spezifikation abweichende Tag-Ids / Tag-Namen verwenden, falsch verwenden (nicht zum Tag zugehörige Informationen), Informationen hinter proprietären Tagnamen ablegen (was durrchaus zulässig ist), aber nicht zusätzlich hinter Tagnamen / Tag-IDs nach Spezifikation hinterlegen. Tagwerte "falsch" formatieren oder mehr oder weniger private Daten in proprietären Tags ablegen, die am normalen Auslesecode bzw. "Vernichter-Codes" vorbeigehen.


    Jeder, der Daten aus komplexeren, z.B. wissenschaftlichen Fotosammlungen aus diversen Kameras diverser Jahre und diverser Hersteller verlässlich zusammenführen muss, hat seinen Auslese-Code dutzendfach zu überarbeiten.


    Aber vollkommen uninteressant für diesen Post irgendwie. Aber war ja eh schon OffTopic ;-)

    In solchen Fällen musst du dich an den Erweiterungs-Vertreiber wenden. Liegt, wie Meldung sagt, daran, dass sein Updateserver nicht erreichbar. Habe gegengeprüft mit aktuellem Plugin. Der dort eingetragene Updateserver ist tot.


    Hat zwar eine neue URL
    http://tech.reumer.net/update/…_googlemap3/extension.xml
    , aber trotzdem


    "403 Forbidden"


    EDIT: Wurde gerade informiert. Es gibt zusätzlich einen Bug in Joomla 3. Updateserver werden nicht aktualisiert, wenn Programmierer im Updatepaket einen neuen einträgt. ABER es wird ein neuer, zusätzlicher in DB angelegt, der dann stimmt. Der alte spuckt ggf. trotzdem obige Meldung, aber wird ja von Joomla deaktiviert. Leider kann man aus Backend Updateserver nicht löschen. Müsste der Pedant dann in DB machen (nicht ganz trivial).
    https://github.com/joomla/joomla-cms/issues/8113


    Dein Problem im Moment ist aber wie oben beschrieben (403).