Beiträge von Re:Later

    Du musst schon etwas detaillierter beschreiben.
    Wo willst du Bilder hochladen? Im Editor (welcher), im Medienmanager (welcher)...?
    Wo liegt die Seite? Ist die lokal auf deinem Rechner installiert oder ist die online? Bei welchem Provider?
    Jedes Joomla hat eine Datenbank, meist MySQL, und PHPMyAdmin wird im Normalfall vom Provider mit angeboten. Wenn nicht, kann man es auch nachinstallieren.

    Schon mal Danke an beide.
    Phoca: Übersetzer-Plugin wollte ich eigentlich nicht verwenden aus Performance-Gründen.
    Nübel-Plugin: Auch eine Idee, je nach Situation, Template switchen.
    Werd ich beides mal ansehen, ob ich was abkupfern kann.


    Bei dem was ich suche, ging es tatsächlich nur um eine CSS-Datei (vielleicht auch mehrere, oder LESS), die unter Bootstrap 3 auch mit Bootstrap-2-Klassen umgehen kann. Also z.B., ich verwende aktuelles Joomla, das ja sein Zeugs mit BS-2-Klassen "ausliefert", lade aber mit meinem eigenen Template das Bootstrap-3-Framework, das ja andere CSS-Klassen verwendet. Trotzdem muss man nicht alles per Overrides umschreiben, weil man die schlaue CSS-Datei dazwischen hat, die einem vieles abnimmt und "übersetzt".


    Muss ich mir wohl noch mal alle Joomla Days Videos ansehen ;) Glaub da war das irgendwo kurz eingeblendet.


    Oder halt dann doch selber schreiben...

    Ich habe kürzlich aufgeschnappt (Video?, Tutorial?, Bericht zu Joomla Days?), es gäbe einen Versuch/Ansatz/Projekt, mittels einer CSS-Datei, die man irgendwo runterladen kann, Bootstrap-2-HTML unter Bootstrap-3 zu verwenden. Wenigstens so ansatzweise. Ich wollte mir das mal ansehen, auch, wenn klar ist, dass das nicht so optimal funktioniert... Hatte den Link irgendwann mal kurz geöffnet. Geben tuts das also. Per Suchmaschine finde ich nicht.


    Wenn jemand weiß,... Danke!

    Sag dem Entwickler: Da hat Strato nichts mit zu tun, soweit du den Fehler beschreibst, da es sich um ein JavaScript-Problem handelt, somit clientseitig, nicht serverseitig auftritt. Es gibt diverse Hinweise zu ähnlichen Fehlermeldungen, wie man Uncaught TypeError: Cannot read property 'blahBlubbDingens' of null ("Ich kann mit Eigenschaft, die als NULL definiert wurde, nix anfangen. Good bye!") in JavaScripten behebt.
    1.5 ist echt langweilig, nebenbei ;)

    sondern als schnelle Maßnahme um die Seite schnell etwas sicherer zu machen


    Und deshalb habe ich den Begriff Schlangenöl gezogen. Die Seite wird nicht sicherer.

    Denn die Updategeschichte wird etwas mehr Zeit beanspruchen.


    Aber die von mir genannten Zwischenschritte nicht, weil ihr in der 2.5er-Linie bleibt, Template und Erweiterungen weiterlaufen können und ihr tatsächlich ein sicheres Joomla habt, wenn Ihr keine Pfeife machen lasst, auch Update-Scharlatan genannt ;-).

    Das kannst du schon mit dem zu Joomla beigepackten Protostar-Template.
    Für linkes und rechtes Menü nutzt du halt ausschließlich die Modulpositionen links und rechts. Andere verwendest du halt einfach nicht. Damit bleiben sie leer.
    Falls du bei der Installation Demodaten lädst, musst halt erst mal störende Module einfach deaktiviern, wie Top-Menü, Suchfeld etc.
    Damit ganze Seitenbreite genutzt wird, stellst du im Template FLUID ein statt STATIC (glaub so heißt das).


    Den Mittelbereich, bspw. Startseite besteht aus mehreren Beiträgen untereinander meist wird Menüeintrag vom Typ Hauptbeiträge genutzt, aber kein Muss. Du stellst im Menü eintrag das Feld # Führende auf beliebige Zahl. Damit werden alle Blöscke volle Breite angezeigt. Alle weiteren Einstellungen setzt du auf 0 (=keine), z.B. #Einleitende.
    Selbiges kannst du mit Bloglayouts machen, wo halt in einem einzelnen Menüeintrag Beiträge einer speziellen Kategorie angezeigt werden.
    Der Menüeintrag Einzelner Beitrag ist eh immer Mittelbereich füllend
    Wie immer muss man natürlich etwas CSS nachschnitzen, wenn du jetzt exakt dein jetziges Aussehen haben möchtest. Dafür gibt es dann ja Foren, wenn du mal Grundgerüst eingerichtet hast.

    Zitat

    es müsste doch die Kattegorie mit im Link sein-


    ICh hab mit dem Modul bisschen rumprobiert und schaffe es nicht ohne Kategorie.
    Was mich auch wundert, ist, dass bei dir die Artikel-Slugs unaufgelöst sind also mit Doppelpunkt statt Bindestrich.
    Eigentlich sollte das diese Zeile in der helper.php abfangen(?)

    Code
    $item->link = JRoute::_(ContentHelperRoute::getArticleRoute($item->slug, $item->catid, $item->language));


    ((Glaube nebenbei, dass es konsequenterweise $item->catslug statt $item->catid sein sollte. Egal. Joomla kommt wohl mit beidem klar.))


    Bist du sicher, dass dein Modul-Override oder Alternatives Layout mit dem im helper erzeugten $item->link arbeitet und nicht vielleicht mit $item->slug o.ä.?



    Und kleine Fundsache. In den BODY-Tags ist eine Fehlermeldung drinnen:

    Code
    <body class="site <br />
    <b>Notice</b>:  Undefined variable: option in <b>/.../webseiten/cbf-muenchen-2015/templates/cbf2015/index.php</b> on line <b>44</b><br />
     itemid-215 ">

    und wieder verworfen weil ich keinen Nutzen gesehen habe. Aber das ist noch keine fundierte Erklärung.


    Na ja, letztlich doch, wenn Benutzer ehrlich mit sich sind. Wenigstens ein richtiges Résumé.


    Betrachten wir diesen Thread. Eine Joomla-Seite wurde über Jahre unsicher gehalten. Der Scanner wird als Lösung betrachtet, aus dieser Bredouille rauszukommen (Tschuldige @nadjak !), was nicht mal ansatzweise möglich ist. Das ist purer Glaube betrachtet man sich die Innereien dieses Scanners. Noch dazu, weil AdminTools nicht aktuell ist (ProVersion), das dann vielleicht noch die eine oder andere aktuellere Heuristik bei hat (weiß nicht, ob Fachfrau so sagt ;) ((Muss grad lachen über die ersten beiden Absätze bei Wikipedia zu Heuristik => Treffer.))


    An den Stellen, wo wirklich Gefahr droht, kann der Normalsterbliche ohne tiefere Joomla-, PHP-Kenntnisse etc. nichts ausrichten, erkennt die Gefahr auch gar nicht, klickt sie weg, weil ja ansonsten viel mehr grün ist... Löscht mutmaßlich Gehacktes. Ignoriert tatsächlich Gehacktes... Und schaut nach 3 Wochen Engagement eh nicht mehr rein ;)


    Ich will dem Herrn Akeeba nicht zu nahe treten (auch, wenn ich sein FOF unnötig wie Kropf im Joomlacore finde ;) ).
    Es mag Professionelle und versierte Laien geben, die genau wissen, wobei AdminTools sie unterstützen kann, aber die Mehrzahl derer, die Fragen bzgl. AT an mich richten oder, die ich entnervt frage, ob das Ding denn wirklich sein muss (am besten noch in Kombination mit anderen Akeeba-Wächtern), weil es flüssiges Arbeiten teils extrem stört, haben nicht den geringsten Plan, was das Teil eigentlich soll und was sie da wo warum eigentlich eingestellt haben. (Und entweder die selbst oder ich schalten das Dingens schließlich aus).


    Außerdem habe ich nur eine Version 3.0.3/Joomla3 der Pro. Vielleicht ja mittlerweile alles viel besser geworden.


    Das sagen meine Notizen:


    5MB Installationsdateien schon für kostenlose Basisversion, die ja nun nicht viel macht.


    Notfallabschaltung:
    - htaccess mit allow:aktuelle(!) eigene IP wird geschrieben. Alte .htaccess gelöscht.
    - Rücksetzung nur per FTP-Zugriff und nur mit entsprechenden Kenntnissen wie man verlängert oder deaktiviert.
    - Oder durch "Löschen der .htaccess und neu erstellen" steht im Manual.
    - Wenn beim Provider in .htaccess spezielle Einstellungen nötig ggf. Serverfehler.
    - nahezu jeder Provider löst das eleganter.


    Admin-Passwortschutz:
    - Löscht ggf. bestehende /administrator/.htaccess undwiederbringlich anstatt Passwortschutz einfach nur zu ergänzen.
    - nahezu jeder Provider löst das eleganter.


    Berechtigungen schrauben:
    - Bestenfalls noch bei Exoten-Providern nötig.
    - Rücksetzen auf alte Werte nach Zerschuss nicht möglich (Restore). Lediglich Pauschalwerte für alle.
    - Oder anders: Man muss Usern nur pauschal erzählen, dass sie die Sicherheit der Seite erhöhen, wenn sie an Schreibrechten rumschrauben und sie glauben, dass ihre Seite sicherer ist, weil sie das getan haben, ohne, dass sie wüssten, was die 3 komischen Zahlen bedeuten. Spätestens beim Versuch das alles wieder zurückzusetzen, wenn etwas nicht funktioniert...


    Scanner:
    - Suggeriert, er sei etwas wie Virenscanner, arbeitet aber nicht mit Virensignaturen o.ä, lediglich paar Standards.
    - .htaccess-Datei und v.a. werden nicht geprüft.
    - Unbedarfter User wird mit Checkliste konfrontiert, die voraussetzt, dass User weiß, was er in Vergangenheit gemacht hat und was er als unbedenklich markieren kann.
    - Lokaler Komplett-Scan 400MB (das meiste aber Bilder, 6500 php-Dateien) läuft bei mir gerade seit Stunden. (War mein Fehler)
    - Scannt PHP-Files nach Endung (Kleinschrift). Lässt viel zu viel aus, was hochgeladenes PHP sein könnte und trotzdem ausführbar ist.
    - Extrem ressourcenfressend, wenn maximal genutzt. Hebelt schwächere Webseiten aus.


    Firewall:
    - Die Firewall, wenn hart eingestellt, müllt einen mit panikerzeugenden False Positives zu (und blockiert die auch), bis man sie so eingestellt hat, dass man sich eine Firewall sparen kann. Zusätzlich gehört eine Firewall VOR das System, das man schützen möchte. Binsenweisheit.
    - Die tut ihre Arbeit nicht alleine, jedenfalls nicht verlässlich. Braucht man also Hintergrundwissen...


    Zitat

    DISCLAIMER
    Sicherheitsbezogene Komponenten, wie diese hier, sind nicht dafür gedacht 100% Schutz gegen jegliche denkbaren Hackerangriffe zu leisten. Obwohl sie schon den Sicherheitsstandard Ihrer Seite anheben, ersetzen sie keines Falls ein gut funktionierendes Gehirn und weitere Sicherheitsfeineinstellungen für Ihre Seite. Schlussendlich sollten Sie immer eine Sicherung Ihrer Seite haben und ungewöhnliches Verhalten Ihrer Seite beobachten, auch wenn Sie diese Software verwenden.

    Daher sollte ich nur kurzfristig für etwas mehr Sicherheit sorgen und jemand anderes macht dann das Update.


    Unterstützung ist da kaum möglich in einem Forum.


    Das einzige, was es noch gibt, ist in der Joomla-Konfiguration Fehler berichten auf Maximum stellen und hoffen, dass irgendeine Meldung ausgegeben wird.


    Andere Möglichkeit, bei Akeeba Situation schildern und um Support bitten (was natürlich kosten wird, ohne, dass man wissen kann, ob es zum Ziel führt).


    Ganz ohne Unterton (ist einfach so):
    - Auch AdminTools laufen unter "Schlangenöl". Zusätzlich weist Akeeba darauf hin, dass (auch) diese Software davon ausgeht, dass man sein Joomla und Erweiterungen aktuell hält.


    Es läuft darauf hinaus, dass dein Auftraggeber Geld locker machen muss, wenigstens für diese Zwischenschritte
    - "händischer" Dateiabgleich und Kontrolle, ob sich Schadcode bereits in diesem Joomla befindet,
    - Update der PHP-Version auf mindestens PHP5.4,
    - Update des Joomlas auf 2.5.28, inklusive die Core-Hacks wieder zum Laufen zu bekommen bzw. eine Abschätzung bzw. auch gleich Umsetzung diese Core-Hacks in joomlakonforme, updatesichere Codes zu überführen.
    - Das vertraglich zugesichert.
    Ein erfahrener Joomlafachmann, der das entsprechende Werkzeug hat, sollte das kurzfristig und preislich akzeptabel hinbekommen.


    Das ist dann eine Basis, die ihr nahezu jedem anderen "Updater" übergeben könnt, wofür ihr euch dann etwas mehr Zeit lassen könnt.


    Jedenfalls solltest Du eine Kopie der Seite anlegen und dort deine weiteren Versuche unternehmen, wenn du selbst weitermachen willst.

    Zitat

    GATEWAY_INTERFACE CGI/1.1


    Das ist die Joomla-Angabe für PHP-Interface für den Webserver ?


    Was sind die Angaben im Joomla-Tabulator Schreibrechte (oder wie's heißt).


    Weiß nicht mehr, ob man bei Hosteurope FastCGI im Kundenzentrum aktivieren muss...

    Zitat

    [hier Einführungstexte von Beiträgen aus beiden Kategorien]


    Menü Inhalte > Beiträge > Optionen-Button oben rechts > Blog/Haupteinträge > Unterkategorien einbinden

    Der betrieb von Jomla mit in der Konfiguration aktiviertem FTP ist nur was für Ausnahmefälle.
    Also erst mal FTP in Joomla deaktivieren.


    Unter System > Systeminformationen sollte unter PHP-Interface für den Webserver sollte fastcgi, fcgi oder ähnlich stehen.


    Wenn nicht, beim Hoster erkundigen wie man dieses CGI/FastCgi bei ihm aktiviert.


    Host-Europe klappt das auf jeden Fall ohne FTP. Hatte ich schon oft genug mit zu tun.

    Zitat

    Cache-Dateien, die noch aktuell sind, werden nicht gelöscht!


    Eigentlich erklärt sich das doch von selbst. Wenn Cache aktiviert, wird auch eine Caching-Zeit/Cache-Dauer (lifetime) angegeben.


    Abgelaufener Cache ist der, der älter als die lifetime ist. Im Normalfall, also Dateien in den Ordnern /cache/ und /administrator/cache/, die da schon länger liegen als die Cache-Dauer.


    z.b. lifetime 2 Tage.
    Datei aber 3 Tage alt, also löschen.
    Datei erst 1 Tag alt, also nicht löschen.


    Beachten muss man, dass bspw. Plugins, die an Joomla-Cache-Einstellungen vorbei in obigen Ordnern Dateien ablegen, nicht berücksichtigt werden. Also für die "Cache leeren" verwenden.

    Die Komponente wäre nur geeignet, wenn deine Seiten mit index.php einen 404-Fehler ausgeben, Außerdem müsstest Du, falls sie doch gesammelt würden, für jede Seite eine Umleitung bearbeiten.
    Das Entfernen des index.php geht per htaccess weitaus bequemer, falls die URLs ansonsten gleich lauten.

    XAMPP Control Panel 3.2.1


    Das ist leider nur die Version des Control Panels. Wie lautet die Version des XAMPP selbst?
    Oder anders: Derzeit noch empfohlen, eine Version mit PHP5.4. Ich nehme bspw. XAMPP 1.8.1. Auch auf 64-Bit-Win7 solltest du die installieren können. http://www.oldapps.com/de/xampp.php?old_xampp=8288


    Stunden warten kannst du dir sparen. Dann läuft sicher was falsch. Vielleicht selten mal Minuten.


    Generell zwischen jedem Installationsversuch (auch online) den Browser-Cache zuvor löschen (Tastenkombination STRG+F5).


    localhost:8080/meinOrdner


    Vermutlich nicht Ursache, aber man weiß ja nie. Im Normalfall musst du Port nicht eingeben localhost/meinOrdner.


    Im Control Panel sind Apache und MySQL grün?