Beiträge von Media Addicted

Long Story Short: wenn ich einen Beitrag planen will, dann passiert bei mir folgendes - siehe Dateianhang.

Sieht mir aus wie ein Bug bei der Interpretation der Datenbank-Infos bzw. irgendein Glitch mit den Datumsformaten von Wordpress und der Datenbank.

Nutze WP 3.4.1 auf einer MySQL-Datenbank (alles gehostet bei all-inkl).

Bei mir gehts auch nicht...

Habe auch diesen Plugin-Wahnsinn mal wieder abgespult. Nichts.
Editor erscheint gar nicht. Memory Limit ist bei mir auf 64MB (mehr geht nicht, war aber auch noch nie ein Problem). WP 3.2. soll doch angeblich so schlank, leicht, fruchtig und locker und überhaupt so viel toller sein als 3.1 :?

habe meine frage mit "trial & error" selbst beantwortet: das sind tatsächlich artikelbilder. wobei ich sagen muss, dass das mit eigener post-id maximal ungünstig gelöst ist.

Hallo,

ich habe in meiner DB in der Tabelle wp_posts eine Menge Einträge, die als

• post_title und post_name nur ein Wort haben (jeweils den Titel eines Bildes aus meinen Uploads),
• den post_status "inherit", aber nicht (wie bei Revisionen von Posts) den post_type "revision", sondern "attachment".
• post_content ist immer leer,
• post_mime_type ist "image/png".

What the heck ist das? Sind das Artikelbilder?

Aufgefallen ist mir das nach dem Upgrade auf Version 3.2, allerdings liegen die Einträge vom Datum her in der Zeit, als ich mit 3.1.4 unterwegs war...

Kann mir da jemand weiterhelfen?

Danke.

bei mir leider ein ähnliches problem: der seiten / post-editor erscheint zwar, aber selbst bei vorhandenen einträgen mit leeren fenstern und buttons sehe ich nur im HTML-modus. im visuell-Modus gibt es gar keine Buttons...

Hallo,

ich habe ein Problem mit meiner WP-AutoUpdate-Funktion von 3.1.2 auf 3.2. Ich kann unter Aktualisierungen zwar die Aktualisierung aufrufen, sie läuft auch durch und meldet "alles ok" - allerdings sind unmittelbar danach (Page Refresh) alle Aktualisierungen wieder verfügbar bzw. sie wurden eben gar nicht installiert.

Das gilt sowohl für Plugins als auch für WP selbst. Dasselbe Problem hatte ich auch schon mit 3.1.0 auf 3.1.2.

An Datenbank und Speicher (all inkl) kann es eigentlich nicht liegen: ich habe beim selben Hoster auf demselben Server noch eine andere WP-Installation, die sogar mehr Speicher benötigt, wo alles einwandfrei funktioniert.

Weiß da jemand weiter?

Hallo,

ich habe einen Beitrag bzw. eine Seite mit einem Passwort geschützt. Wenn man jetzt das PW eingibt, landet der Besucher aber erstmal wieder auf der Startseite. Wenn man dann die PW-geschützte Seite wieder aufruft, kann man sie ansehen.

Lässt sich dieser falsche Redirect irgendwie verhindern?

Danke!

Also: alle Plugins deaktiviert, wieder dasselbe Problem. Er SAGT, dass alles erfolgreich war, aber nach einem Reload des Admin Panels sind alle Aktualisierungsaufforderungen wieder da.

Provider ist all-inkl, die Seite ist http://www.media-addicted.de.

Edit: Manuell hat das Update jetzt funktioniert. Mit den Plugins besteht beim Auto-Update allerdings noch immer dasselbe Problem. Habe nochmal alles Mögliche probiert: alle Rechte in wp-content auf 777 gesetzt etc. pp. Hilft alles nix.

Hallo zusammen,

betreibe Version 3.1.2 und will mit dem Updater auf 3.1.3 aktualisieren. Macht er auch alles ganz brav und sagt, dass die Installtion erfolgreich gewesen sei, mit den Links zum Dashboard etc.

ABER: danach wird nach dem nächsten Laden der Admin-Seite wieder die Update-Aufforderung angezeigt und man kann das Ganze endlos wiederholen.

Mit den Plugin-Aktualisierungen übrigens dasselbe.

Kann jemand helfen? Danke.

Hallo,

ich bin auf der Suche nach einem Plugin, das auf einer Seite / Post alle (zumindest mehrere) meiner verschiedenen Profile (Xing, Twitter, Facebook, Delicious etc.) anzeigen und verlinken kann, am liebsten mit einem schönen Icon für jede dieser Seiten.

Gibt es sowas oder ist es einfacher, sich ein paar Icons zu ziehen und einfach aus HTML sowas selber zu bauen...?

Danke.

Vorgehen

Hi,

also ich habe das Problem jetzt grundsätzlich gelöst, jedoch nicht für das Plugin. Es scheint aber ein Fehler des Plugins zu sein. Grundsätzlich bin ich so vorgegangen:

1) Mit dem WordPress-Plugin die Datenbank (Zeichensatz und Kollationen der Tabellen) auf UTF-8 bzw. UTF-8_general_ci geändert.

2) Dump machen.

3) Im Dump die noch immer falschen Sonderzeichen und HTML-Entities per Suchen / Ersetzen ausgetauscht.

4) Dump wieder einspielen.

Folgende Sonderzeichen musste ich bei mir ersetzen:

ü ü
ä ä
ö ö
Ö Ö
Ä Ä
ß ß
Ãœ Ü
Ö (war anscheinend schon korrekt kodiert)
° °
§ §
² ²
& &
&lt; ? <
&gt; ? >
&quot; "
&apos; '
&auml; ä
&ouml; ö
&uuml; ü
&Auml; Ä
&Ouml; Ö
&Uuml; Ü

Sowohl in Posts / Kommentaren / Feeds / Titeln ist jetzt alles wieder ok.

Datenbank-Codierung

Also ich habe bei mir in der Datenbank gesehen (via PHPmyadmin), dass das o.g. Skript nicht alle Tabellen von latin1 in UTF-8 konvertiert hat. Stattdessen sind einige Tabellen, u.a. die wp_posts, noch in latin1 codiert.

Eine mögliche Lösung ist diese Vorgehensweise, die ich im Laufe der Woche mal ausprobieren werde. Das dort verwendete Skript prüft JEDE Tabelle auf codierung, generiert einen SQL-Code für die Konvertierung nur der benötigten Tabellen, den man dann selbst in PHPmyadmin copy-pasten und ausführen muss.

Der Vorschlag von Pumi ist zwar einfacher, aber belässt die falsche Codierung in der Datenbank.

Widget-Dateien

Danke für die Antwort. Als Anhang die entsprechenden Dateien.

In der .po-Datei gibt es z.B. folgende Zeilen:

Zitat

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Poedit-Language: English
X-Poedit-Country: SINGAPORE
X-Poedit-KeywordsList: __;_e
X-Poedit-Basepath: .
X-Poedit-SearchPath-0: .

Alles anzeigen

In der .pot-Datei findet sich was ähnliches, allerdings mit /n-Suffix bei UTF-8:

Zitat

"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: English\n"
"X-Poedit-Country: SINGAPORE\n"
"X-Poedit-KeywordsList: __;_e\n"
"X-Poedit-Basepath: .\n"
"X-Poedit-SearchPath-0: .\n"

Alles anzeigen

In den beiden PHP-Dateien habe ich weder den String "UTF-8" noch "ISO-5589-1" gefunden.

Auch interessant: wenn man mal bei Google nur meine Seite durchsucht, dann stellt man fest, dass die Überschriften dort auch falsch dargestellt werden, die Textauszüge aber nicht...

Geschafft!

Also, zur allgemeinen Information: das erwähnte Skript hat wunderbar funktioniert. Nach der Umstellung im Blog selbst keine Probleme mit Sonderzeichen mehr.

Case closed.

Hallo zusammen,

mal wieder ne Frickel-Frage.

Ich habe auf meinem Blog (WP 2.33) das Plugin WP-PostViews 1.20 laufen. Funktioniert auch wunderbar, aber in der Sidebar meiner Seite werden die "Most Viewed" jetzt mit falschen Sonderzeichen angezeigt. (Das Problem live und in Farbe, siehe Sidebar)

Hintergrund dazu:
Ich habe vor kurzem mein Blog auf UTF-8 umgestellt. Seitdem hatte ich auch keinerlei Probleme mehr mit Sonderzeichen, weil ich mit Hilfe eines Skripts die gesamte Datenbank von ISO nach UTF konvertiert hatte. Nur dieses eine Plugin macht jetzt Ärger.

Das o42-CleanUmlauts-Plugin ist bei mir aktiv, macht aber keinen Unterschied, ob ich es aktiviere oder deaktiviere.

Ideen irgendjemand? Kann man vielleicht im Plugin irgendwo was ändern?

Bisher...

Also ich hatte in Wordpress (seit 1.5.x) nie irgendwas geändert, ausser, dass ich irgendwann mal in den Optionen "Einstellungen > Lesen" auf ISO umgestellt hatte. Habe ich dadurch auch in ISO in die Datenbank geschrieben? Ich dachte immer, dass das nur eine Art Interpreter für den DB-Inhalt sei...

Ich schaue mal in die wp-config und das Theme und poste dann hier mal die Resultate.

PS: Wo im Theme wären denn -wenn überhaupt- ISO oder UDF-Definitionen angelegt?

Hi zusammen,

ich nutze für mein Blog das Google Sitemaps-Plugin. Dort kann man separat für jede "Art" von Beiträgen eine Priorität festlegen, mit der die Suchbots (bzw. Google) den Inhalt durchforsten sollen.

Diese Kategorien sind:

• Startseite
• Beiträge
• Statische Seiten
• Kategorien
• Archive
• Tag Seiten
• Autoren Seiten

Für jede dieser Kategorien kann man eine (relative) Priorität zwischen 0.1 und 1.0 in 0.1-Inkrementen angeben. Die Unterschiede zwischen Statischen Seiten, Beiträgen und Tag-Seiten ist mir schon klar.

Ich möchte aber ganz einfach erreichen, dass alle Beiträge "gleich" gelistet werden, also gleich priorisiert und zwar unabhängig davon, ob sie im Archiv oder in den Kategorien sind.

Kann mir jemand hier erklären, wie "Archivbeiträge" von normalen abgegrenzt werden von Wordpress? Oder wie die Differenzierung von Startseite und "dem Rest" vorgenommen wird? Werden diese Beiträge dann doppelt indiziert?

Danke für Hinweise...

Es gibt dafür ein Plugin!

Es gibt für genau diesen Zweck ein schlankes Plugin.

bitcycle.de » btc-meta

Klinkt sich in den WP-Editor, wo man für jeden Post und jede Page per Checkbox bei "noindex" und "nofollow" einen Haken setzen kann.

Hallo zusammen,

ein Problem zu den Zeichen, für das ich hier leider noch keine Antwort gefunden habe. Antworten bitte langsam und für Dummies :)

Also die Situation. Bis gestern hatte ich in meinem Blog ISO... in den Optionen aktiviert, wollte aber auf UTF-8 umstellen. Habe ich gemacht. Allerdings egal wie ich es drehe, immer gibt es Probleme.

Szenario 1
1) Wordpress-Optionen "Einstellungen > Lesen": UTF-8
2) Clean-Umlauts-Plugin: DEAKTIVIERT

Ergebnis:
* Sonderzeichen in Posts, die ich nach der Umstellung auf UTF-8 (in den Lesen-Optionen) geschrieben hatte, sind ok.
* Sonderzeichen Wordpress-Intern sind ok (z.B. "Tellerrand")
* Sonderzeichen in Posts und Kommentaren, die ich geschrieben habe, während ISO-8859-1 aktiv war, stellen statt Sonderzeichen kleine Rauten mit Fragezeichen dar.

Szenario 2
1) Wordpress-Optionen "Einstellungen > Lesen": UTF-8
2) Clean-Umlauts-Plugin: AKTIVIERT

Ergebnis:
* Sonderzeichen scheinen überall korrekt dargestellt zu werden. Sowohl alte als auch neue Posts sind ok (also verfasst unter ISO... und UTF-8).
* In den Wordpress-Optionen werden bei alten Kommentaren wieder die Fragezeichen-Rauten dargestellt, in den Tabs von Firefox übrigens auch.

Szenario 3
1) Wordpress-Optionen "Einstellungen > Lesen": ISO-8859-1
2) Clean-Umlauts-Plugin: Aktiviert

Ergebnis:
* Die Anzeige der Kategorien enthält zwar keine Fragezeichen-Rauten, aber merkwürdige Zeichenkombinationen anstelle der Umlaute. (z.B. FUNdstücke oder Martin Hömmerich)
* Derselbe Fehler tritt im Tellerrand auf
* Die Posts selbst und die Kommentare scheinen sowohl in der Frontend-Anzeige als auch in der Backend-Verwaltung ok.

Szenario 4
1) Wordpress-Optionen "Einstellungen > Lesen": ISO-8859-1
2) Clean-Umlauts-Plugin: DEAKTIVIERT

Ergebnis:
* dasselbe wie in Szenario 3.

Die Masterfrage: wie kann ich diesen Zeichenbrassel dauerhaft beseitigen?!

Ich habe mir da mal ein Skript rausgesucht, welches die Datenbank von Wordpress in UTF-8 konvertiert. Ist es das was ich brauche?

Danke im Voraus für Hinweise!

die datenbank ist unkomprimiert 3,5 MB und GZIPped 540KB groß. Daran sollte es nicht liegen.

mysql dumper werde ich mal probieren...