Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenHast Du es mal mit dem Plugin WP-PageNavi probiert? Die Ausgabe mit Seitenzahlen finde ich eh schöner, und ich habe bei mir damit keine Probleme, bei einer ähnlichen Konstellation.
So wie Du die Weiterleitung beschreibst: Ist das gemäß dieses Artikels gemacht? Falls nicht liegt es sonst vielleicht auch daran, wie es genau umgesetzt ist?!
Ich würde mal vermuten so hier:
[LEFT]
<?php printf( __('%1$s %2$s to “%3$s”', 'k2_domain'), '<span id="comments">' . count($comments) . '</span>', (count($comments) != 1) ? __('Responses', 'k2_domain') : __('Response','k2_domain'), the_title('', '', false) ); ?>[/LEFT]
Du müsstest die Funktion in ein eigenes Widget gießen. Dazu gibt es Tutorials im Netz. Es gibt aber auch schon fertige Plugins, die genau das tun. Mal so auf Anhieb aus wordpress.org rausgesucht:
http://wordpress.org/extend/plugins/world-clock-widget/faq/
Die liegen in wp-includes/default-widgets.php. Dort kannst Du sie bei Bedarf rauskopieren und anpassen, wenn Du ein eigenes Widget erstellen willst. Aber bitte nicht die Datei selber ändern, das macht Dir nur Ärger bei den regelmäßigen WP-Updates.
Ich kann mich irren, aber geht es da nicht um die FTP-Zugangsdaten? Auf manchen Servern ist das scheinbar nötig.
Gib dem Pluginautor doch am besten noch die genaue Info, woran der Fehler liegt. Der kriegt solche allgemeinen Aussagen wie "Dein Plugin macht mein WP kaputt" sicher dreimal am Tag. 
Die Ursache ist hier ja, dass der Rückgabewert von get_comment_time scheinbar per Filter um ein span mit der ID "aectime8197" ergänzt wird, was die Ausgabe im Feed kaputt macht. Ich habe allerdings die genaue Stelle, wo das passiert, im Plugin nicht finden können.
darf man Wordpress ein CMS nennen?
Ja, darf man. Siehe: WordPress Wins CMS Award
Ansonsten: Geht es Dir um die Kennzeichnung der aktuellen Seite? Das macht wp_list_pages eigentlich schon von selber, Du musst nur die Klasse, die es dranhängt, im Stylesheet entsprecvhend behandeln. Schau ggf. mal in ein, zwei aufwändigere Themes rein, wie es da gemacht ist.
Ansonsten zu der Memory-Sache siehe: http://faq.wordpress-deutschland.org/exhausted-php-memory/
allow_url_fopen ist eine Option, die man in der php.ini setzen kann. Du kannst probieren, im wordpress-Verzeichnis eine php.ini anzulegen und das darin zu setzen:
; Whether to allow the treatment of URLs (like http:// or ftp://) as files.
allow_url_fopen = OnEs kann aber sein, dass Dein Provider Dir keine Änderungen dieser Einstellungen erlaubt.
Was eine API ist, kann Dir die Wikipedia sagen. In diesem Fall nehme ich an, dass die Update-Anfragen an den WP-Server scheifgehen!? Woran das liegen könnte, vor allem wenn es vor dem Update ging, kann ich Dir leider auch nicht sagen.
Logst Du Dich auf der gleichen Domain ein, unter der Du auch die Seite anzeigen lassen willst? Im Backend findet soweit ich weiß kein Redirect auf die eingetragene URL statt, das kannst Du also sowohl mit IP als auch mit Domain aufrufen. Wenn Du Dir jetzt z.B. die Loginseite mit IP-Adresse gebookmarked hast, kannst Du Dich da zwar einloggen, der Login landet aber in einer anderen Session als der fürs Frontend, welches über die Domain aufgerufen wird.
Tja, das wäre nur eine Vermutung. Ist mir mal bei einem anderen Projekt passiert und hat viel Kopfzerbrechen bereitet ehe ich drauf kam.
Kein Problem, ich knobele ja gerne an solchen Problemchen, vor allem an welchen wo sich am Ende auch eine Lösung findet. Wäre natürlich schön, wenn das im Plugin behoben wird.
Gaaaaaanz grob kann man sagen, dass man mit dem Code eines GPL-Produktes kein Geld verdienen kann/darf, wohl aber mit Services rund um ein GPL-Produkt. Sprich, du dürftest die Codebasis von WordPress nicht zum Kauf anbieten,
Dürfte man schon, allerdings nur unter den Bedingungen der GPL. Und das hieße, man müsste einen Käufer finden, der einem Geld für ein Produkt gibt, das er auch kostenlos bekommen kann. Und man könnte den Kunden dann nicht daran hindern, das Produkt seinerseits kostenlos weiterzuverteilen. Das taugt so in der Regel natürlich nicht als Geschäftsgrundlage.
Hast Du alle Vorkommen der alten Domain und des alten Serverpfades im DB-Dump ersetzt? Das steht an vielen Stellen, nicht nur die beiden Optionen, die man im WP-Backend setzen kann. Dann sollte beides eigentlich problemlos klappen.
Also man kann zumindest schon mal folgendes argumentieren: WordPress wie es jetzt ist steht unter der GPL. Damit wird der jetzige Codestand für immer frei zugänglich bleiben. Niemand kann das ändern, nicht mal die WP-Autoren.
Das WP-Team könnte sich natürlich entscheiden, die nächste Version unter eine andere Lizenz zu stellen, aber das würde die bisher veröffentlichten Versionen nicht berühren. Und das könnten sie auch nur machen, wenn sie die Erlaubnis jedes einzelnen Committers einholen würden, was sehr aufwändig bis unmöglich sein dürfte.
Genauso könnte jemand kommen und Updates von WordPress nur gegen Geld rausrücken. Allerdings müssten die Updates immer noch unter GPL stehen, und die Community würde das dann in nullkommanix in den normalen Stand mergen. Wäre also kein brauchbares Geschäftsmodell. Das gleiche gilt für den Versuch, WordPress nur noch gegen Bezahlung downloadbar zu machen. Die GPL erlaubt das durchaus, aber sie erlaubt dann eben jedem anderen auch, den Code weiterhin kostenlos anzubieten.
Ansonsten kann man ja an anderen Beispielen sehen, was passiert, wenn ein ehemals offenes System versucht, sich zu kommerzialisieren. Bei Mambo war das z.B. so (soweit ich mich erinnere -- ok, habe noch mal nachgelesen, Mambo ist ebenfalls GPL, der Streit ging noch um was anderes). Da hat sich spontan ein Fork gebildet, welcher heute als Joomla wesentlich bekannter als Mambo sein dürfte.
Ich denke, die einzige echte Gefahr für WordPress (abgesehen von einem noch besseren Mitbewerber-CMS) wäre es, falls Auttomatic mal pleite gehen würde. Aber selbst dann könnte die Entwicklung ja von der Community weitergetragen werden.
Hm, mal was mir da auf Anhieb einfällt:
- MySQL-Dump der alten Datenbank ziehen
- alle Dateien kopieren
- Blog-Adresse im Dump ersetzen
- Blog-Pfad auf dem Server im Dump mit neuem Pfad ersetzen
- DB am Ziel importieren
- eventuell Permalinks neu abspeichern um die .htaccess zu aktualisieren
Ja logisch, Du hast die Zeilen dann ja auch nicht mehr drin. Was ich meinte, ist folgendes:
<?php echo get_comment_time('Y-m-d H:i:s'); ?>Das sollte ein Datum erzeugen und sonst nichts. Es erzeugt bei Dir aber offenbar das Datum in einem span-Tag. Das könnte z.B. ein Plugin oder das Theme über einen Filter da einfügen, denke ich.
Also ich sehe Deine Testkommentare aktuell mit dem richtigen Datum. Sicher, dass Das im Opera nicht bloß gecacht war und es doch an einem Plugin lag? Ich habe gerade mal noch etwas gegoogelt, und das span könnte von "Ajax Edit Comments" stammen (wegen des "aec" in der span-ID). Hattest Du das im Einsatz?
Update: Sehe in Deiner Liste gerade, dass Du das tatsächlich im Einsatz hast. In der aktuellen Version des Plugins kann ich das span-Tag nicht entdecken. War es bei Dir vielleicht nicht aktuell? Sag mal Bescheid, ob der Fehler mit tatsächlich auftritt und ohne nicht. Strg+F5 lädt übrigens in den meisten Browsern die Seite neu unter Umgehung des Caches.
Sind keine eigenen Elemente, ist eine Code für alle Seiten im header.php.
Ok, also keine Widgets. Dann müsstest Du das auch in der header.php anpassen.
Ok, wo finde ich den richtigen Conditional Tag und wo füge ich diesen genau ein?
http://codex.wordpress.org/Conditional_Tags
Nächster Schritt wäre wie gesagt genau zu überlegen, auf welchen Seiten Du etwas einblenden willst. Wenn etwas z.B. nur auf der Startseite oder nur in Archiven oder nur nicht auf Suchergebnisseiten sichtbar sein soll, kannst Du das über eine entsprechende if-Abfrage gut regeln. Wenn Du dagegen ein Element auf allen Seiten haben willst, aber jeweils mit z.B. einem anderen Bild, dann müsstest Du eher eine Stylesheet-Lösung bauen, denke ich.
Entweder die beiden Attribute weglassen oder besser noch die richtigen Werte eintragen.
Woher kommt eigentlich das span-Tag rund um das Datum? Hast Du das in der PHP-Datei eingefügt oder kam das automatisch bei dem get_comment_time-Aufruf raus?!
Wir nähern uns langsam, aber immerhin. Meine aktuelle Vermutung wäre dann, dass es an dem span-Tag liegt. Der Aufruf von [COLOR=#000000][COLOR=Black][COLOR=#0000bb]mysql2date[/COLOR][/COLOR][COLOR=#007700][COLOR=Black] mit zwei Parametern klappt ja offenbar, mit drittem Parameter false kommt 1970 raus. In letzterem Fall nutzt WP intern die date-Funktion von PHP, während es sonst seine eigene date_i18n-Funktion nutzt.[/COLOR]
[COLOR=Black]So, und das kann ich dann ja endlich mal testen:[/COLOR]
[/COLOR][/COLOR]
Datumstest 1: <?php echo date('D, d M Y H:i:s +0000', strtotime('<span id=\'aectime8197\'>2009-11-23 18:21:29</span>')); ?>Ergibt: Datumstest 1: Thu, 01 Jan 1970 01:00:00 +0000
Datumstest 2: <?php echo date('D, d M Y H:i:s +0000', strtotime('2009-11-23 18:21:29')); ?>Ergibt: Datumstest 2: Mon, 23 Nov 2009 18:21:29 +0000
Ja, da hätten wir es doch hoffentlich gefunden. Bleibt nur noch zu schauen, ob Dein Theme oder eines der Plugins dieses span-Element per Filter an das Datum dranhaut.