Beiträge von codestyling

Frage: von einer eigenen Blog Seite des gleichen Blogs oder Content-Klau von einer anderen Domain ? :mrgreen:

Wenn es überhaupt sinnvoll ist, gibt es nur 2 Lösungen:

a) Frameset
Das würde aber bedeuten, das du WP dazu bringen musst, alle Templates nur in einem Frame auszugeben, während 1 konstantes Frame den Player beinhaltet und nie neu geladen wird. Das ist aber keine sehr schöne und einfache Sache.

b) Playertitelposition abspeichern und weiterspielen lassen
Falls der Player per Javascript ausgelesen werden kann, an welcher Position er ist und auch wieder mit vorgegebener Position gestartet werden kann, dann könntest du per Javascript die Position in ein Cookie schreiben und den Player nach Laden der nächsten Seite dort weiterspielen lassen wo er aufgehört hat.
Meist wird so was aber von den Playern nicht unterstützt.

Mehr Lösungen gibt es leider nicht.

Dann hast du sicher die Kommentarfunktion in den Einstellungen abgeschalten.
Somit sind neue Artikel nach dem Speichern nicht kommentierfähig. Selbst wenn du das nachträglich wieder einschaltest, ist das für gespeicherte Artikel immer noch aus.
Dann kannst du nur in den betreffenden Artikel gehen, nach unten rollen und in einer der unteren Boxen die Kommentare für den Artikel anschalten.

... und Admins sowie Benutzer sollten auch kommentieren können, da gibts bis auf o.g, Problem kein Unterschied.

Sollte eigentlich gehen, hast du Moderation an ?
Es kann auch am Theme liegen, denn mein Testkommentar kam mit der URL zurück:

http://agaporniden.sittiche.de/portal/allgemeines/1#comment-2

Ein Kommentar gab's schon und meiner wäre der 2. gewesen. Dahin wollte auch die Seite springen, nur das er nicht angezeigt wird.

Hast du meinen Kommentar in der Übersicht gefunden ?

Schwer zu sagen, wenn man sich nicht selbst einloggen kann.
Für 1und1 hätte ich zwei Strohhalme:

1 - in der .htaccess PHP5 einschalten (soll ja Plugins geben, die das brauchen, nur 1und1 hat's nicht standardmäßig an, außerhalb der WP Sektion am Anfang gleich)

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

2 - Modifikation der wp-config.php direkt nach den DB Konstanten.

set_magic_quotes_runtime(0);

Ansonsten hilft nur Plugins aus und schauen, welches es ist.

Mag ja sein, dass für deine Zwecke das vollkommen ausreichend ist, aber wenn du es schon der Allgemeinheit bereitstellst, solltest du damit rechnen, dass jemand anderes sich ein paar Texte umbenennen möchte.

Und das geht ohne Code anzufassen nur mit einem *.po/*.mo Ansatz.

Ein englisches Translation File ist normal nicht nötig, denn alle Label in WP sind normalerweise englisch vorgegeben und werden nur in andere Sprachen lokalisiert. Nur wenn du unterscheiden willst zwischen en_US und en_GB dann brauchst du evtl. ein solches File.

Schau dir die beliebtesten Plugin's an und du wirst keines mit hart codierten Texten/Label finden. Zur Veröffentlichung gehört das zum Standard. Selbst wenn du kein File selbst bereitstellst, solltest du es anderen ermöglichen, dieses sich generieren zu lassen und selbst zu übersetzen.

Ich find nun mal "quick 'n dirty" Lösungen nicht besonders berauschend. Wenn ich den Calendar nun gern in Chinesisch oder Russisch selbst übersetzen will, geht das eben nicht. Da ich mein Backend/Frontend in mehreren Sprachen umschaltbar in einer Installation von WP betreibe, nützen mir hart codierte Texte nix.

Also, ich habe beim meinen Testsystem folgendes mal eingeschaltet:

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = On

Daraufhin ging ein Anmelden gar nicht mehr (Weisse Seite Phänomen).
Dann hab ich den Language Ordner umbenannt, woraufhin beim Neuladen der Loginseite jetzt Fehlermeldungen erschienen aber eben immer noch kein Login!

Also hab ich die wp-config.php modifiziert und folgendes direkt nach den DB Definitionen eingetragen:

set_magic_quotes_runtime(0);

Somit gilt das sowohl fürs öffentliche Blog als auch fürs Backend.

Ergebnis: ich kann trotz per php.ini eingeschaltetem magic_quotes_runtime wieder das Blog und auch den Login und DashBoard benutzen. Da es nun erstmal englisch war, hab ich den Language Ordner wieder zurück benannt und schon war auch alles wieder deutsch.

Es sieht so aus als müsste man das nochmals ausschalten, bevor das erste Script per include/require geladen wird. Definitiv macht es aber die de_DE.mo Files beim Einlesen kaputt, denn diese PHP Option modifiziert Dateizugriffe und somit den Inhalt der *.mo Dateien beim Einlesen, da diese teilweise Binärdaten enthalten, deren 0x0000 in "\0" umgewandelt werden, was die

Zitat

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0

Fehler dann erzeugt.

Zitat von mi-schi

...
Ansonsten müsste ich genauso alle englischen Wörter heraussuchen, diese mit den Funktionen ersetzen (was in den JavaScript-Dateien sicherlich nicht funktioniert) und dann die .mo oder .po oder wie auch immer Dateien schreiben. ...

Wenn du ein universelles Publikum haben willst, ja. Und Javascript Dateien können sehr wohl lokalisiert werden, wie auch sonst könnte dir der Visuelle Editor von WordPress oder die Mediathek Dialoge zeigen, die deutsch sind ?
Denn im Quelltext sind die immer englisch.

... warum richtig machen, wenn's auch schnell geht. Und Wartbarkeit und Komfort ade. :cry:

Sorry, aber ich versteh unter Plugin-Übersetzung was anderes!
Wozu gibt es denn wohl PoEdit und die *.mo Files ?

Das kann man zwar so machen aber eine änderbare und anpassbare Übersetzung ist viel mehr wert.

Beispiel (stellvertretend für alle Label, die bearbeitet wurden):

<input type="submit" name="submit" value="[COLOR=Red][I][B]Optionen bearbeiten &raquo;"[/B][/I][/COLOR]>

ist viel besser so zu machen:

<input type="submit" name="submit" value="<?php _e('edit settings &raquo;', 'Events_Calendar'); ?>">

und dann per PoEdit einzulesen und eine event-calendar-de_DE.mo zu erzeugen und im Plugin per load_plugin_textdomain() laden zu lassen. Das würde ich Übersetzung nennen.

Frage 1: Werten WordPress interne Funktionen den EXIF aus oder macht das zusätzliches Plugin ?
Um den Fehler suchen zu können, müsste man wissen, ob eine pure WP2.5.1 Standardtheme ohne Plugins den gleichen Fehler produziert.

Frage 2: Läuft dein Blog in UTF-8 oder doch noch im ISO... Mode ?

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; }