Beiträge von Ammaletu

    In letzter Zeit wurde, soweit ich weiß, geändert, welche Nutzer beliebiges HTML posten dürfen. Für alle anderen wird das gefiltert, script und styles fliegen dabei raus. Postest Du das also als admin-Nutzer und wenn ja auf Multisite oder Einzelinstallation?

    Andererseits würde dieser Effekt ja immer auftreten, auch beim Ausbessern. Ich wüsste jetzt nicht, wieso WP ein Element mal ändern sollte und mal nicht.

    Für die Like-Buttons hat heise.de eine schöne Lösung programmiert, die datenschutz-technisch einwandfrei ist. Das Problem dabei war ja, soweit ich das verstanden habe, dass die Daten in ein Land geleitet werden, das keine adäquate Datenschutzgesetze hat (USA bei Facebook). Flattr ist eine schwedische Firma, deren Impressum nennt zudem einen Standort in London. Wenn die Daten also in der EU bleiben, würde ich denken, dass das kein Problem ist (und Nein, ich bin kein Anwalt oder sonstiger Rechtsexperte*g*). Außerdem geht doch eh keiner rum und mahnt Seitenbetreiber ab, die irgendwelche Buttons einbauen. Da wüsste man ja nicht, bei wem man anfangen sollte, so verbreitet ist das mittlerweile. ;)

    Du solltest erst einmal herausfinden, was das Problem ist. Wenn Du schreibst, die Bilder sind im Artikel noch da und werden aber nicht angezeigt: Woran liegt das dann? Stimmt die URL nicht mehr? Schreib uns ggf. mal die URL der Seite oder schick mir den Link per PM (eine Seite, wo man so ein kaputtes Bild im Quelltext sehen kann).

    Ich bin auf Arbeit und rufe die Seite jetzt sicher nicht auf, aber das sieht mir verdächtig aus. Wo die Mweldung herkommt, steht ja in der Meldung: Von einer polnischen Diät-Spam-Seite?! Das kommt entweder aus Werbung, die Du absichtlich im Blog geschaltet hast, oder jemand schleust das in die Seite ein. Und da Werbung selten auf Java basiert, würde ich auf letzteres tippen.

    Wenn es tatsächlich nach außen hin getrennte Seiten sind, würde ich MultiSite dafür bevorzugen. Dort kannst Du ja beiden Seiten das gleiche Theme geben, was gerade einer der Vorzüge von MS ist. Wenn es nur um zwei Bereiche der gleichen Webseite geht, dann ist eine Lösung mit dem klassischen WordPress und entsprechend gesetzten Rechten vielleicht besser.

    So, habe die beiden Zeichen jetzt mal in der Sprachdatei ersetzt und getestet. Das klappt an sich gut, viel kann dabei ja auch nicht schiefgehen. Die Entities werden, soweit ich das gesehen habe, sonst auch nur an einer Stelle ohne die _x()-Funktion verwendet, und das ist in theme-compat\comments.php, was deprecated und vermutlich zu vernachlässigen ist.

    Ein Problem gibt es allerdings: wptexturize ist buggy, so dass man am Ende vorerst doch nicht um InTypo herumkommt. Im Moment ersetzt wptexturize manchmal ein schließendes Anführungszeichen durch ein öffnendes (http://core.trac.wordpress.org/ticket/18549 bzw. http://core.trac.wordpress.org/ticket/17571 und eigentlich http://core.trac.wordpress.org/ticket/4539 -- wow, ein 5 Jahre alter Bug, jede Menge Code von Nutzern, aber niemand committed es mal...), außerdem sind die einfachen Anführungszeichen nicht in den Language Files enthalten. Das hätte im Moment den Effekt, dass man die ganzen Bugs relativ leicht sehen kann, da unser öffnendes Anführungszeichen ja unten steht, und dass der Kontrast zu den einfachen Anführungszeichen ebenfalls auffallen würde.

    Also warten bis #4539 geschlossen ist und dann einen Patch für die einfachen Anführungszeichen schreiben und dann erst in die Language Files eintragen?! Meine Güte, wieso muss das so kompliziert sein? Zu allem Überfluss enthält InTypo auch noch Bugs, die ich fixen musste. *grummel*

    Die Bilder werden in dem Menü angezeigt, solange noch Daten davon in der Datenbank stehen. Dass in dieser Ansicht keine Option zum Löschen vorhanden ist, ist etwas unpraktisch. Man löscht die Bilder wie alle anderen Uploads auch über die Mediathek-Ansicht im Backend. Dann verschwinden sie auch automatisch aus der Kopfzeilen-Ansicht.

    Wenn Du alle Seitenaufrufe zählen willst, pack das doch am besten in die footer.php, eben vor das schließende body-Tag. Wenn manche Seiten nicht gezählt werden sollen, kannst Du das mit Conditional Tags gut einschränken. Um z.B. nur Einzelseiten zu zählen:

    PHP
    if (is_single()) {
      echo "Extra-Code";
    }

    Dabei aufpassen, dass PHP in <?php ... ?> steht und HTML ggf. außerhalb davon. Am besten auch hinterher mal schauen, dass die Änderungen die Seite nicht irgendwie kaputt machen.

    Für das Frontend steht in den FAQ, wie man die index.php ins Root-Verzeichnis kopiert, so dass man dort die tieferen Verzeichnise nicht sieht. Aber das Backend wird natürlich trotzdem im Unterordner aufgerufen, da liegen nun mal die Dateien und die Backend-Ansichten werden ja nicht alle durch eine index.php durchgeschleift, sondern es wird immer die gewünschte Datei direkt aufgerufen. Du kannst jetzt natürlich alle Links zum Backend aus der Seite entfernen (Login-Link etwa), wenn nichts davon öffentlich sein soll (wenn man sich also nicht registrieren kann).

    Also, das Problem habe ich jetzt schon mal verstanden: Du hast einen Custom Post Type "Portfolio" angelegt und eine gleichnamige Seite "Portfolio". Normalerweise sind Portfolio-Beiträge unter der URL /portfolio/beitrag123 zu erreichen, die statische Portfolio-Seite ist unter /portfolio zu erreichen. Soweit, so schön.

    Wenn nun die Unterseiten von Portfolio ins Spiel kommen, kann WP wegen der Namensgleichheit nicht wissen, was gemeint ist (genau genommen ist der angezeigte Name egal, dass der Slug gleich ist stört). WP sucht also nach einem Posting vom Typ "Portfolio" mit dem Slug "print" anstatt nach der Unterseite "Print" zur Oberseite "Portfolio". Das wird nicht gefunden, also 404.

    Eine Lösung ist natürlich, die Slugs nicht gleich sein zu lassen. Wenn der Slug der Oberseite "mein-portfolio" wäre, hättest Du das Problem nicht. Aber ich nehme mal an, dass das Absicht ist. Ich suche jetzt gerade mal, ob man das noch irgendwie umgehen kann...

    Update: Für die Pagination auf der Portfolio-Seite ist das Problem ähnlich: WP sucht sicher nach einem Portfolio-Posting "page". Dafür gibt es ein Plugin, das hoffentlich weiterhilft: http://wordpress.org/extend/plugins/category-pagination-fix/

    Update 2: Falls der Pagination-Fix so noch nicht geht muss eventuell noch eine Kleinigkeit am Code des Portfolio-Seitentemplates geändert werden. Da wird $paged einfach so verwendet, was denke ich eigentlich noch als global eingelesen und/pder selbst befüllt werden müsste Schaue ich mir genauer an falls es relevant ist.

    Ansonsten habe ich zu dem Problem viele Threads gefunden (z.B. http://wordpress.org/support/topic/…ture-permalinks), aber keine wirklich verständliche Lösung. Irgendwie müsste man wohl an die Rewrite Rules ran, aber das kann ich mir jetzt nicht so nebenbei ausdenken, das wäre aufwändig. Ein anderer Workaround, der mir einfällt: Die Unterseiten einfach nicht als Unterseiten machen, sondern als normale Seiten mit einem Slug wie "portfolio-print". Im Menü kann man sie dann ja trotzdem wie jetzt arrangieren.

    Ich nutze seit langem das Plugin "InTypo", um deutsche Anführungszeichen ausgegeben zu bekommen. Auf der Suche nach einem Bug in diesem Plugin habe ich gerade mal in die Funktion wptexturize geschaut und mit Verwunderung festgestellt, dass zumindest die doppelten Anführungszeichen ja jetzt über die Sprachdatei eingestellt werden können -- es aber im Moment nicht werden.

    Im Code: wp-includes/formatting.php, Zeile 36. In der Sprachdatei ab Zeile 12674:

    Code
    #: wp-includes/formatting.php:36 wp-includes/formatting.php:2986
    msgctxt "opening curly quote"
    msgid "“"
    msgstr "“"
    
    
    #: wp-includes/formatting.php:38
    msgctxt "closing curly quote"
    msgid "”"
    msgstr "”"

    Gibt es einen Grund, wieso hier nicht die deutschen, typographischen Anführungszeichen gesetzt werden? Also 8222 für öffnendes und 8220 für schließendes Anführungszeichen. Es wäre toll, wenn das geändert werden könnte. :)

    Und dann fehlt im Core noch ein Patch, der das gleiche für die einfachen Anführungszeichen ergänzt. Keine Ahnung, wieso das da nicht gleich gemacht wurde. Der Code ist ein wenig unübersichtlich (RegExes), aber ich kann dieser Tage ja mal schauen, ob ich das eingebaut kriege. Oder hat jemand genauere Infos, wieso das überhaupt fehlt?

    Edit: Das Forum ersetzt die Entities durch die eigentlichen Zeichen, obwohl es als Code markiert ist. In der Datei stehen natürlich HTML-Entities.

    Das in die index.html einzubauen sollte kein Problem sein. Das Problem ist, wie merkst Du Dir, dass das Intro schon angezeigt wurde für einen bestimmten Besucher? Das Intro nur mit URL-Parameter anzeigen geht ja vermutlich nicht, da Du die externen Links auf die Seite nicht kontrollieren kannst. Das Intro nur mit Parameter nicht anzuzeigen geht auch nicht, da WP ja an allen möglichen Stellen auf die Startseite verlinkt und Du die Links sicher nicht alle um den Parameter ergänzen willst. Und es immer anzuzeigen wird sehr schnell ziemlich nerven.

    Vielleicht doch per JS anzeigen und sich dann per Cookie merken, dass es schon angezeigt wurde? Das dann nur für Anfragen, die Cookies unterstützen (Accepts-Header?!). So sehen es nur Nutzer mit JS und Cookies, alle anderen nicht. Es soll ja eh ein Extra sein, richtig, kein integraler Bestandteil der Seite?!

    Ich sehe gerade, dass die Code-Ansicht in meiner letzten Antwort das aus irgendeinem Grund alles auf eine Zeile gehauen hatte. Das geht natürlich nicht. Falls Du es so probiert hattest, dann bitte noch mal mit obigem, berichtigtem Code testen.

    Davon abgesehen: Soll das immer nur beim Aufruf der Startseite kommen oder auch, wenn man direkt auf eine Unterseite geht (z.B. per Google)? Falls es nur auf der Startseite kommen soll, würde ich überlegen, das in die index.php des Themes einzubauen. Das Problem ist da dann nur, eine Lösung zu finden, die auch für Leute funktioniert, die JavaScript oder Cookies abgeschaltet haben. Ansonsten wäre das relativ simpel, die Willkommensseite oder die Startseite anzuzeigen, abhängig von z.B. einem Cookiewert.

    Zitat

    Kann ich das theme mal zeigen oder ist das eher nicht gestattet?

    Siehst, weiß ich nicht mal, ob Links auf Kauf-Themes als Werbung gelten, die hier ja nicht rein soll. ;) Kannst mir den Link ja mal als Nachricht schicken. Ich kenne mich nun auch nicht so gut aus mit dem, was es an freien Themes so gibt, kann aber zumindest mal schauen, ob mir was entsprechendes einfällt.

    Davon abgesehen sind Kauf-Themes ja nicht schlecht. Man sollte halt nur wissen, ob sich die Investition lohnt. Hier kommen halt öfters Leute mit Fragen zu gekauften Themes an, bei denen sie für 100 Dollar oder so offenbar keinen Support dazu kriegen oder wegen mangelnder Englisch-Kenntnisse nicht nutzen können. Da kann man dann oft einfach nicht besonders weiterhelfen.


    Zitat

    Das sieht doch schon halbwegs nach dem aus, was Du haben möchtest. Falls Du eine eigene Lösung bastelst / basteln lässt, würde ich die an Deiner Stelle darauf aufbauen, denke ich.
    http://mapservices.org/myguestmap/

    Zitat

    durch Themawechsel bleiben Plugins aber aktiv, und Shortcode die Plugins ansteuern funktionieren dadurch natürlich auch weiterhin, den diese stehen im Content. und habe mit Designtemplates nichts zu tun.

    Das stimmt. Oben steht aber, dass es um einen Shortcode geht, den der Theme-Autor ins Theme eingebaut hat. Deswegen habe ich darauf hingewiesen.

    Ich wollte mal nach Meinungen zu dem nicht ganz neuen Thema Gravatar und Datenschutz fragen. Ich habe die Gravatare bisher auf meiner Seite nicht eingesetzt, finde sie aber sehr schick und würde das beim aktuellen Redesign gerne einbauen. Andererseits sind die Probleme schon nicht einfach wegzudiskutieren. Deswegen überlege ich nun, ob man da vielleicht mit einem Plugin etwas dran machen könnte, so á la der 2-Klick-Facebook-Like-Lösung von Heise (http://www.heise.de/extras/socialshareprivacy/).

    Mal kurz die Probleme mit den Gravataren aus meiner Sicht:

    1. Wenn Besucher 1 eine Seite mit einem Gravatar aufruft, wird Automatic seine IP übermittelt. Daraus lassen sich anonyme Surf-Profile bauen, wenn auch keine kompletten. Wenn Automattic die IP mit anderen Daten verknüpft ist das Surf-Profil ggf. auch nicht anonym.
    2. Wenn irgendjemand eine Seite aufruft, auf der Besucher 1 mit seinem Gravatar kommentiert hat, erfährt Automattic, auf welchen Seiten ein bestimmter Nutzer alles kommentiert hat. Für registrierte Nutzer ist das für Automattic nicht anonym, sie kriegen aber auch die Kommentar-Profile der nicht registrierten Kommentierer.
    3. Auch jeder andere kann einen Bot bauen, der im Netz nach Fundstellen für die Gravatar-URL sucht, und daraus ein Kommentar-Profil bauen. Je nachdem was man in den Kommentaren oder auf der Gravatar-Profilseite verrät ist das ggf. einer Person zuordenbar. Dem Kommentierenden ist das ggf. nicht bewusst, dass damit alle seine Kommentare mit dem gleichen Gravatar einander zugeordnet werden können.
    4. Der MD5-Hash der E-Mail-Adresse wird in der Gravatar-URL öffentlich gemacht, obwohl man ja im Kommentar-Formular versprochen hat, die E-Mail nicht zu veröffentlichen. Durch Ausprobieren, Wörterbuch-Attacken etc. kann man ggf. die E-Mail-Adresse ermitteln. Siehe: http://www.developer.it/post/gravatars…not-a-good-idea
    5. Wenn jemand einen Kommentar unter falschem Namen abgeben möchte (Identitätsklau), sieht das mit Gravatar daneben noch mal echter aus.


    Nummer 5 sehe ich nicht als echtes Problem an. Identitätsklau geht halt immer. Man kann sich ja eine schlecht erratbare Adresse zulegen, die man zum Kommentieren benutzt.


    Bei Nummer 4 bin ich mir nicht sicher. In den FAQ auf gravatar.com wird das Problem eher heruntergespielt, andererseits zeigt das verlinkte Beispiel, dass das in der Praxis ja durchaus geht.


    Schlimm an Nummer 2 bis 4 ist, dass es alle Kommentierenden betrifft, nicht nur die, die sich bei gravatar.com registriert haben. Um ein Identicon oder ähnliches Standard-Icon zu generieren, wird natürlich ebenso der MD5-Hash veröffentlicht im Bild-Link. Automattic vertraue ich eigentlich, mit den Daten keinen Quatsch zu machen, deswegen habe ich ja auch einen gravatar-Account. Aber dieses Vertrauen kann ich ja nicht allen meinen Besuchern aufzwingen, oder?


    Und Nummer 1 ist mit am übelsten: Die Datenübertragung der IP in die USA ist ja datenschutzrechtlich zumindest fragwürdig ohne vorheriges Einverständnis des Besuchers. Ich weiß, das ganze moderne Web funktioniert so und alle extern eingebunden Sachen von Like-Button bis Analytics ermöglichen das. Tja...


    Ich habe auch mal nach Plugins gesucht und nichts direkt Passendes gefunden. "Simple Local Avatars" ermöglicht das Hochladen von Avataren für angemeldete Nutzer, aber das hilft beim anonymen Kommentieren nicht weiter.


    So, und nun würde ich gerne wissen, wie man das denn zumindest verbessern könnte. Ich will Gravatare nämlich nutzen, weil ich das Konzept schön finde, aber ein bisschen besser muss das doch noch gehen?!


    Was ich mir vorstellen könnte: Eine Checkbox anbringen "Gravatare nutzen". Ist diese beim Kommentieren nicht angehakt, wird ein lokales Standard-Bild verwendet. Dann wird schon mal nicht der MD5-Hash veröffentlicht von diesem Nutzer, was die Punkte 2 bis 4 behebt. Für Gravatar-Nutzer könnte man einen Hinweis-Text anbringen, der 2 bis 4 kurz erläutert. Erwähnung in der Datenschutzerklärung der Seite muss natürlich auch.


    Fallen euch noch andere Möglichkeiten ein, insbesondere zu Punkt 1?