Beiträge von Autor33

    Windows: 14,0 KB (14.399 Byte)
    Firefox: 14.06 KB (14.399 Byte)
    Filezilla: 14.399 Bytes

    Das Bild scheint tatsächlich unverändert zu bleiben.

    Da selbst bei 100% durch den obigen Code in der functions die Datei neu gespeichert und geringfügig verändert wird, müsste sich eine WP-Aktion in jedem Fall in der Dateigröße auswirken. Der "optische" Unterschied zwischen 14 und 143999 beruht aber wohl nur darauf, dass 1 KB nicht exakt 1000, sondern 1024 Byte sind. Auf http://www.umrechnung.org/masseinheiten-…eicherplatz.htm entsprechen 14399 Byte exakt 14.06152 KB.

    Windows scheint dann die zweite Nachkomma-Stelle nur nicht anzuzeigen.

    Jemand anderer Meinung?

    Melewo:
    Wie kann ein falsches Farbprofil bei WP Folgen haben, wenn WP "gar nichts" macht mit dem Bild? Du meinst die zusätzlichen Größen?
    Ein Browser, der ungefragt einfach selbst komprimiert... Sachen gibt's. "Wer solche Freunde hat, braucht keine Feinde", fällt mir dazu ein. Solche Browser sind keine Unterstützung.

    Putzlowitsch:
    Es ist wirklich irreführend, weil beim Googeln in fast jedem Beitrag zur Deaktivierung der autom. Kompression einfach nur gesagt wird "WP komprimiert deine Bilder automatisch um 10%". Ich habe das immer auch aufs Originalbild bezogen. Plugin-Aktionen wüsste man sicherlich, aber warum sollte ein Theme ungefragt eingreifen und komprimieren?

    "Sollte" die 10%-Komprimierung nur für die zusätzlich beim Upload von WP erzeugten Bilder (andere Größen) erfolgen oder auch beim Originalbild selbst?
    Die meisten, die zu diesem Thema schreiben, differenzieren nicht, so dass der Eindruck entsteht, es geschehe für alle Bilder, auch das Originalbild selbst. Jetzt habe ich eine Quelle gefunden, die behauptet, nur bei den anderen Größen.

    Allerdings, wenn ich es ausprobiere, zeigt mir das hochgeladene Bild in Filezilla eine etwas andere Dateigröße als das Bild auf meinem PC hat. Ist nicht viel, 14 zu 14,4 KB, aber da meine Bilder schon ziemlich stark komprimiert sind, habe ich mir auch keine großen Unterschiede erwartet, zumal bei nur 10%.

    Sollte die automatische Kompr. nur für die zusätzlichen Bilder gelten?

    Da es sich um keinen Blog handelt, habe ich in den Lese-Settings eine statische Front Page gewählt.
    domain.de/index.php leitet um auf domain.de, ohne dass ich manuell einen redirect angelegt hätte in der htaccess.

    Technisch kommt WP offenbar nicht ohne /index.php aus. Es gibt aber keine für den Besucher relevante Seite mit dieser URL.

    Stimmt, sicher ist man nur mit dem Meta-Tag "noindex", z.B. wegen duplicate content. Hat außerdem den Vorteil, dass die betreff. Seiten Pagerank denoch weitergeben. Und wenn es um wichtige Sicherheitsfragen geht, sollte man (zusätzlich oder stattdessen) in vielen Fällen die .htaccess nutzen.

    Die Standard-Empfehlung von WP dürfte schon passen für mich, abgesehen von der Bildersache. Außergewöhnliche technische Features, z.B. per include, haben meine kleinen Sites nicht. Ganz normale Informations- und "Firmen"-Sites, später kommt mal ein Onsite-Blog als Subdomain dazu.

    Was mich etwas verwirrt, ist allerdings, dass viele Webmaster zusätzlich zu den von WP selbst empfohlenen Ausschlüssen noch weitere Verzeichnisse und Dateien ausschließen. Es fällt mir schwer zu beurteilen, ob ich das ebenfalls ergänzen soll zu den von WP
    gemachten zwölf Anweisungen. Viele ergänzen noch einiges von den folgenden Sachen:

    Disallow: xmlrpc.php
    Disallow: index.php
    Disallow: wp-register.php
    Disallow: /feed/
    Disallow: /author/
    Disallow: /archives/
    Diasllow: /20*

    Um das einschätzen zu können, fehlt mir der technische Background und selbst mit Google finde ich dazu nichts raus, ausgenommen die Sache mit der seit WP 3.5 stets aktivierten und für Angriffe anfälligen xmlrpc-Schnittstelle.

    Hallo,
    auf http://codex.wordpress.org/Search_Engine_…xt_Optimization
    empfiehlt WP folgenden Code in der robots.txt:

    Dass es das Ranking verbessert, wie WP dort behauptet, bezweifle ich stark, aber macht ihr das der Sicherheit und Vermeidung von duplicate content wegen?

    Angenommen, ich würde als einzige Ergänzung zur obigen Empfehlung jpg, png und gif im Ordner Uploads aussperren wollen, weil ich keine Bildersuche bei allen Sumas brauche, andere Medien (ebenfalls in "uploads") wie z.B. pdf aber gefunden werden sollen. Wäre dann die folgende Ergänzung ganz unten in der robots.txt richtig:
    Disallow: /*.jpg$
    Disallow: /*.png$
    Disallow: /*.gif$

    oder gleichwertig:
    Disallow: /uploads/*.jpg$
    Disallow: /uploads /*.png$
    Disallow: /uploads/*.gif$

    Mach ich, aber ich verstehe ehrlich gesagt nicht, was du damit meinst:
    "aber es bringt nichts, weil die Mediathek keine Ordnung per Kategorie am Webspace kann"

    Das nach Dateityp differenzierte Aussperren von Suma-Crawlern beeinflusst doch nur die Indexierung der Suma, nicht das Arbeiten mit den Bildern in der Mediathek?

    EINEN Nachteil hat es doch, zumindest für manche:
    Wenn man nicht in der Bildersuche der Sumas auftauchen will und den uploads-Ordner sperrt per robots.txt, dann sperrt man gleich alle anderen Medien mit. Mit seinen Videos und Audios, PDFs will man aber evtl. in den Sumas gefunden werden.

    Oder könnte man das disallow auf bestimmte Datei-Arten spezifizieren?

    SirEctor:
    Mal angenommen, es geht noch oder es gibt ein anderes Plugin. Dann wäre das eine Option. Die andere wäre der obige Code in der functions.php.

    Macht man das dann besser per Plugin oder functions.php oder ist das echt egal? Performance, Sicherheit, "trouble-Potential", Verwaltungsaufwand.. was ist besser, eine stetig steigende Anzahl an Plugins oder eine anwachsende functions.php?

    Ganz ohne eigenen Code in der functions.php wird es wohl nicht gehen bei mir, also das Aufpassen beim Theme-Update bleibt mir in jedem Fall und wäre zumindest bei mir kein Argument gegen die functions.php als Lösungsort für diverse Verbesserungen.

    spickzettel:
    Guter Hinweis, merci. Solche Veränderungen in WP sind der Grund, warum ich immer versuche, sowohl mit Plugins als auch functions-Codes so sparsam wie möglich zu sein.

    Danke für die Erklärung.

    Webspace ist nicht das Ding. Es würde einfach Zeit sparen, wenn man alle, bereits fertig bearbeiteten Bilder auf einen Schlag in WP bringen könnte. Außerdem möchte ich auf jeden Fall die automatische Komprimierung umgehen.

    Gibt übrigens ein Plugin für die Verbindung zur Mediathek nach FTP-Upload: http://www.tipps-archiv.de/wordpress-medi…der-upload.html

    Der von mir in post 3 gefundene Code für die functions.php ist ein anderer als der von dir gepostete. Kannst du oder jemand anderes beurteilen, ob da ein relevanter Unterschied besteht?

    Alles klar, verstehe ich. Das heißt in meinem Fall, dass der beim Reinkopieren des Codes fehlende Bild-Link kein Problem ist, da ich keine Anhangseite brauche: Ich will weder die Bilder auf Klick nochmal extra vergrößert darstellen noch brauche ich Thumbnails bzw. Gallerien. Das autom. Erzeugen verschiedener Größen beim Einfügen habe ich durch die Media-Settings deaktiviert.

    Ergo --> "Link zur: Keine" in den Anhangseinstellungen, statt "Medien-Datei". Am besten gleich nach dem Upload. Korrekt?

    Schade, dass man offenbar die Bilder nicht per FTP in die Mediathek bringt. Wird mir wohl nichts anderes übrig bleiben, als entweder ein Plugin zu besorgen oder meiner functions.php etwas Weiteres hinzuzufügen.

    Wordpress hat viele Vorteile, aber ich bin überrascht, was es alles automatisch macht ohne den Anwender darüber wenigsten zu informieren, besser noch, vorher zu fragen. Wahrscheinlich gibt es unzählige Webmaster, die z.B. nicht merken, dass automatisch weitere Bilder erzeugt und außerdem um genau 10% komprimiert werden. Automatische Anhangsseiten und deren Verlinkung ist nur ein weiteres Beispiel.

    Melewo:
    Am Anpassen der Bildpfade führt eh kein Weg vorbei. Ich habe zwar konsequent auf absolute Urls bislang gesetzt und die Domain bleibt unverändert, aber ich teste auf einer Subdomain und von dort wird dann die Site übertragen.

    Aber davon abgesehen habe ich bislang Bilder immer nur per <img src...> referenziert. Warum braucht WP ein zusätzliches <a> und muss ich das überall manuell ergänzen im Code?

    WP wandelt beim Reinkopieren meine <p> in unsichtbare Steuerzeichen um und erst nach "Ausgabe" sehe ich im Code wieder <p> und <br>, wenn ich das richtig verstehe. Was genau heißt "Ausgabe"?

    Clubs München:
    Hast du das mit p probiert? Bei mir sehe ich nix.

    Wegen Bilderreferenzierung, wie gesagt, ich kenne nur das dafür ausreichende img-tag mit src zur Pfadangabe.

    Ups, dachte das Hochladen per FTP in den uploads-Ordner wäre gleichbedeutend mit "in der Mediathek" sein.

    Dass die Verknüpfung bestimmter Bilder mit bestimmten Posts/pages danach erst noch erfolgen müsste, ist klar. Aber ich dachte, ich kann das dann ganz normal beim Schreiben machen, und finde die Bilder dann in der Mediathek vor.

    Das bedeutet im Umkehrschluss, dass nur über WP hochgeladene Bilder praktisch verwendbar sind für posts/pages und per FTP deshalb gar keinen Sinn macht?

    Hallo,
    bei dem Relaunch einer alten, einfachen, statischen Website mit textreichen Seiten (kein Blog) möchte ich nun WP als CMS verwenden. Das Design ändert sich, aber der zentrale Content nicht.

    Wenn ich nun eine solche Seite in WP anlege, würde ich gerne einfach den kompletten Code in den WP-Editor im Text-Modus reinkopieren. Die bisherigen Seiten haben <p>, <br>, <h>, <div>, <span>, <a>, <b>, <i>, <strong>, <q>, <blockquote>, <img> im Code.

    Zwei Unterschiede zu WP sind mir aufgefallen:
    1. Bilder bekommen in WP zusätzlich <a> zum <img>, warum das?
    2. WP kennt keine Absatz-tags <p>; faktisch existieren Absätze zwar, aber im Code ist nichts davon zu sehen, worauf sich das gründet?? Manuell eingefügtes <p> verschwindet ebenfalls wieder.

    Welche manuelle Nacharbeit im Code muss ich wie machen?

    Bei früherer Gelegenheit, genauer gesagt, beim Einfügen meines Profilbildes bei G+, ist mir schon mal aufgefallen, dass mein FF bei "Ansicht - Zoom - normal" alles vergrößert unscharf anzeigt. Zoome ich zwei Stufen kleiner, passt es, d.h., Bilder werden scharf in Originalgröße angezeigt.

    Die kleinere Einstellung merkt er sich dann aber offenbar nicht generell, sondern nur für die betreff. Seite --> neue Seite mit WP wieder unscharf vergrößert, aber laut Zoom-Einstellung "normal".

    Ist zwar eigentlich offtopic, aber wisst ihr, was mein FF (aktuelle Version, Win7) da "macht"?