Beiträge von Putzlowitsch

    ... Das Jacket (Muster) eignet sich nicht für eine Skalierung und wird in kleiner Größe nie besonders gut aussehen ...

    Also ich finde, das was da der Firefox und Chrome bei der Verkleinerung draus machen, sieht nicht schlecht aus.

    Gruß
    Ingo

    Wie gesagt, entweder Du verwendest eine von Wordpress erzeugte, verkleinert Version (Thumbnail) oder Du verkleinerst das Bild mit einem Bildbearbeitungs-Programm auf die gewünschte Größe (150x208) und lädst dann dieses Bild hoch und verwendest es.

    Gruß
    Ingo

    Der Zebra-Effekt ist bei mir im Firefox und Chrome nicht zu sehen. Verwendest Du als Browser den MS-IE?

    Dieser sogenannte Moiré-Effekt entsteht durch das feine Muster der Jacke beim Verkleinern des Bildes. Der IE scheint da ein einfaches Verfahren (Weglassen von Pixlen) zu verwenden, wodurch der Effekt zu sehen ist.

    Einfache Lösung: Das Bild auf die vorgesehen Ausgabegröße in einem Bildbearbeitungs-Programm verkleinern und dann in dieser Größe hochladen und einbinden.
    Das wirkt sich auch positiv auch die Ladezeit der Seite aus.

    Eigentlich sollte die WP-Mediathek auch ganz brauchbare Verkleinerungen erzeugen, falls Du das Bild darüber hochgeladen hast. Dann kannst Du auch dieses Thumbnail verwenden.

    Bilder sollten generell nicht in ihrer Originalgröße eingebunden und dann per HTML oder CSS verkleinert werden.

    Gruß
    Ingo

    ...
    Kannst ja Dein PrePage-Plugin mal wieder zur Verfügung stellen... :roll: ...

    Keine schlechte Idee, nur müßte ich dann mein Plugin noch umschreiben, denn es ist ursprünglich nur als Vorschaltseite für eine bestimmte Zahl von Seiten gedacht, aber nicht die komplette Website.

    Aber wie ich gerade sehe, hast Du ja schon etwas gefunden.

    Gruß
    Ingo

    Ich habe die Funktionen jetzt nur überflogen. Nachdem was ich gesehen habe, ist das eher ein Ersatz für die Wordpress-XML-RPC-Schnittstelle.

    Um mit Plugins die Funktionalität von Wordpress zu erweitern oder zu verändern, wird man immer noch die klassischen API-Funktionen benötigen. Oder habe ich etwas übersehen?

    Gruß
    Ingo

    Weiterleitungen, ob nun Proxy oder Frame oder was auch immer, sind oft keine vernünftige Lösung.

    Optimal wäre das richtige Aufschalten der Domain auf den Webserver, wo die WP-Installation liegt. Bei Strato kann man dafür den NS-Record oder den A-Record im DNS-Menü verwenden. Das setzt aber voraus, daß der Webhoster mit der WP-Installation auch die möglichkeit bietet, externe Domains aufzuschalten.

    Gruß
    Ingo

    Das nutzt sehr viel, wenn der Besitzer ein anderer ist (insbesondere ein Dienst oder Service)...

    Wenn der Prozess, der schreiben will (Apache/PHP), nicht der Besitzer ist, reicht 644 vollkommen aus. Er kann nicht schreiben. Ist der Prozess aber der Besitzer der Datei, hilft auch ein Entziehen der Schreibrechte für den Besitzer (444) nicht, weil er sich ja die Schreibrechte selbst wieder erteilen kann.

    In Bezug auf die Sicherheit in WP bringt 444 keinerlei Mehrwert. Das ist auch das Problem, wenn PHP als CGI/FastCGI im Kontext des FTP-Benutzers läuft. Da hat jeder böse Code, der durch eine WP-Sicherheitslücke reinkommt, immer schreibenden Zugriff auf alle Dateien.

    Allerdings hat man da (z.B. bei 1&1 und Strtao) auch in der Regel nie Probleme mit WP-/Plugin- oder Themeupdates, weil diese einfach so funktionieren, ohne Eingabe von FTP-Daten oder sonstigen Klimmzügen. :)

    Gruß
    Ingo

    ...
    Ist unterteilt in Besitzer (kann meistens alles), Gruppe (nur lesen), Alle (nur lesen). In dem Du die Schreibberechtigung auf eine .htaccess entfernst, kann auch der Webserver diese Datei nicht mehr beschreiben. Oder Du änderst den Besitzer der Datei auf den FTP-Benutzer. Wenn die Datei dann trotzdem noch beschrieben werden kann, entziehe dem Besitzer das Schreibrecht. ...

    Wenn die Dateirechte auf 644 stehen, nützt das Entziehen der Schreibrechte (444) recht wenig, denn der Besitzer kann sich das Schreibrechte selbst natürlich wieder erteilen.

    Gruß
    Ingo

    Die meisten Ressourcen (Bilder, CSS, JavaScript) zeigen auf die Hauptdomain und nicht auf die Subdomain.

    Da wirst Du noch Änderungen nach Punkt 3, wie oben von SirEctor verlinkt, durchführen müssen. Besonders auch das Umbennen der Bildpfade ist wichtig (letzter Absatz in dem FAQ-Artikel).

    Gruß
    Ingo

    Das mit der Bildgröße war jetzt nur eine Vermutung, wenn es bei der Testseite geht, wird es daran nicht liegen.

    Ich habe mal das große Bild direkt beim Facebook-Debugger eingegeben. Da erhalte ich nur eine Fehlermeldung und wenn ich mir unten die Daten anzeigen lassen will (Scraped URL), kommt nur ein "Document returned no data".
    Bei dem Bild der Testdomain wird aber das Bild angezeigt.

    Könnte am WP Super Cache liegen, damit kenne ich mich aber nicht aus.

    Gruß
    Ingo

    Wenn ein Querystring an einer URL dran klebt, ist die Request-Methode offensichtlich. So schlau ist der Apache....


    Eben, wenn an der URL Parameter dranhängen, ist es ein GET-Request. Mit dem 405 sagst Du dem Aufrufenden, daß die Methode GET nicht erlaubt ist, und welche ist es dann?

    Ein schönes Beispiel, wie der 405 richtig verwendet, ist z.B. die xmlrpc.php in Wordpress. Die gibt den 405 aus, wenn sie einfach so in der Browserzeile (mit GET) aufgerufen, mit dem Hinweis, daß nur POST-Requests erlaubt sind.

    Für das konkrete Problem ist der 404 vollkommen ausreichend und passender, würde ich sagen.

    ... Zudem nicht gelesen und somit auch nicht verstanden: Request_URI ...


    Danke für den Hinweis, das Modul kenne ich und verwende es auch.

    ... Keine vernünftige Lösung ist es, für jeden Mist in WordPress ein Plugin zu installieren. Da wünsche ich auch viel Spaß! :D


    Wenn es sowieso nur Mist ist, kann man es ja ganz weglassen.
    Aber ich gebe Dir recht, so eine einfache Parameter-Prüfung gehört nicht in ein Plugin, sondern eigentlich in den WP-Core.

    Gruß
    Ingo