Beiträge von Ammaletu

Also zum Bewerten habe ich auf meiner alten Seite "Xavins Review Ratings" verwendet:
http://wordpress.org/extend/plugins/xavins-review-ratings/

Wird aber wohl im Moment gerade nicht weiterentwickelt und enthält meines Wissens nach nicht direkt eine Suchmöglichkeit. Das kann man aber leicht selber programmieren, da die Ratings als Custom Field gespeichert werden und man die WP-Query darum erweitern kann.

Es gibt aber sicher auch neuere Plugins, könnte ich mir vorstellen. Wenn Du nach "Rating" suchst, immer schauen, ob das für die Nutzer offen ist. Die meisten bieten den Nutzern die Möglichkeit, etwas zu bewerten.

Ich kenne das Plugin nicht, aber so wie es da steht ist es jedenfalls nicht gültig. Du kannst ja nicht einfach in einem PHP-Block HTML ausgeben, ohne es in echo "..." zu packen. Ob PHP an der Stelle geht oder nicht sollte sich außerdem einfach herausfinden lassen.

Wenn Dir nicht wichtig ist, dass es in jedem Uralt-Browser geht, kann man das zudem sehr einfach per CSS lösen:

table.some-class tr {
  background-color: white;
}


table.some-class tr:nth-of-type(odd) {
  background-color: red;
}

"some-class" natürlich ersetzen durch eine Klasse oder ID oder sonst etwas, was eindeutig auf diese Tabelle verweist.

Browser-Support für nth-of-type ist offenbar Firefox 3.5+, Opera 9.5+, Chrome 2+, Safari 3.1+, IE 9+, was für ein Feature wie den Zebra-Effekt sicher ausreicht.

Ist das Menü sehr groß, sind also sehr viele Menüpunkte enthalten? ich erinnere mich dunkel, dass es damit Probleme geben kann, weil WP in dieser Ansicht pro Menüpunkt 3 oder 4 Felder zum Server überträgt. Und da ist auf den meisten Servern einfach irgendwo ein Limit, wie viele Felder ein Formular haben darf. Falls das bei Dir zutrifft, müsstest Du schauen, ob das Limit etwas hochgesetzt werden kann. Das wäre eine Frage für Deinen Hoster.

Punkt 1: In jedem Fall ein komplettes Backup machen! Also alle Datein (auch die WP-Dateien) und einen Datenbank-Dump vom Server ziehen und lokal lagern, für alle Fälle.

Dann wäre die Frage, wo diese Meldung genau herkommt. Ich sehe jedenfalls im Quelltext nichts verdächtiges. Du kannst ja auf jeden Fall auch mal testweise auf ein anderes Theme gehen oder mal die Plugins nach und nach ausschalten und schauen. Es ist jetzt halt erst mal schwierig zu sagen, ob da nur ein Plugin irgendwas lädt oder ob das Blog gehackt wurde.

Ansonsten kann ja auch vielleicht jemand anderes noch was zu sagen, ich bin nicht direkt Experte für solche Sicherheitsprobleme. ;-)

Das kannst Du so machen:

<?php echo do_shortcode('[nggallery id=' . get_the_field('galerienummer') . ' template=irmen]'); ?>

get_the_field statt the_field habe ich mal geraten, aber üblicherweise geben die the_*-Methoden alles gleich aus, was Du hier nicht brauchen kannst, während die get_the_*-Methoden es zurückgeben. Bietet die NGGallery denn nicht alternativ richtige Template-Methoden an? Schau mal in die Doku, das geht sicher schneller als es über den Shortcode zu lösen, der am Ende ja auch nur auf solche Methoden gemappt wird.

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.

Ich hätte noch was. In WP 3.3.1, wenn man ein Plugin im Multisite-Modus löscht:

• "Nein. Zurück zur Pluginliste" --> Im Button daneben steht "Ja, ", also hier vielleicht auch lieber analog "Nein, zurück"?!
• "Klicke, um die ganze Liste der zu löschenden Dateien zusehen" --> "zu sehen"

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:

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).

Freut mich, dass es nun geht. Das ist so sicher die einfachste Lösung und auch diejenige, die in Zukunft am wenigsten Kopfschmerzen verursacht. ;-) Außerdem sagt dem Laien "Referenzen" mehr als "Portfolio", denke ich, das ist so gesehen also auch nicht schlecht.

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.

Getestet habe ich bisher noch gar nicht, werde ich aber machen. Ich melde mich. Bis zur nächsten Version ist ja noch etwas Zeit, glaube ich.

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:

#: 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?!