Beiträge von codestyling

Kann nicht gehen, den WP setzt die Locale nicht sondern schaltet nur die Sprache um. Im Plugin wird [COLOR=Red]strftime[/COLOR] benutzt, was aber an die gesetzte Locale gebunden ist und somit auf "de_DE" steht aber eben nicht auf "de_DE.utf-8".

for($currentMonth = 1; $currentMonth <= 12; $currentMonth++) $monthNames[$currentMonth] = ucfirst(strftime("%B", strtotime("$currentMonth"."$bogusDate")));

Wenn du im Plugin das Array $monthNames[] mit den 12 korrekten deutschen Monatsnamen bestückst statt die formatieren zu lassen, dann ist's auch UTF-8. (Datei in UTF-8 ohne BOM Marker speichern!)

Erweiterung: Ich hab nochmal nachgedacht, entweder hat dein Provider zwar die deutsche Locale aktiviert aber nur für ANSI charsets und bräuchtest die UTF-8 charset Variante, oder aber dein Provider bietet dir einen Windows Server (kein Unix) als Basis. Bei Windows Server hilft auch keine korrekt gesetzte Locale, da muß man

1. erkennen, dass es ein Windows Server ist und
2. falls es so ist, eine iconv() Konvertierung des Monatsnamens nach UTF-8 machen.

Es ist sicher einfacher, das Array der Monatsnamen händisch mit den korrekten Werten zu bestücken. Oder du benutzt die Namen aus der Übersetzung per

...
$monthNames[1] = __('January');
....

Was ich eigenartig finde ist, dass deine normale Domain 2 Cookies setzt, die offensichtlich domainweit gelten (also auch für die Blog Subdomain) aber vom Blog her nicht gesetzt oder refreshed werden.
Wenn ich mich im Blog bewege und die Cookies vorher beide gelöscht habe, setzt keine der Seiten des Blogs, auf denen ich kommentieren könnte, die Cookies neu.
Kann es sein, das für den Fall, dass jemand Cookies unterdrückt hat (ausgeschaltet), dein Comment Template einen zufälligen (oder immer einen bestimmten) User einträgt ?

So trivial ist das Ganze leider nicht. Dazu muß man

1. ein WordPress Plugin schreiben, das
2. ein TinyMCE Plugin in den Editor integriert, welches man
3. ebenfalls in JavaScript schreiben muß.

Das heißt, du braucht Ahnung von WP Plugin Codierung, Wissen um den Aufbau und Verwendung von JavaScript Plugins für den TinyMCE und Kenntnisse, wie das mit dem Editor interagiert.

Das mal eben schnell aus dem Ärmel schütteln geht vermutlich nicht, dabei riskiert man einen funktionslosen oder schlimmstenfalls nicht mehr erscheinenden Editor.

Ich kann dir da leider kein Tutorial bieten, wäre aber ein interessantes Projekt, wenn ich mit meinen Laufenden durch bin.

So was passiert gern mal auf "Gemeinschaftsrechnern" wie z.B. in Universitäten. Wenn sich mehrere Benutzer den gleichen Account bei Windows teilen müssen, dann sind sie für den Browser physisch der gleiche Benutzer und die zuletzt genutzten Cookie werden dann verwendet.

Wenn also erst "Meier" bei dir kommentiert und danach "Schulze" mit den gleichen Windows Account, dann sieht der eben "Meier" in den Kommentarfeldern schon eingetragen.

Zitat von tatoosh

sobald mehr text im main steht, kommt automatisch rechts im browser die scrollleiste. dann verschiebt sich alles, ...

Was soll sich Verschieben, ich seh nix Ungewöhnliches. Der FireFox blended die Scrollleiste erst ein, wenn der Text länger als der sichtbare Bereich ist, der IE hat sie immer da nur stellt er die erst auf "benutzbar" wenn die Seite aus dem sichtbaren Browserfenster geht.

Da in FireFox die Breite der Scrollleiste beim Erscheinen von deiner Body Breite abgeht, führen die margin: 0px auto; Anweisungen im Stylesheet zum Sprung nach links um die halbe Breite der Scrollleiste, also normales Verhalten.

Zitat von fischnackdissen

Ich bin leider vieeel zu schwach in Programmieren und kann daher nur meine Wünsche nennen aber leider keinen Editor selber verbessern bzw. umprogrammieren.

Das ist vollkommen ok, niemand muß alles können. Allerdings ist bei Kundenaufträgen ein wenig Programmierung immer von Vorteil, denn dann kann man das machen, was ich als Screenshot angehängt hab. Man gibt dem Benutzer/Kunden einfach die Möglichkeit, im Editor spezielle Formatierungen machen zu können.

Die gezeigte Erweiterung ist integraler Bestandteil des Freshy Themes (nicht von mir) aber auch ich hab schon Extensions für jemanden integriert, der es komfortabel braucht.

Und zum Editor (TinyMCE) kann man folgendes festhalten: Die "Verunstaltung" von Codeeingaben ist [COLOR=Red]nicht[/COLOR] Bestandteil des Editors selbst, denn der wird auch in anderen Projekten (nicht WordPress) ohne diese Probleme eingesetzt. Es ist die Philosophie von WordPress, dass die Beiträge im Grunde keinen Code enthalten sollen und werden durch eine WordPress spezifische Anpassung nach bearbeitet, die manchmal eben nicht das macht, was man gern hätte. Dies kann man auch "totlegen", aber eben mit dem Ergebnis, das dann in der DB nicht mehr der pure Text landet (was WP eigentlich haben will) sondern der ganze Markup eben auch. Hatte das schon mal aus der WP 2.3.3 rausgebaut und schaue gerade, wie ich das aus WP 2.5.1 rausbauen kann, denn der Editor und WP Anpassungscode ist 100% neu (neues Konzept auf Prototype.js).

Wäre dann aber eben auch ein Patch und somit nicht Update sicher.

Zitat von flowers@jesus-initiative

Wie löst man denn das Problem mit CSS, dass man z.B. drei Zeilen Text rechts neben einem Bild schreiben kann, dann z.B. drei Leerzeilen eingibt (oder eben entsprechendes per CSS!), damit der weitere Text unterhalb eines Bildes weitergeht und das nächste Bild nicht neben dem vorherigen Bild klebt, sondern unter jenem.

Entschuldige, das ich nicht genau weiß, welche Bilder und Anordnungen du aus deiner Seite meinst. Es hängt ein wenig von Bildformaten ab (ich benutze zum Beispiel feste Formatgrößen, nur wenige), für die man das sehr schön machen kann. Ausserdem sind in <p> zwar keine <div> erlaubt (Blocktag in Blocktag) aber man kann <span> benutzen, weiteren Text reinstapeln, klassifizieren und dann per CSS die <span> zum Blocktag machen (display:block). Das ist durch die Brust ins Auge aber der HTML Markup validiert. Spezifischer hab ich's jetzt nicht, da ich nicht weiss, was genau du meinst.

Zitat von Astrid

codestyling,
was hat das mit dem Standpunkt zu tun?

Wikipedia: Standpunkt

Wenn man sich die Klientel von WordPress ansieht, dann muß man mit einer Menge Leute rechnen, die noch nie in ihrem Leben Sourcecode oder HTML/CSS gesehen haben und es auch gar nicht richtig wollen. Es geht nur um's Schreiben. WordPress ist ein System, das dafür konzipiert wurde, auf die dümmsten Eingaben und/oder Benutzungsweisen soweit wie möglich geregelt reagieren zu können. Und Benutzer kommen auf saudumme Ideen, das kann ich nach zig Jahren Entwicklung nur bestätigen. Das ein System, das unter dieser Prämisse verbreitet wird, nicht hochgradig optimiert sein kann, dürfte klar sein.

Ich bin kein Entwickler des WP Kerns und habe auch nie gesagt, das es nichts schnelleres oder evtl. besseres gibt. Nur eine Pauschalisierung ohne Fakten ("... ist Fakt!") ist noch keine untersuchbare Aussage mit Substanz, die zur Lösung eines Problems beiträgt.

Ein System ist nur so schnell, wie seine schwächste Stelle. Und die ist nun mal im den meisten Fällen die DB.

Benenn doch einfach die de_DE.mo um, bring WP zum Error und du weißt es.
Wiederherstellen des Names nicht vergessen hinterher. :mrgreen:

Zitat von Astrid

Ich möchte das auch einmal kurz einwerfen. Machen wir uns nichts vor - die Performance von WP lässt allgemein zu wünschen übrig, das alles auch völlig ohne PlugIns. WP trödelt - Fakt.

Sagen wir mal so, ich empfinde das gerade noch im Rande des akzeptablen Rahmens.

Ist ein Standpunkt, den ich aber nicht teile. Denn wenn man einen Rootserver nimmt, auf dem die DB lokal ist und WP nicht über das Netzwerk aus Timbuktu Daten lesen muß noch sich mit 500 weiteren Domaindatenbanken arrangieren muß, dann rennt das plötzlich ohne Ende.

Die DB Overloads, Latenzzeiten (kann ja mal über USA laufen der Request) und Requestanzahlen an sich werden immer ausgeblendet bei dieser Diskussion, obwohl die der Zeitkiller schlechthin sind.

Sicher ist das eine oder andere Kernmodul optimierbar, aber der Brüller kommt da nicht raus. Was auch einen Teil der Performance kostet, ist die immer umfangreicher werdende Prüfung der Nutzereingeben (Comments, Post Inject Attacken und der gleichen), damit hier nicht wieder jeder heult, dass das Blog geknackt wurde. Sicherheit kostet etwas Performance, war schon immer so. Ausserdem nimmt die Anzahl der "bad bots" rasant zu, ich hab Logfiles, wo wild gewordene, neu erschienene Bots 10000 Abfragen in nur 5 Minuten durchs Blog jagen wollen. Bei so viel Traffic, der nur sinnlose Arbeit für das Blog (und den Server) bedeutet, muß auch irgendwann die Performance deutlich runtergehen für die normalen Surfer.

Ich will bei Leibe nicht WP auf einen Sockel setzen, aber die Kirche muß im Dorf bleiben. Bei 0,00€ Hostern oder 500 Domains auf einer Machine Billig Paketen will man allen Ernstes in dieser materiell ausgelegten Welt erwarten, goldene Wasserhähne zu bekommen ?

Zitat von flowers@jesus-initiative

Ich habe nicht ausprobiert, ob man das <p>-Tag braucht, aber wenn dann auf jeden Fall mit Attributen, ansonsten wird es auch wieder gelöscht. Dann mit width und height ausprobieren, welche Werte zum Erfolg führen und wieviel Leerraum man haben will.

Ich finde das schon merkwürdig, dass Leerzeilen einfach gelöscht werden und man auf so komplizierte Sachen ausweichen muss.

Was spricht gegen eine Leerzeile mit <br />, dass WP sie unbedingt löschen muss?

Viele Leerzeilen und massig Leerzeichen sind doch nur ein Ersatz für unzureichendes Styling per CSS.
Wenn ich ein Bild mit 50px Abstand nach oben in den Artikel haben will, dann geb ich dem Bild eine class="obenluft" die ich im CSS File dann definiere mit:

.obenluft { margin-top: 50px; }

Und schon hab ich meinen gößeren Abstand. Inplace Styling ist schlechter Stil, dazu gibt es CSS Dateien, die auch noch browserspezifisch geliefert werden können.
Die HTML spezifikationskonformen Browser komprimieren ja auch x Leerzeichen zu einem zusammen, weil das nicht statthaft ist nach HTML.
Layout und Content sind 2 verschiedene Sachen, Content wird in HTML/XHTML ausgezeichnet und das Layout per CSS definiert.

Zugegeben, der Editor vergreift sich manchmal, aber sobald man class="..." benutzt, bleibt die auch erhalten. Mehr braucht es auch nicht.

Die definierten CSS Regeln lassen sich ja auch zusammensetzen und auf Paragraphen, Div's oder sonstiges anwenden. Man kann ja auch mehrere angeben wie: [COLOR=Black]<p class="[/COLOR]topbigspace[COLOR=Black] red clear">...</p>[/COLOR] mit

.topbigspace { margin-top: 80px; }
.red { color: #f00; }
.clear { clear: both; }

Im Rahmen eines größeren Projektes hab ich ein Auskopplung als Plugin bereitgestellt, die es möglich macht, sich an WordPress in verschiedenen Sprachen anzumelden und die Admin Oberfläche entsprechend beschriftet zu bekommen.

Plugin Seite: WPML Admin

Der Umfang der finalen Release wird einiges größer sein, aber bereits diese Auskopplung ist interessant, wenn man mehrere Benutzer im Blog hat, die verschiedene Sprachen in der Admin Oberfläche bevorzugen (z.B: englisch statt deutsch, oder französisch). Welche Sprachen verfügbar sind und per Anmeldung ausgewählt werden können, entscheidet der Blogbetreiber selbst. Ich hab eine stattliche Sammlung der WP 2.5.1 *.mo Files für verschiedene Sprachen zusammengetragen, wenn Bedarf besteht, kann ich das noch bereitstellen.

Ein Feedback hierfür ist sehr willkommen und Kritik ist ebenfalls erwünscht.

Ich hab mal eine Auskopplung aus dem laufenden Großprojekt gemacht und die Umschaltung des Administrations Login als abgespecktes Plugin veröffentlicht.

Wer es testen möchte, kann es hier nachzulesen und runterzuladen: Code Styling Project » WordPress 2.5.1 - mehrsprachige Anmeldung (beta download)

Feedback erwünscht, die volle Packung (finale Komplettlösung nicht nur Auskopplung) ist noch nicht stabil genug für den produktiven Einsatz auf allen Server Systemen, aber die Auskopplung ist erfolgreich durchgetestet.

... siehe nächster Eintrag.

Sofern für Strato Kunden noch folgende Probleme mit dem PHP safe_mode aktuell sind:

Safe Mode bei Strato umgehen - WordPress 2.2 installieren (gunnART - Grafik, Layout, Konzeption)
Das Strato Safemode Problem und die Antwort von Strato - Joomla CMS Support Forum

... liegt es am eingeschalteten safe_mode="on".

Das könnte auch andere Hoster betreffen, kann man nachsehen mit phpinfo(); ob es on ist, dann sind Komplikationen vorprogrammiert.

Noch ein Nachtrag: Feeds sagen nicht, was sie sind. Rote Zeilen fehlen

<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    [B][COLOR=Red]xmlns:atom[/COLOR][/B][B][COLOR=Red]="http://www.w3.org/2005/Atom"[/COLOR][/B]
    >


<channel>
    <title>theleprompt</title>
    [B][COLOR=Red]<atom:link href="http://www-test.blogs.uni-osnabrueck.de/theleprompt/feed" rel="self" type="application/rss+xml" />[/COLOR][/B]
    [COLOR=Black]<link>http://www-test.blogs.uni-osnabrueck.de/theleprompt</link>[/COLOR]
    <description>Zufälliges aus der elektrosozialen Welt.</description>
    <pubDate>Mon, 02 Jun 2008 23:27:11 +0000</pubDate>
    <generator>http://wordpress.org/?v=2.3.3</generator>
    <language>en</language>

Wenn im Channel die korrekte Feedadresse nicht drin ist, kann das auch in die Hose gehen.

Nach Durchsicht der WP Sourcen läuft Feed Import über Socket Funktionen innerhalb der Snoopy Klasse. Falls dein Provider socket Benutzung komplett unterbunden hat, kann es auch fehlschlagen.

Es gibt mehrere Gründe, warum das intern fehlschlagen kann, aber die aussagekräftige Meldung (solche komischen PHP Fehlerzeilen im Output) wurden willentlich unterdrückt:

Snoopy

@$client->fetch($url);

und der Text kommt einerseits hier vor (ist es aber nicht)

function wp_rss( $url, $num_items = -1 ) {
    if ( $rss = fetch_rss( $url ) ) {
....
    } else {
        _e( 'An error has occurred, which probably means the feed is down. Try again later.' );
    }
}

und nochmal im Widget (vermutlich richtige Stelle):

function wp_widget_rss_output( $rss, $args = array() ) {
    if ( is_string( $rss ) ) {
        require_once(ABSPATH . WPINC . '/rss.php');
        if ( !$rss = fetch_rss($rss) )
...


    } else {
        echo '<ul><li>' . __( 'An error has occurred; the feed is probably down. Try again later.' ) . '</li></ul>';
    }
}

Also es muß einen Fehler beim Abholen geben und ich würde stark auf socket Beschränkungen seitens des Providers tippen, wenn es nicht am Inhalt der Feeds scheitert.

Zusatz: Auf meinem Test XAMPP System laufen beide Feeds aus dem 1. Posting sowohl im Blog Widget als auch im Dashboard.

Zitat von attze

Der Witz ist aber, dass Feeds intern aber auch nicht funktionieren. Wenn mit wordpress Mu einzelne Blogs andere Blogs aus der selben Installation feeden, dann kommt der selbe Fehler. :twisted:

Im Mensafrei Feed wird eine DTD referenziert von itunes, die man nicht laden kann und 404 als Anwort bekommt.
Da Feedparser immer auch die DTD's laden, kann er das nicht für

xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"

und somit bekommst du die Anzeige, ist nicht verfügbar !
Wenn schon Sonderlocken mit DTD's fahren, dann auch erreichbare angeben !

Zitat von attze

Mit verlaub, ich halte diese Erklärung für falsch, weil das Problem auch auftritt, wenn alles brav in utf kodiert wird.

Ok, ich hab derzeit nicht die Zeit, WP zu debuggen aber wenn ich den Feed vom ORF validieren lasse, dann ist der zwar ok, aber ein Parser wie der der Widgets kann über diese Zeile stolpern !

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

Und hier der kaputte ZAMG validiert

Ich glaub nicht, das der Widget Parser so tolerant geschrieben ist, wie FireFox, der da drübergeht!

Also die 2. Editorzeile mit den Paragraphen, Fonts, Video usw. wird in meiner deutschen WP Version mit Shift + ALT + Z ausgeklappt.

[COLOR=Red]Wichtig:[/COLOR] Hab eben festgestellt, das es einige Themes wie "freshy" schaffen, den letzten Button (der normalerweise die 2. Zeile einblendet) zu entfernen und mit einen eigenen zu ersetzen. Also Themes, die sich in den Editor für spezielle Funktionen integrieren können, haben das Potential dazu, diesen zu beschädigen.

Welcher Feed soll importiert werden ?
... und das hier hab ich schon mehrfach geschrieben:

http://forum.wordpress-deutschland.org/konfiguration/…html#post169756
http://forum.wordpress-deutschland.org/allgemeines/35…html#post170296