Beiträge von codestyling

Ist bei diesen nix brauchbares für euch dabei WordPress Plugins ?

Zitat von _Paul_

Muss ich dazu irgendwelche "offiziellen" englischen WordPress-Vokabeln benutzen oder kann ich die englischen Phrasen benutzen, die mir in den Sinn kommen?

Solange es halbwegs korrektes Englisch ist, gibts keine weiteren Anforderungen. Die Amis werden dich schon kritisieren, wenn das Theme mal öffentlich sein sollte und denen was nicht passt. :-)
Man sollte höchsten z.B. darauf achten, das ein Post ein Post bleibt und nicht mit Sheet übersetzt wird. Ein wenig die englische Terminology sollte man schon im Auge behalten. Am Besten englisch anmelden (WPLANG in der config einen leeren String geben) und dann sieht man, ob es sich ins Bild einfügt.

Zitat von _Paul_

Wann "muss" oder besser, wann sollte ich _e('') und wann __('') benutzen?

Der Aufruf von _e('') führt ein automatisches [COLOR=Red]e[/COLOR]cho mit der Übersetzung aus, sprich der Text wird sofort ausgegeben.
DerAufruf von __('') führt kein echo aus sondern gibt nur den übersetzten Text zurück. Diese Variante ist zu bevorzugen, wenn man mit dem Text noch etwas anstellen will, bevor man ihn selbst per echo ausgibt.

Zitat von _Paul_

Was mache ich mit Strings wie diesem?

PHP

<?php comments_number ('0 Reaktionen', '1 Reaktion', '% Reaktionen' );?>

Muss das dann so aussehen:

PHP

<?php comments_number _e('0 Reaktionen', '1 Reaktion', '% Reaktionen', 'Themename'));?>

?

Nein, denn ich vermute, dass comments_number() eine Funktion ist, die intern erst die Nummer bestimmt, um die richtige Pluralform zu finden.
Allerdings ist das kontraproduktiv, wenn das der Theme-Author so verfasst hat, denn es gibt Sprachen, die die Pluralisierung mit bis zu 4 verschieden Abstufungen benutzen!

Angepasst sollte das so aussehen:

<?php comments_number (__('0 Reaktionen', 'Themename'), __('1 Reaktion','Themename'), __('% Reaktionen', 'Themename'));?>

Diese Lösung stimmt aber z.B. für Russisch oder andere Sprachen mit > 2 Pluralformen nicht. Um das korrekt so zu programmieren, damit man die ebenfalls verfügbare _ngettext Pluralisierung verwenden kann, müsste ich das Theme als Source Code haben.

Zitat von _Paul_

Und die gleiche Frage für folgenden String:

PHP

Sie können hier einen <a href="#respond">Kommentar hinterlassen</a>, einen <a href="<? trackback_url() ?>">Trackback setzen</a> oder die Reaktionen per <a href="feed/">RSS-Feed</a> verfolgen.

Ist meine modifizierte Version richtig?

PHP

<?php _e('Sie können hier einen <a href="#respond">Kommentar hinterlassen</a>, einen <a href="trackback_url()">Trackback setzen</a> oder die Reaktionen per <a href="feed/">RSS-Feed</a> verfolgen.', 'Themename')?>

Das funtioniert ebenfalls nicht, denn die Funktion trackback_url() wird nicht ausgeführt. Ausserdem wäre dann der String nicht konstant, was er aber für gettext sein muß. Deshalb muß die URL reinformatiert werden.

<?php echo sprintf(__('Sie können hier einen <a href="#respond">Kommentar hinterlassen</a>, einen <a href="%s">Trackback setzen</a> oder die Reaktionen per <a href="feed/">RSS-Feed</a> verfolgen.', 'Themename'),get_trackback_url()); ?>

Allerdings solltest du alle Texte als Ausgangssprache in englisch verfassen und danach übersetzen, denn standardmäßig läuft WP ohne Sprachdatei. Dann sollte es auch englisch erscheinen und nicht "zwangsdeutsch".

Der eingeschaltete ZEND_COMPATIBILITY_MODE führt nicht nur zu diesen Problemen sondern ist u.a. auch veranwortlich für:

• Auslieferung von korrupten, sehr langen *.zip/*.rar Dateien
• Absturz von WordPress bei Benutzung von Sprachdateien

Wenn möglich sollte diese PHP Einstellung abgeschaltet werden.

Es gibt leider nicht DIE Einstellung für den Server, es hängt immer von der entsprechenden Version (Apache/PHP/OS ...) , dem jeweiligen Anwendungsfall (WP, Typo3, BB etc.) und der Last, die auf dem Server wirken wird, ab.

Zitat von -ivan

Ich denke, man sollte generell alle Umlaute durch die Sonderzeichen ersetzen oder? Es hat noch mehr äüö ohne Sonderzeichen in der Sprachdatei DE_DU und auch in der DE-SIE.

Meiner Meinung nach sollten eher alle Umlauteersetungen (HTML entities) rausfliegen und nur noch UTF-8 darin vorkommen, denn dann gibt es deutlich weniger Probleme, wenn die Texte auch in Javascript benutzt werden. Außerdem wurde bei WP mit Version 2.5 eingeführt, dass das Encoding standardmäßig auf UTF-8 steht.
Dies sollte sich endlich mal in den Blogs durchsetzen, reine ISO Kodierungen richten mehr Schaden an als Nutzen (man beachte nur mal beispielsweise die Feedimporte, die dann in UTF-8 Blogs aus ISO Quellen reinkommen und völlig kaputt sind).

Hast du Plugins installiert ?
Ich hatte mal während einer Pluginentwicklung das Problem, das genau so was erschien, wenn ich den Theme oder Plugin Editor benutzen wollte.
Das lag daran, das ich versehentlich eine globale Variable $dir benutzt hatte.
Ich schlage vor, falls du Plugins aktiv hast, diese alle zu deaktivieren.
Danach sollte der Editor erstmal gehen. Danach einzeln die Plugins aktivieren und pro Plugin prüfen. Dann findest du den "Schuldigen" sofern es ein so gelagertes Problem ist.

Wird das eine Intranet Anwendung oder ist das öffentlich zugänglich ?
Ohne Absicherung (Anmeldung) wirds im Internet nicht gehen, sonst hast du nach kurzer Zeit massenweise blaue Pillen Werbung drin.

Es gibt auch eine Menge Themes, die mit eigenen Javascript Bibliotheken daher kommen und sich mit WP eigenen (in neueren Versionen) nicht vertragen.
Wechsel mal auf das Standard DE Theme und probiert dann den Editor.
Auch ein bekannter Kandidat für solche Probleme sind Plugins wie LightBox.

Unabhängig von Sprachdatei und Formatierern ist die Ausgabe des Datums per date() Funktion abhängig von der Betriebssystem Locale und ist bei Providern standardmäßig auf en_US gestellt (siehe php reference: date)
Nicht umsonst macht WP für die Datumswerte der Posts eine Sonderlocke (the_date()) damit man das auch per Sprachdatei formatieren kann.
Wenn du ein "aus der Luft" gegriffenes Datum deutsch formatieren willst, braucht das angepassten Code, der vergleichbar des the_date() codes ist.

Zitat von HCl

Ich würde nur im äußersten Notfall Änderungen an der Datenbank oder den Beiträgen selbst vornehmen wollen. Diese Möglichkeit habe ich aber im Auge.

So wie Du, marX, es mit dem wpautop vorgeschlagen hast, funktioniert es leider nicht.
Ich habe allerdings herausgefunden bzw. meine herausgefunden zu haben, dass die einzelnen Seiten eines Beitrags in der Methode setup_postdata() (wp-includes/query.php at line 2652ff. @ WP 2.7-RC1) generiert werden. (Ich habe einfach mal dateiübergreifend nach nextpage gesucht.) Der Hook the_content ist allerdings sehr viel später. (Ich hoffe, ich liege da nicht allzu falsch.)
Gibt es eine Möglichkeit, darein zu kommen?

Nach meine Analyse muss das <!--nextpage--> in dem Text der Datenbank stehen, denn WP splittet den Text in einzelne Seiten auf innerhalb von setup_postdata() ohne das dort ein Hook greifen kann. Später ist das nur mit imensen Aufwand zu machen.
Was mir vorschweben würde ist ein TinyMCE Plugin, das einen Button einfügt und den Text nach einladen in den Editor per Knopfdruck automatisch mit <!--nextpage--> anreichert und dann beim Speichern alles korrekt in die DB schreibt. Ein solches TinyMCE Plugin ist etwas schwieriger zu schreiben, hab aber so etwas schon gemacht. Es ist nur die WP Version wichtig, da der Editor je Version geringfügig anders ist.

Eine Frage: Warum reicht das Einfügen von <!--nextpage--> per TinyMCE Editor nicht aus ?
Man kann sich doch nicht nur den <!--more--> so setzen sondern ein Button für next page gibt es auch.
Damit wird kein Plugin benötigt und du entscheidest aktiv beim Schreiben über die Stelle der nächsten Seite.

Damit die Code-Beispiele richtig angezeigt werden,
m�ssen die Sonderzeichen maskiert

Dieser Kommentartext kommt vermutlich aus deiner comments.php oder commentform.php. Das ü ist ISO codiert muss aber auch UTF-8 sein.
Daran scheitert dann der Validator.
Wirf es raus oder speichere die Datei als UTF-8 ohne BOM und benutz ein korrektes ü.
Es könnte noch mehr solche Schnitzer geben.

Dein Kalendar Plugin wird das Problem sein: plugins/events-calendar/js/

denn die zusätzlichen Scripte des Plugins, die auf jQuery beruhen, funktionieren mit der jQuery Version nicht.
Allein 6 Scriptfehler meldet Firebug zu diesem Thema.
Wenn du den Kalendar deaktivierst, müsste es auf dem betroffenen Rechner auch funktionieren.
Du solltest evtl. ein Update des Kalendar Plugins durchführen.

Dein myGallery Plugin ist veraltet und lädt prototype.js nochmal aber mit einer alten Version 1.4.0. Diese überschreibt aber die von lightbox mitgelieferte und per wp_head() reingeholte Version 1.6.0.2.
Da dies krachen muss, denn zwischen 1.4 und 1.6 gab es einen internen Strukturwandel bei prototype.js, funktioniert auch nix mehr auf diese Weise.
Schau nach einem Update von myGallery oder einem anderen passenden Plugin.

Das gleiche Problem gab es im WPD Blog, denn lightbox und piclens behindern sich gegenseitig.
Das Script piclens.js definiert pause als Variable während lightbox.js dies als function pause(...) definiert. Das kann nicht gut gehen.
Ich hab dein lightbox.js runtergeladen und angepasst, damit das funktioniert. Ist als Anhang dran und sollte bei dir ersetzt werden. Dann funktioniert das auch wieder.

Die pragmatische Lösung sieht so aus:

1. Suche die Datei /wp-admin/import/mt.php
2. in einem Texteditor öffnen.

Nun nach folgender Stelle suchen (bei WP 2.6.2 ab Zeile 362):

} else if ( 0 === strpos($line, "DATE:") ) {
                [COLOR=Red]$date = trim( substr($line, strlen("DATE:")) );
                [/COLOR][COLOR=Red]$date = strtotime($date);
[/COLOR]                $date = date('Y-m-d H:i:s', $date);
                $date_gmt = get_gmt_from_date($date);

und durch folgenden Code ersetzen:

} else if ( 0 === strpos($line, "DATE:") ) {
                [COLOR=DarkGreen]preg_match("/^DATE:\s*(\d+\/\d+\/\d+\s*\d+:\d+:\d+)\s(AM|PM|)*/", $line, $hits);
                $date = strtotime($hits[1]);
                if($hits[2] == 'PM') $date += 43200; //add 12 hours[/COLOR]
                $date = date('Y-m-d H:i:s', $date);
                $date_gmt = get_gmt_from_date($date);

Nun sollten alle Datumswerte korrekt importiert werden.
(Zur Sicherheit kannst du ja vorher eine Kopie der Originaldatei machen.)
erfolgreich getestet mit WP 2.6.2.

Das sieht nach einer im Frameset weitergeleiteten Domain aus, die bei bplaced.net gehostet ist.
Wie im dortigen Forum nachzulesen ist, hat der Provider allow_url_fopen, Socket Zugriffe und curl unterbunden. Somit kommt das automatische Plugin-Update, das nach neueren Plugins sucht als du installiert hast, vermutlich aus dem Tritt, denn es kann nicht abrufen und wird dann evtl. sogar nur den Head der Admin Seite anzeigen ohne irgend welche Plugins zu listen.
Zu einem Zeitpunkt, wo keines der Plugins überprüft werden soll (steht in der DB, wann der letzte Check des entsprechenden Plugins war und somit die nächste Abfrage errechnet werden kann), kannst du dann vermutlich Plugins aktivieren oder siehst sie dann. Nach der Aktivierung eines dürftest du in das gleiche Problem zurückfallen.
Dies liegt am Hoster, denn die komplette Beschränkung dieser Art torpediert nicht nur WP sondern auch Joomla und diverse andere Systeme aus dem gleichen Grund.

Deine registrierte Domain liegt beim Hoster 1und1 und somit sind die Angaben zur Datenbank komplett falsch.
Der Hoster stellt die Verbindungsdaten zur Datenbank im Admin-Center der 1und1 Oberfläche dar, diese gehören in die wp-config.php.
Diese Daten solltest du auch per Mail bekommen haben bzw. am Ende als Zusammenfassung bei der Erstellung deiner Datenbank.
Die sollten in etwa so aussehen:

// ** MySQL Einstellungen ** //
define('DB_NAME', 'dbXXXXXXXXX');    // Der Name der Datenbank, die du benutzt.
define('DB_USER', 'dboXXXXXXXXX');     // Dein MySQL-Datenbank-Benutzername.
define('DB_PASSWORD', '********'); // Dein MySQL-Passwort
define('DB_HOST', 'dbXXX.1und1.de:3306');    // 99% Chance, dass du hier nichts ändern musst.
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Wobei die XXX Sachen (und das Passwort) natürlich entsprechend deiner DB Einrichtung sind.

PS: Und IDN Domains (Umlaut-Domains) bergen evtl. später noch andere Probleme.

Also ich hab mal einen kleinen Test gemacht. Folgender PHP Code wurde ausgeführt:

$date = strtotime(trim(' 09/02/2007 00:10:00 AM'));
    var_dump($date);echo "<br/>";
    $date = date('Y-m-d H:i:s', $date);
    var_dump($date);echo "<br/>";
    $date_gmt = get_gmt_from_date($date);
    var_dump($date_gmt);echo "<br/>";

und das Ergebnis ist folgendes (egal ob Leerzeichen zwischen Zeit und AM oder nicht, auch Kleinschreibung ändert nix):

bool(false) 
string(19) "1970-01-01 01:00:00" 
string(19) "1969-12-31 23:00:00"

Also das Ganze nochmal wiederholt, aber diesmal AM weggelassen:

$date = strtotime(trim(' 09/02/2007 00:10:00 '));
    var_dump($date);echo "<br/>";
    $date = date('Y-m-d H:i:s', $date);
    var_dump($date);echo "<br/>";
    $date_gmt = get_gmt_from_date($date);
    var_dump($date_gmt);echo "<br/>";

und jetzt ist das Ergebnis:

int(1188684600) 
string(19) "2007-09-02 00:10:00" 
string(19) "2007-09-01 22:10:00"

Ok, die PHP strtotime() Funktion spinnt also also mit AM/PM Angaben. Es gab dazu einen Bug Eintrag bei PHP, der eigentlich 2005 gelöst worden sein sollte: PHP Bugs: #34771: strtotime() fails with 1-12am/pm

Allerdings sieht das nicht danach aus oder der ist wiedergekehrt in PHP. Wenn man sich die Bugliste von PHP zum Thema strtotime() ansieht, dann merkt man schnell, das an dieser Funktion immer wieder was nicht geht und das auch noch OS abhängig ist: PHP Bugs: Search

Evtl. könnte man das in WP umgehen. Allerdings ist das dann im WP Trac zu melden, doch ich fürchte, das kann dauern.
Und um es nochmal klar festzustellen, es ist kein WordPress Problem sondern ein PHP Bug.

Moveable Type Import Datei - Datumswerte werden laut Spezifikation so angegeben:

AUTHOR: Foo Bar
TITLE: A dummy title
DATE: [B]01/31/2002 03:31:05 PM[/B]
CATEGORY: News

darauf wendet WordPress beim Import die regulare PHP Funktion:

$date = trim( substr($line, strlen("DATE:")) );
$date = [B]strtotime[/B]($date);

an und baut daraus den Zeitstempel für den Eintrag im Blog.
Wenn etwas mit dem Datumswert in der MT Datei nicht stimmt, liefert die strtotime() Funktion den 1.1.1970 1:00 Uhr (Start of Unix Epoc)
Dies kann auch passieren, wenn die Jahreszahl nur 2 stellig ist, siehe PHP Manual.
Ohne einen Ausschnitt aus der MT Datei mit einem später falsch konvertiertem Datum kann man nicht sagen, was schief läuft, denn der Import Code im WP sieht erstmal formal korrekt zur Spezifikation von MT aus: mtimport - Movable Type Import Format