Beiträge von F-rank

    Steht denn nun in der .htaccess etwas von "[COLOR=#ff0000]Go away, lamer![/COLOR]" drinnen?
    Also so etwas in der Art wie:

    Apache Configuration
    <Files wp-login.php>
      AuthName "Go away, lamer!"
      AuthType Basic
      AuthUserFile /pfad/zu/.htpasswd
      require valid-user
    </Files>


    Dann sollte eigtl. auch noch ein Rewrite der wp-login.php in der .htaccess stehen, der den GET-Parameter "[COLOR=#ff0000]redirect_to=index.php[/COLOR]" anhängt.
    Der Zeitstempel der .htaccess wäre in dem Fall interessant. Da wäre nach veränderten Dateien der Installation mit gleicher bzw. sehr nahe ähnlicher Zeit zu suchen.

    Steht aber nichts dgl. drinnen? Dann würde ich mich zuerst fragen, was dieses seltsame "Site unavailable"-Plugin, das ich auf wordpress.org nicht finden kann, denn für ein Ding ist?! Hast du das schon einmal deaktiviert und nochmal geguckt? Wo ist das her?

    Andernfalls sähe es tatsächlich nach vielleicht gehacktem WP aus, denn dann müsste ja die WP-Rewrite-Engine im Spiel sein und jmd. hätte also PHP-Befehle abgesetzt, die das, wie auch immer, bewirken. Ein fehlerhaftes oder zwielichtiges Plugin könnte die Lösung sein. Fehlerhaft geworden vielleicht nach dem letzten WP-Update??

    Schöne Grüße ...

    Dafür könnte nach meiner Meinung nicht einer von denen verantwortlich gemacht werden, welche die Grafiken einbanden

    Doch. Genau deswegen dürfen Social Iframes nicht ohne Datenschutzwarnung eingebunden werden. Hotlinking ist ja ein ganz anderes Denkmodell. Es geht hier nicht mehr darum, ob ich mich mit fremden Inhalten schmücke - das ist in diesem Falle gewollt und das Thema damit gegessen.

    Es geht jetzt vielmehr darum, ob ich mittels Hotlinking Nutzerdaten von gänzlich Unbeteiligten ohne deren Zustimmung und Wissen nach Übersee senden darf.

    Problem
    Ich sag's mal drastisch: wenn schon Lavabit mit 400.000 Benutzern schließen muss, um nicht rechtsbrüchig zu werden, wie steht es dann mit Begehrlichkeiten der NSA auf eine Blogplatform mit 70 Millionen Instanzen, die standardmäßig Avatare via gravatar.com hotlinken? Wenn 1+1=2 ist, dann hat die NSA nach FISA rechtmäßigen Direktzugriff auf gravatar.com-Logdateien.
    Lassen wir also einmal einen NSA-Mitarbeiter eine bestimmte E-Mail-Adresse in sein Terminal tippen, dann macht in einem Seiten-Thread ein kleines Progrämmchen:

    Code
    grep $(md5(E-MAIL-HASH)) LOGDATEIEN


    und spuckt als niedliche Tabelle alle URLs zu den Kommentaren aus, die die gesuchte E-Mail-Adresse in den letzten Jahren seit 2007 in potentiellen 60 bis 70 Millionen WordPress-Sites hinterlassen haben könnte.

    Das funktioniert unabhängig davon, ob du bei gravatar.com registriert bist!

    Denn, der Graukopf-Avatar (Kommentator ist also nicht auf gravatar.com registriert) ist ein Failure-Hotlink auf gravatar.com, der den Hash der E-Mail-Adresse dieses Nutzers enthält, welcher wiederum seine echte Adresse angab, weil er so gerne benachrichtigt werden wollte, falls jmd. auf seinen Kommentar antwortet... :(

    Ja, natürlich ist das nur ein Steinchen im Bauwerk der Datenschnüffelei. Aber ein wesentliches. Es geht schließlich um ganz persönliche Meinungen einer Zielperson, die diese vielleicht gewohnheitsmäßig überall hinterlässt. Allein daraus kannst du ein Gesinnungsprofil zu einer beliebigen E-Mailadresse erzeugen. Ach, und nicht vergessen: die IP-Adresse steht in den Logs überall mit dabei, womit weitere Querverbindungen verfolgbar werden. Die IP-Adresse gehört nach deutschem Recht zu den personerbezogenen Daten. Ich bin sicher: es ist nur eine Frage der Zeit, bis deutsche Datenschützer den Avatar-Haken in den Einstellungen für illegal erklären.

    Niemand kann doch von Automattic erwarten, dass die nun gravatar.com zumachen, so wie Lavabit. Soviel Charakter haben auf der ganzen Welt wohl nur ganz wenige Nasenträger, obwohl von denen die Zeitungen derzeit voll sind. Aber aus dem Blickwinkel des (nicht nur) deutschen Blognutzers ist das ein nicht bewiesener, aber möglicher und darum wahrscheinlicher Datenschutz-Gau der Gesinnungsschnüffelei.
    "Globally Recognized Avatar" ist nun einmal "Globally Recognized" :grin:

    Lösung
    Die Lösung heißt natürlich: lokale Avatare. Es gibt Plugins dafür. Die unterbinden zwar normalerweise gravatar.com-Abrufe im Backend nicht. - Doch da wird schon das nächste Datenschutz-Plugin am Horizont erkennbar - und dafür können wir WordPress wieder lieben.

    Ja, das könnte bequemer sein, ist es aber nicht, dafür ist es gefährlicher. So einen Datenbank-Eingriff zu machen, wie dieses Plugin es tut, ohne zu warnen, dass man vorher jedenfalls ein Backup machen müsse, ist echt fahrlässig und kann nun wirklich böse enden.

    Wenn du aber wiederum ein Backup machst, dann hast du ja ohnehin den Datenbank-Dump zur Hand und kannst sicher die oben beschriebene Methode in Sekunden auf einer Kopie des Dumps ausführen. Dazu ist die Methode absolut geeignet, den Austausch der Domainnamen in wirklich jedem Winkel der Datenbank zu erledigen. Suchen und Ersetzen auf einem Dump ist absolut resistent gegen API-Änderungen im Core, vernachlässigte Plugin-Pflege und PHP-Programmierfehler :-)

    Und den Aufwand:

    • Plugin installieren,
    • Paypal-Button und Firmen-Werbelink bewundern,
    • Gott vertrauen und die Plugin-Logik auf die ungesicherte Datenbank loslassen (mir daneben selber aus dem Englischen dolmetschen),
    • Plugin wieder deinstallieren (macht das überhaupt jemand? - eine Laie weiß nicht einmal, dass das Plugin nach dem Eingriff überflüssig ist und natürlich wieder deinstalliert gehört, und das Plugin sagt dir das nicht) -


    würde ich mir, ganz ehrlich, echt sparen.

    Nachhaltiger, insbesondere schneller und verlässlicher, finde ich insofern die von mir beworbene Methode :-D

    Tu dir einen Gefallen und nimm ein bestehendes WordPress-Design, sprich: Theme, und passe es an deine Vorstellungen an. Vorteil ist, dass du die Lernkurve wesentlich niedriger hältst und schneller zu einem Erfolg kommst. Nimm z.B. das Theme Responsive. Es ist bei der Darstellung auch für Tablets und Smartphones optimiert (an diese Geräte solltest du denken) und mit reinem CSS, anderen Farben, anderem Hintergrund, also etwas Backend-Klicken und CSS-Voodoo, kommst du zu bestimmt ansehnlichen Ergebnissen. Dasselbe gilt für das vorinstallierte TwentyTwelve und auch andere freie responsive Themes. Auf YouTube findest du sicher bei Bedarf auch noch ein paar Tutorials zu diesen Dingerchen.

    Beispiel-Sites mit dem Responsive-Theme: http://cyberchimps.com/showcase/

    Vorteil: du sparst irre Zeit. Du musst kein HTML anfassen - so simpel sind WP-Themes auch wieder nicht. Du hast z. B. die Blog- und Kommentarfunktionen schon vor-designed. Was da im Endeffekt hinten noch so dranhängt, zahlst du mit viel Zeit. Das genannte Theme kostet nichts und es ist recht sauber programmiert, so dass du dabei auch dazulernen kannst.

    Deine Freundin wird dankbar sein, wenn es dann auch am Handy funktioniert, glaub' mir.

    P.S.: Mach ein WordPress-Update, immer wichtig.

    Sorry - hatte zu tun ...

    Zum Ausgangsproblem, das, glaube ich, darin besteht, dass die Kaufen-Knöpfe in einer Reihe stehen sollen. Das ist nur zu erreichen, indem du die Lücken, die durch unterschiedlich hohe Bilder, ein- oder zweizeilige Überschriften usw. entstehen, in Kauf nimmst. Fällt aber nicht so auf und das kannst du ja bei der Dateneingabe steuern:

    An das Ende der style.css bzw. via sonstiger Woo-CSS-Location:

    Hoffe, das hilft ...

    Wie sieht denn das Original-Theme aus? (Link??) - Ich meine, da scheint ziemlich viel angepasst worden zu sein, was tlw. auch noch nicht richtig funktioniert: z.B. bleiben die Spalten 16% breit auf dem 320px breiten Alt-iPhone - und das ist ja so nicht gedacht.

    Also bei Anpassungen im Responsive Design muss sehr viel Vorsicht walten, wenn am Ende nicht alles kopfstehen soll.

    Bevor da also am beschriebenen Problem im Detail geschraubt wird, sollte das Responsive Design tun, wozu es da ist: in den Devices einmal zumindest sich an die Breite anpassen. Deswegen meine Frage nach einem Link vielleicht auf's Original. Zuerst muss das Design funktionieren, dann, mit viel Vorsicht, die Details angehen.

    Grüße!

    Deine Datenbank hat wenig mit den angezeigten Werten zu tun. Da geht es um den Arbeitsspeicher, der pro PHP-Skriptaufruf genutzt wird bzw. dessen Maximalwert pro Skriptaufruf (festgelegt vom Hoster; bzw. in der "php.ini"). Zwar können Datenbankdaten über PHP-Aktionen auch dazu beitragen, dass Memory verbraucht wird, aber da gibt es keine direkte Beziehung zur Datenbankgröße.

    Je mehr Plugins du aktivierst, desto höher der Speicherverbrauch, weil alle Plugin-Skripte bei jedem Seitenaufruf in den PHP-Speicher geladen werden; wie weit du da noch gehen darfst - das ist die hilfreiche Aussage dieses Plugins.

    Das Plugin hat also den Sinn, bei fröhlich multiplen Plugin-Installationen möglichst noch zu warnen, bevor der WOD ("White Screen of Death") zu sehen ist. Denn wenn ein Skriptaufruf mehr Speicher konsumieren will, als dir maximal zugestanden wird, siehst du weiß, d.h. alle Farben gleichzeitig, und stehst trotzdem im Dunkeln :-)

    Grüße

    Ich hab' schlechte Erfahrungen mit Child-Themes. Mit dem Update von Parent-Themes wird natürlich überschrieben und dann gibt's meist Ärger,, weil Neues dabei ist, womit das Child nicht zurecht kommt, oder weil etwas so nicht gedacht war - ist halt meine Erfahrung. Andere mögen andere Erfahrungen haben.

    Zudem kommt ein so nützliches Plugin wie Anitvirus von Sergej Müller nicht mit Parent-Themes zurecht (Parent-Templates werden beim Scan bis dato nicht beachtet).

    Entweder also ich ändere und update das Theme nicht, oder ich benenne es komplett um (inkl. Anpassungen in den Theme-Dateien) - dann wird es ja auch nicht mehr geupdatet.

    Allerdings beobachte ich die Änderungen schon, um eventuelle Sicherheitsupdates nicht zu verpassen. Mit einem Diff-Betrachter ist so etwas kein Problem.

    Gruß,
    Frank

    Das manövriert dir die Nav-Leiste nach oben:

    Code
    #access { position: absolute; top: 0; }


    Streiche das, und sie sitzt unten.

    Der entstehende weiße Balken oben, der danach entsteht, ist hierdurch verursacht:

    Code
    #branding { padding-top: 43px; }


    Grüße,
    Frank

    Eine Möglichkeit:

    Lade einen kompletten Datenbank-Dump herunter, z.B. mit dem phpMyAdmin.

    Öffne dann lokal die Datei *.sql mit einem Nur-Text-Editor und rufe die Editor-Funktion Suchen & Ersetzen auf. Suche nach alt-domain.de und ersetze durch neu-domain.com. Ersetze auf diese Weise alle Strings.

    Nun die Datei als Kopie des Original-Dumps (damit du noch das Original als Backup hast)!! abspeichern. Den veränderten Dump per Datenbank-Import einspielen.

    Damit sollte ohne sonstige Änderungen alles unter dem neuen Domainnamen laufen.

    Gruß,
    Frank

    P.S.: Dieses Vorgehen ist für stabile Nerven gedacht, falls da doch etwas schiefgeht. Du musst jedenfalls ein funktionsfähiges (getestetes!) Backup in der Rückhand haben.

    Bevor du die Plugin-Seite im Browser aufrufst:

    Verbinde dich per FTP mit deinem Webspace und benenne alle Ordner im Verzeichnis wp-content/plugins um, indem du jeweils einen Unterstrich _ davor setzt.

    Jetzt die Plugin-Seite im Browser aufrufen ...
    Es sollten damit alle Plugins deaktiviert worden sein.

    Nun wieder per FTP alle Ordner mit dem Original-Pluginnamen benennen (also Unterstrich wieder weg) und die Plugin-Seite im Browser neu laden.

    Ist der Fehler weg? - Falls ja, dann nacheinander immer nur ein Plugin aktivieren und sofort danach testen, ob noch alles funktioniert (Dashboard-Anzeige etc.).

    Das Plugin, das da evtl. für dieses seltsame Verhalten sorgt, könnte so zu finden sein.

    Gruß,
    Frank

    Nein, es handelt sich de facto um ein 150x150px-großes Bild in deinem Link. Andere Bilder sind sogar nur 75x100px groß und werden hochskaliert. Wenn ich unter diesem Link auf das Bild klicke, wird es übrigens in seiner echten Größe angezeigt - da siehst du dann, wie groß die Dingerchen eigentlich sind. Wenn die aufgeblasen werden, dann sind sie natürlich unscharf.

    Ich glaube, da stimmt etwas mit dem Bilderdepot nicht. Es sieht so aus, als würde WooCommerce die Standard-Thumbnails von WordPress als Originale behandeln.

    Leider kann ich nicht mehr dazu sagen, dazu müsste man doch sehr in das WooDo einsteigen, um dem auf den Grund zu gehen. Ging es denn schon einmal besser? Was hast du inzwischen geändert oder anders gemacht?

    Es hängt davon ab, wie du deine Spielberichte realisierst. Sind es z.B. normale Artikel (sorry: "Beiträge"), die einer Kategorie "Spielbericht" zugeordnet sind?
    Dann könntest du via "Design" => "Menüs" ein individuelles Menü erstellen und links mit Klick auf den Akkordeon-Tab "Kategorien" die Spielberichte-Kategorie als Menüpunkt hinzufügen (neben all den anderen, die dann auch manuell hinzugefügt werden müssen).

    Grüße