Beiträge von codestyling

Hier mal die TinyMCE Dokumentation (englisch) zum Theme content_css: TinyMCE:Configuration/content css - Moxiecode Documentation Wiki
Interessant ist folgender Abschnitt:

Zitat

/* Site rules */
body {
background: #000 url('somebg.gif');
}

/* TinyMCE specific rules */
body.mceContentBody {
background: #FFF;
}

.mceContentBody a {
color: red !important; /* FF requires a important here */
}

Alles anzeigen

Jedes gute Theme definiert über die .mceContentBody Klasse den Hintergrund für den Editor abweichend. Ebenfalls kann man, wie gezeigt, auch die Links oder sonstige Elemente im Editor dadurch beeinflussen.
Nur machen das die meisten Theme Autoren sehr zu meinem Leidwesen nicht (vermutlich aus Unkenntnis).

Das Problem liegt in der Art und Weise wie das Plugin diese Text verwaltet:
install.php

$ngg_options['galTextSlide']        = __('[Show as slideshow]','nggallery'); // Text for slideshow
    $ngg_options['galTextGallery']        = __('[Show picture list]','nggallery'); // Text for gallery

Diese werden während der Installation in eine option geschrieben mit der zum Zeitpunkt des Schreibens aktiven Sprachdatei. Nachdem es erstmal in der option Tabelle gespeichert ist, ändert sich das nie mehr.
Demzufolge sind diese beiden Texte auch nicht wirklich Sprachdatei abhängig, es funktioniert nur für Blogs, die sich in einer Sprache bewegen und sich zum Zeitpunkt der Installation in der richtigen Sprache befinden.

Diese sollte der Autor umgehend ändern und für Multi-Lingual Blogs immer durch die Sprachdatei laufen lassen als es statisch abzuspeichern. Bitte dem Autor darauf hinweisen, ggf. diesen Post als Link mitschicken.

In der Sprachdatei von WP sind alle Angaben für zum Beispiel Monatsnamen, Wochentagsname und einige Kommentar basierte Text drin, die leider im Frontend benötigt werden, damit man korrekte Ausgaben bekommt.
Im Moment arbeite ich daran, wie man mehrere Sprachdateien konzeptionell so in WordPress als Standard integrieren kann, dass man:

1. zwischen Backend und Frontend unterscheiden kann
2. möglichst wenig PHP Dateien ändern muß
3. mit bestehenden Plugins und Themes keine riesige Baustelle aufreißt.

Wie gesagt, das ist alles andere als trivial und ich hab schon einen Berg Papier vollgekritzelt aber noch keine wirkliche Lösung. Irgendwo ist immer eine "Kröte" versteckt, die man schlucken müsste.

Ich diskutiere das auch mit einigen Entwicklern, aber das ist zähflüssig im Moment.

Ja, das ist u.U. ein Problem. Es gibt auch eine heiße Diskussion in der Entwickler-Liste um dieses Thema. Ich hab auch schon mehrmals vorgeschlagen, einen Weg zu suchen, wie man Frontend von Backend Sprachdateien separieren kann.
Allerdings ist das alles andere als trivial, denn man müsste eigentlich 3 Dateien haben:

1. reines Frontend
2. reines Backend
3. in Front- und Backend

damit Übersetzungen auch nur 1 mal drin stehen. Nur diese Sisyphus-Arbeit das Trennen zu wollen, macht im Moment keiner mit.

Zitat von Presswurst

Hallo,

in diesem Zusammenhang hätte ich mal ne' grundsätzliche Frage zur Sprachdatei (ich hab' das ganze Forum durchsucht und nur dieses Thema hier gefunden):

Wir die Sprachdatei nur dann geladen, wenn ich in den Admin-Bereich (sprich: Backend) gehe, oder wird die Sprachdatei auch geladen, wenn ein Besucher meinen Blog besucht? Kann man dazu eine definitive Antwort geben, oder ist das von irgendwelchen "Faktoren" abhängig?

Vielen Dank für alle Antworten im Voraus.

Die Sprachdatei wird immer geladen, egal ob Frontend oder Backend. Sobald unter WPLANG in der wp-config.php ein Wert steht, versucht WordPress diese Sprachdatei zu finden und zu laden. Denn einige Teile des Frontends bekommen ein paar Beschriftungen aus dieser Datei.

Falls in der Firma der FlashPlayer 10 installiert wurde und die WP Version < 2.7 ist, dann funktioniert der Flash-Upload nicht mehr. Es geht nur noch der klassische Upload. Es ist ein Problem mit dem 10er Flashplayer, der erst in Version 2.7 behoben wurde.

Also ohne Lizenzangabe hängt es von 2 Sachen ab:

1. ist das Plugin über wordpress.org Plugin Directory downloadbar ?
2. erweitert es die Funktionalität so, das andere Teile der Ursprungssoftware ihr Verhalten ändern ?

Zu 1.) dann gilt automatisch GPL, weil nur GPL Plugins dort Bedingung sind.
Hostet man es selbst, ist Punkt 2.) wichtig.

Zu 2.) wenn das Plugin Filter oder Hooks von WordPress benutzt, ändert es das Verhalten von WordPress (Erweiterung,Veränderung und Anpassung der Basis-Software). Somit ist dieser Teil GPL. Wenn man allerdings eine Klasse in einer extra PHP Datei hat, die keinerlei Bezug zu WordPress hat (keine Hooks, Filter, Konstanten oder WP Funktionen werden von der Klasse benutzt), kann man diese Klasse einer gesonderten Lizenz unterwerfen. Allerdings ist dann das Gesamtkonstrukt nicht mehr GPL und somit u.U. nicht mehr über das wordpress.org Directory hostbar.

Leider muß ich dir sagen, daß deine Creative Common ungültig ist, denn du baust auf GPL Code auf, benutzt die API und erweiterst den Funktionsumfang eines bestehenden GPL Produktes.
Allein die Nutzung des Filters

add_filter('the_content', 'yigg_button');

den jedes andere Plugin durch

apply_filter('the_content', 'Mein Text, der durch den Filter soll.');

aufrufen kann, wird somit zum Bestandteil des GPL Produktes und ändert dieses.
Unter diesen Voraussetzungen kann man dein Plugin frei verteilen, kommerziell einsetzen und jederzeit ändern, sorry, die Lizenz gilt nicht!

Ein sehr interessanter und informativer Test mehrerer SEO Plugins mit detaillierter Auswertung: SEO-Plugins für WordPress im Vergleich: All in One SEO Pack vs. izioSEO vs. wpSEO - TalkPress

Div's werden vom WordPress TinyMCE in <p> umgewandelt!
Warum nicht deinen Text in ein <p> sperren:

<p style="code">A problem has been detected and Win...</p>

und mit einem Stylsheet:

p.code {
font:1.1em 'Courier New', Courier, Monospace;
background-color:#FAFAFA;
border-color:#DDDDDD;
border-style:dotted;
border-width:1px;
padding:4px;
}

Mit Klassen behaftet Paragraphen behält WordPress als "vom Benutzer gewollt" bei. So geht das super.

Man könnte allerdings auch die dafür vorgesehenen <code> oder <pre> Tag verwenden und stylen.

Zitat von MystikWolf

Dann zeig mir, wo steht
- wie ich den Editor anpassen kann

http://www.laptoptips.ca/projects/tinymce-advanced/

Zitat von MystikWolf

- wie ich eine einfachere Benutzerbedinung umsetze
- wie ich das Dashbord "aufräume"

WordPress Admin Theme Adminimize - bueltge.de [by:ltge.de]

Es gibt noch mehr, wenn man wirklich gewillt ist, sich mit der Software auch beschäftigen zu wollen. Aber deinem Tonfall entnehme ich, das du schon auf "Krawall gebürstet" hier angekommen bist mit einer befangenen Meinung und somit auch gar kein echtes Interesse hast. Überzeug mich von Gegenteil, wenn es nicht so ist.

Ist schwierig mit WordPress zu vereinen, denn der "normale" Stand-Alone TinyMCE hat alles in einem Rutsch drin und kann compressed werden, während in WP jedes Plugin ein Plugin in den Tiny "reinschieben" kann, wenn es der Meinung ist. Deshalb ist auch der Tiny speziell an WP angepasst worden.
Die allgemeine Lösung müsste man erstmal ansehen und ggf. umschreiben.

Ab WP 2.8 sollen die Scripte ja im Footer ladbar werden und ebenfalls von WP aus bereits zusammengefasst und komprimierbar sein (auf Wunsch). Das sollte dann den erhofften Gewinn bringen, der auch 100% kompatibel zu WP ist.
Die andere Alternative wäre die Aktivierung vom Turbo (Gears), der die entsprechenden Standard TinyScripte ja im Browser cachen kann.

Ist hier schon mehrmal behandelt worden. Läuft unter "Internationalisierung von Domain Namen" und benötigt PunyCode: Punycode ? Wikipedia
Deine Domain muss im Backend in PunyCode Schreibweise eingetragen sein. Aber Vorsicht, Browser verstehen das nicht immer, Flash-Uploader kann funktionsunfähig werden, weil "same origin policy" durch 2 differente Domain-Strings zuschlägt usw.
Derzeit ist es nicht empfehlenswert, mit Umlautdomains zu arbeiten.

Normal müsste qTranslate beim Interpretieren des Sprachblöcke auch auf "sinnlose" whitespace testen und diese entfernen. Das erledigt man mit entsprechenden regular Expressions. Die Frage ist, ob das der Autor berücksichtigt hat.

Hast du einen Link zu Seite parat, damit man das mal analysieren kann ?
(ggf. auch als PN wenn du das hier nicht reinstellen willst)

Das ist nicht ganz so einfach, denn es kostet eine Menge Performance. Ich hab eine Reihe von regular Expressions zusätzlich in den filter the_content gehängt und mehrere Korrekturroutinen zur Behandlung geschrieben. Ich untersuche praktisch wie der HTML Validator den (vor)produzierten Markup während der Aufbereitung zur Ausgabe und entferne oder füge Tags hinzu. Das ist aber sehr spezifisch und kann nicht allgemeingültig programmiert werden (nur wenn man richtig viel Zeit investiert evtl.) denn je nach weiteren Plugins, die den Content modifizieren können, kann es neue Probleme geben. Deshalb kann ich auch nicht 100% garantieren, das am Ende stets valider HTML rauskommt, jedoch meistens ist er valide.
Da ich selbst qTranslate nicht einsetze, kann ich nicht sagen, ob und wie man da eingreifen kann/muss. Dazu müsste ich den Code studieren. Der Autor sollte um einiges schneller sein als ich das bin.

Die externe Seite ist nicht in UTF-8 Codierung im HTML Head und die PHP Datei vermutlich nicht im Texteditor als UTF-8 ohne BOM gespeichert worden.
Beides führt dazu, das du die UTF-8 Codierung, die in der DB gespeichert ist, also ISO Zeichen dargestellt bekommst.

qTranlate klingt erstmal nach einem Verdächtigen, denn soweit ich mich erinnere, benutzt das solche Marker wie [en_US]...[/en_US] um zu kennzeichnen, was in welcher Sprache ist.
Die ist vergleichbar mit der Angabe [caption ...] ... [/caption] die für gerahmte Bilder benutzt wird.
Durch die Arbeit mit einem meiner Plugins, das ebenfall Content von statischen Seiten verändert (während der Ausgabe) bekomme ich in der WordPress eigenen Korrektur wpautop ebenfalls solche Probleme mit halboffenen <p>, sei es am Anfang oder Ende. Bei solchen Einschüben über ShortTags gibt es tatsächlich einige Problem mit der automatischen Paragraph Erstellung, weshalb ich dafür selbst Korrekturcode schreiben musste.
Eine Anfrage beim Autor, ob das Problem bekannt ist, wäre keine schlechte Idee, denn die bei dir aktivierten "Sonderreparaturen" sollte man normal nicht brauchen, um validen Code zu erhalten. Ich befürchte, das qTranslate zu einem falschen Zeitpunkt den Content "seziert" und damit kaputtes Markup produziert, wenn es Teilbereiche "herausschneidet".

Das ist eine Mischung aus Tiny, WP und Plugins.
Ein Liste der verwendeten Plugins wäre hilfreich um zu sehen, ob potentiell eines dabei ist, das dein Content der Seite modifizieren kann.
Auch wäre wichtig zu wissen, ob du den Tiny im Standard einsetzt und ob in den WordPress Einstellungen die Reparatur von HTML Markup aktiviert ist.

Löst aber nur den Speed, nicht aber die max-connetion Problematik.
Ist ein einfaches DOS Scenario, wenn die zig Bots auf deine Seite loslässt, die alle in die DB fragen, um die Seite zu erstellen, kannst du bereits damit die maximale Anzahl gelichzeitiger Connections überschreiten.
Dies ist ein generelles Problem, das man mit Beschleunigung des DB Anfragen zwar verkleinern nicht jedoch beseitigen kann!