Beiträge von codestyling

  • Suche Upload-Manger u. Popupfunktion

    Da du WP Super Edit installiert hast, kann dieser Probleme nach sich ziehen.
    TinyMCE gehört bereits zu Lieferumfang und ist speziell von und mit Moxiecode an WP angepasst, die Download Variante von Moxiecode direkt arbeitet so nicht mit WP.

    Um alle Funktionen von TinyMCE freizuschalten, gibt es das Plugin TinyMCE Advanced: http://www.laptoptips.ca/projects/tinymce-advanced/

    Während des Hochladens von Bildern in die Mediathek beim Schreiben lässt sich festlegen, ob in wie man beschriften oder verlinken will.
    Wenn du ein umfassenderes Bildverwaltungsystem mit eingebauten Anzeigfeatures haben möchtest, empfiehlt sich NextGen Gallery: NextGEN Gallery at alex.rabe

  • Textformatvorlage erstellen mit Button für TinyMCE, Text hervorheben/einfärben

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


    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).

  • Nextgen Gallery: Sprachen

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

    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.

  • frontend und backend von deutsch auf englisch

    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.

  • frontend und backend von deutsch auf englisch

    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.

  • frontend und backend von deutsch auf englisch

    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.

  • WordPress + YiGG = YiGGPress

    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.

  • WordPress + YiGG = YiGGPress

    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

    Code
    add_filter('the_content', 'yigg_button');

    den jedes andere Plugin durch

    Code
    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!

  • Gleichmäßige Innenabstände bei "Box" mit Hintergrundfarbe

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

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

    und mit einem Stylsheet:

    Code
    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.

  • WP? - neeeee

    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.

  • TinyMCE und cfm compressor für Geschwindigkeit

    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.

  • Probleme bei Umlauten in der URL

    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.

  • TinyMCE wieder mal

    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.

  • TinyMCE wieder mal

    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.