Beiträge von codestyling

  • WP 2.8.1 stürzt komplett ab

    Ich würde da ja gern weiterhelfen, aber ohne wenigstens den Blog mal aufrufen zu können, was er im den HTTP-Headern meldet, wird das nix.
    Ausserdem wäre es hilfreich, etwas über den Server, seine Komponenten und die Einstellungen zu wissen. Dazu hab ich ja WP System Health als Plugin geschrieben, um Supportfragen gezielter stellen zu könne.

  • Fehlerhafte deutsche Sprachdatei

    Ich werde das Thema aufgreifen und in der Polyglot Liste sowie im Trac von WP einwerfen. Das Problem ist nicht so einfach, denn es bedarf einer Codeänderung in WP, um das sauber zu bekommen.
    Diese verwendete Pluralform

    Code
    #: wp-admin/includes/dashboard.php:240
msgid "Comment"
msgid_plural "Comments"
msgstr[0] "Kommentar"
msgstr[1] "Kommentare"

    ist nun mal was anderes als die hier verwendete Sigular Form:

    Code
    #: wp-content/themes/default/comments-popup.php:49
msgid "Comment"
msgstr ""

    Es gibt 2 Möglichkeiten, das im Code kenntlich zu machen:
    1. mit implizitem Kontext:

    Code
    #: wp-content/themes/default/comments-popup.php:49
msgid "Comment|inside popups"
msgstr ""


....


_c('Comment|inside popups');

    2. mit explizitem Kontext:

    Code
    #: wp-content/themes/default/comments-popup.php:49
msgctx "inside popups"
msgid "Comment"
msgstr ""


....


_x('Comment', 'inside popups');

    Damit würde man dem Problem auf Codeebene aus dem Weg gehen.
    Allein eine Änderung in der *.po Datei ist nicht Zielführend, denn der Code muß dazu passen.
    Soetwas kann man nur mit dem Entwicklern klären lassen, werde sehen, was ich tun kann.

  • Fehlerhafte deutsche Sprachdatei

    Hatte ich in meinem Blog schon beantwortet:

    Zitat

    Normalerweise braucht der Einleseprozess für WordPress <= 3 Sekunden pro 20 Dateien. Es werden Dateien immer in Schritten zu 20 Stück analysiert und ausgewertet. Die einzige Erklärung, die ich dafür hätte, würde sich im Bereich <em>Scriptlaufzeit</em> bewegen, denn das kann auf einigen Maschinen evtl. deutlich länger brauchen. Eine andere Möglichkeit wäre noch das Versagen der Ajax Calls zu Scannen. Das würde man im FireBug sehen können im Tab "Netzwerk" -> XHR
    Die Antwort des letzten Ajax Calls beim Scannen wäre dann interessant, ob sich dort ein Fehler äußert.

    Es läuft laut letzter bekannter Rückmeldung von zonebattler auf das Script-Laufzeit-Limit zurück, das bei ihm scheinbar voll ausgereizt wird, weil der Server nicht der Schnellste ist.

  • Fehlerhafte deutsche Sprachdatei

    Zitat von zonebattler

    [FONT=Fixedsys]“msgfmt: found 2 fatal errors”[/FONT]

    Details:

    [FONT=Fixedsys]…\wp-content\languages\de_DE.po:16148: duplicate message definition…
    …\wp-content\languages\de_DE.po:1684: …this is the location of the first definition
    …\wp-content\languages\de_DE.po:16152: duplicate message definition…
    …\wp-content\languages\de_DE.po:10189: …this is the location of the first definition[/FONT]

    Ich würde sagen, das es ein Bug in PoEdit ist, denn dieser bekommt es nicht auf die Reihe, das ein Text mit gleicher Message ID einmal mit und einmal ohne Pluralisierung vorkommt.
    Das ist aber von der Behandlung in der Sprachdatei selbst (*.mo) essentiell!

    Hier als Beispiel einer der betreffenden Stellen:

    Code
    #: wp-admin/includes/dashboard.php:240
msgid "Comment"
msgid_plural "Comments"
msgstr[0] "Kommentar"
msgstr[1] "Kommentare"

    und dann die aus dem Standard Theme:

    Code
    #: wp-content/themes/default/comments-popup.php:49
msgid "Comment"
msgstr ""

    Wie man sehen kann, ist der eine Eintrag eine Pluralisierung und der andere nicht. Dies sollte PoEdit eigentlich erkennen können, denn der Schlüssel (Key) für die obere ID ist:[INDENT] "Comment\0Comments"
    [/INDENT]während der Schlüssel (Key) für die untere ID folgender ist:[INDENT] "Comment"
    [/INDENT]Somit sind das in der *.mo Datei 2 differente Schlüssel, weswegen sie auch korrekt getrennt benutzt und gelistet werden.
    Das PoEdit das nicht versteht, ist ein Problem von PoEdit und nicht der deutschen Sprachdatei!

    Thema unübersetzte Strings, hier wieder ein Beispiel:

    Alles, was in der Sprachdatei enthalten ist und als Kommentar "[COLOR=Sienna]Not gettexted string WP_I18N_ ....[/COLOR]" enthält, sind Texte, die man nur im Quellcode ändern kann, denn zu diesem Zeitpunkt der Ausführung des Scripts ist es nicht möglich, eine Sprachdatei zu benutzen. Davon gibt es mindestens 7 Stellen im WP Core, die offizielle wordpress.pot Datei enthält diese ebenfalls. Somit ist auch dies kein Versäumnis sondern Absicht.

  • Zugriffe aus russischem Forum

    Die Übersetzungen werden besser, je öfter sie angewendet werden.
    Ich teste den Dienst schon eine Weile wegen meines WP Translation Plugin's und stelle fest, daß Sprachen, die man öfter übersetzen lässt, kontinuierlich an Qualität gewinnen.
    Das trifft für Russisch leider nur begrenzt zu, den allzu häufig werden russische Seiten nun mal nicht in deutsch übersetzt.
    Ich denke, dadurch dass man Übersetzungen verwerfen und neu anfordern kann, Google eine Translation DB hat und scheinbar eine KI ähnliche Bewertung vornimmt, steigert sich die Qualität bei verstärkter Nutzung.

  • Theme Editor Fehler nach Server wechsel

    Wenn dein neuer Server den Tokenizer nicht unterstützt (PHP Module, das standardmäßig da sein sollte), dann brechen sowohl der Theme als auch Plugineditor kommentarlos ab, ihre Seite zu erstellen.

    Das wird (hoffentlich) in 2.8.1 gefixt sein. (hier eines der WP Trac Tickets #10262)

    Das kannst du mit meinem Plugin "WP System Health" überprüfen. Unter Server Setup -> Details werden alle geladenen PHP Module aufgelistet. Steht dort Tokenizer nicht mit drin, hast du dieses Problem.

  • Texteditor

    Man kann einem Editor keine Minderleistung vorwerfen, wenn dem prinzipiell nicht so ist. Wenn ich das mal bildlich vergleichen dürfte: man hat eigentlich einen Luxusauto, das die Werkstatt aber auf 20 km/h begrenzt hat.

    In etwa so verhält es sich mit dem TinyMCE. Wenn man den pur einsetzt, wie er gedacht ist, kann der wesentlich mehr, als was WordPress zulässt.
    Die Entwickler in USA haben als Philosophie, dass man im Editor kein Markup (HTML) zu schreiben hat. Da soll nur purer Text mit marginalen Formatierungen (Fett/Kursiv...) rein.
    Aufhübschen und Umbauen sollen Plugins, Filter und die Templates, man will dort jedoch nicht ein Frontpage Clone.

    Seit Monaten, wenn nicht Jahren gibt es immer wieder das gleiche Thema in den Entwicklerlisten: "free TinyMCE" oder "lass mich HTML schreiben, ich weiss, was ich tue"
    Leider bewegt sich da momentan immer noch nix. Also kann man das nur selbst per Filterunterdrückung machen, denn die WP eigenen Autokorrekturen hat der TinyMCE im Original nicht. Das ist nur in der WP angepassten Version so.

    Deshalb würde ich nicht gleich den Editor verteufeln, wenn jemand anders den "verkrüppelt" hat.

  • Scriptfehler in der Pluginverwaltung ...

    Prototype.js ist ein Problemkind im Moment. Version 1.6.0 geht in Google Chrome überhaupt nicht und wie das mit FF3.5 ist, kann ich nicht sagen, habe ich noch nicht.
    Die Bugfixes sind bei Prototype in Arbeit, zum Teil auch gefixt. Weil Prototype immer wieder Probleme bereitet, bin ich gerade dabei, alles auf jQuery umzustellen.

  • JQuery funktioniert scheinbar nicht

    PHP
    <link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />


		<?php [COLOR=Red][I][B]wp_enqueue_script("jquery");[/B][/I][/COLOR] wp_head(); ?>
		
<script src="http://www.equine-blog.tote-zitrone.de/wordpress/wp-content/themes/equine-blue/fisheye.js" type='text/javascript'></script>


	</head>


    Wenn kein Plugin oder Komponente jQuery hinzufügt, kannst du so dafür sorgen, das es gemacht wird. Allerdings ist das dann in allen Seiten drin, weil es ja im Header passiert.