... 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
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen... 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
... Normalerweise muss ein Cookie gesetzt werden - bei Erstbesuch wird der Hinweis angezeigt. Für die Gültigkeitsdauer des Cookies dann nicht mehr. ...
Echt, Du willst da ein Cookie setzen, wo das doch so leicht zu manipulieren ist? Warum keine Post-Variable, z.B. isset($_POST['ib18'])?
http://forum.wpde.org/plugins-und-wi…html#post504205
Sorry, das konnte ich mir jetzt nicht verkneifen. ![]()
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
Mit welcher Absender-Adresse wird denn die Testmail verschickt?
Es könnte sein, daß der SMTP-Server Deines Webhosters die E-Mail-Adressen der anderen (echten) Nutzer/Leser nicht als Absender-Adresse akzeptiert.
Gruß
Ingo
Könnte auch am nicht/nicht richtig installierten Flash-Player liegen. Ich habe auf dem Rechner, wo ich es getestet habe, kein Flash installiert. Im Chrome geht es dann deshalb, weil dort Flash im Browser integriert ist.
Gruß
Ingo
Im Firefox habe ich den Fehler auch, ist ein normaler Desktop-PC mot Windows 7.
Auf dem selben Rechner funktioniert es im Chrome einwandfrei.
Könnte als ein Firefox-Problem sein.
Gruß
Ingo
Könnte auch ein Plugin sein, welches eine unerwartete Ausgabe erzeugt. Hast Du in letzter Zeit Plugins installiert?
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
Kannst Du bitte mal genauer beschreiben, wie Du beim Umzug vorgegangen bist.
Und was meinst Du mit Subdomains bei Strato?
Kannst Du bitte mal die Domains/Subdomains nennen?
Gruß
Ingo
Moment, Du bist von wordpress.com zu Strato umgezogen, also meineseite.wordpress.com zu meineseite.strato.de oder von wo nach wo?
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
Vielleicht ist das Bild mit 3507 x 2480 Bildpunkten einfach zu groß, so daß Facebook es nicht verwendet. Bei den erkannten Meta-Tags wird "og:image" zumidenst vom Debugger aufgelistet.
Bei Google+ wird das Bild übrigens zur Auswahl angeboten.
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ß!
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