Beiträge von codestyling

    Verstehe den Anwendungfall nicht. Sagen wir mal dein Theme hat die textdomain "ABCD" und du möchtest als Plugin BuddyPress mit in die gleiche Sprachdatei haben. Dann müstest du erstmal ca. 1000 Stellen in BuddyPress von der BuddyPress textdomain auf "ABCD" ändern. Dann müsstest du das alles in einen Ordner zusammkopieren und scannen lassen.

    Allerdings ist die viele Arbeit dahin, wenn es ein Pluginupdate gibt (zum Beispiel wegen eines Sicherheitsrisikos, welches du nicht ignorieren kanns) und alles wieder auf BuddyPress steht.

    Kannst du einen plausiblen Anwendungsfall dazu liefern, mir fällt keiner ein.

    Mit einem redirect wird der Browser angewiesen, die Seite frisch unter der gegeben URL abzuholen. Damit ist es nix mit Fehler ausgeben!

    Wenn du einen Fehler in der Bearbeitung findest, dann füllst du das Formular mit den entgegen genommenen Daten aus, packst deine Fehlermeldung hinzu, überspringst die Datenbank Speicherung und auch den redirect.
    Damit bekommt der Benutzer die Seite so angezeigt, wie er sie abgeschickt hatte, nur das dann zusätzlich der Fehler drin steht. Er kann jetzt ergänzen, was fehlt und erneut abschicken. Wenn alles passt und deine Prüfungen ok sind, kannst du es in die DB packen und redirect aufrufen. Dann bekommt der Nutzer wieder ein leeres Formular.

    Zeigt mir leider die Sprachdateien für WPtouch nicht an.


    Das kann ich so nicht stehen lassen. WPTouch hatte in älteren Versionen ein Problem, das ich in meinem Beitrag WPTouch iPhone Theme und die verkrüppelte Übersetzung beschrieben hab. Spätesten mit Version 1.9.26 zeigt mein Plugin sehr wohl auch WPTouch an. Allerdings bringt die kostenfreie Version über wordpress.org Repository keinerlei Sprachdateien mit sondern nur eine Vorlage.
    Wenn man fertige Sprachdateien dazu haben möchte, muß man sich auf die Webseite des Anbieters begeben und hoffen, daß die dort kostenfrei zu haben sind.
    Sonst erstellt man eben eine neue mit meinem Plugin und übersetzt die komplett selbst. Ist aber einiges an Arbeit, was man dann investiert.

    Mal eine Frage: Kann es sein, das der Spam über dein Mobile Theme (WPTouch) reinkommt und AntiSpamBee dort nicht greift?
    Überprüf mal, wenn möglich, ob die fraglichen Kommentare per Mobile Theme reinkommen.

    Eine Multisite Installation funktioniert nicht, wenn WordPress in einem Unterordner installiert ist. Siehe offizielle Seite: http://codex.wordpress.org/Create_A_Netwo…gs_Requirements

    Wichtigster Abschnitt:

    Zitat

    Giving WordPress its own directory will not work in WordPress 3.0 with multisite enabled. It interferes with the member blog lookup. If you wish to install WordPress in a folder AND have that folder name it will work. Domain mapping, however, will not work.

    90M Benutzung von Arbeitsspeicher ist die eine Seite der Medaille, aber da es ja um dem upload von Files geht, gibt es natürlich auch dafür ein Limit. WP System Health zeigt das bei 1und1 im PHP Reiter auch an:

    Code
    Maximum File Size
    [I](upload_max_filesize)[/I][B]                         40 MB[/B]
    The maximum size of an uploaded file.

    obwohl das memory_limit bei 90M steht.
    Da ja schon etwas für PHP core an Speicher benötigt wird, beliben ca. 32M übrig für die Bilder beim Upload. Deswegen steht auch der Server bei 32M aus obwohl doch 90M da sind. Der Abbruch basiert auf dem Limit für uploads und wird in der gleichen Art und Weise reported als wäre es ein Speicherüberlauf.

    Konsequenz ist, das du kleiner Bilder oder Bilder zips hochlädst, denn ich fürchte, das 1und1 dieses Limit nicht ohne weiteres ändert.

    Deine Installation versuch 3 Versionen von jQuery zu laden in dieser Reihenfolge:

    Code
    1.) http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
    2.) http://gasthaus-lober.de/wp-includes/js/jquery/jquery.js?ver=1.4.2
    3.) http://gasthaus-lober.de/wp-content/themes/Lober/js/jquery.min.js

    Nummer 2.) ist die korrekt Version, die WordPress mitbringt und sicher auch konsequent von mehreren Plugins benutzt wird, wie im Codex beschrieben.
    Nummer 1.) ist mir nicht klar, vermutlich hast du irgend ein Plugin laufen, was fehlerhaft versucht, jQuery grundsätzlich vom Google CDN zu laden.
    Zu 3.) kann man nur sagen, das es ein schlecht programmiertes Theme ist, wenn es seine eigene Version von jQuery mitbringt, wenn es doch WordPress schon an Board hat und in einer weitaus fortgeschritteneren Version.
    Die auf jQuery basierenden Lighboxen (egal welche) benutzen in fast 100% der Fälle die WordPress mitgelieferte Version. jFancy erweitert somit auch die unter 2.) geladene jQuery Version, wird aber dann per 3.) wieder durch die Version des Themes überschrieben, weshalb dann auch die jFancy nicht mehr da ist.

    Versuch rauszufinden, warum 1,) drin ist und stell das ab.
    Im Theme ersetzt du die jQuery Einbindung mittels eines korrekten wp_enqueue_script() Aufruf, siehe Codex: http://codex.wordpress.org/Function_Refer…_enqueue_script

    Das Problem ist die Ladereihenfolge und das doppelte Laden der gleichen jQuery Bibliothek. Hier die Reihenfolge:

    Code
    .../wordpress/wp-content/themes/Amaris/js/jquery.min.js
    .../wordpress/wp-content/themes/Amaris/js/loopedslider.js
    .../wordpress/wp-content/themes/Amaris/js/custom.js
    .../wordpress/wp-content/themes/Amaris/js/jqueryslidemenu.js
    .../wordpress/wp-content/plugins/nextgen-gallery/shutter/shutter-reloaded.js?ver=1.3.0
    .../wordpress/wp-includes/js/jquery/jquery.js?ver=1.4.2

    Da das Theme zuerst seine Version von jQuery als Erstes laden lässt, "registrieren" sich alle Erweiterungen für jQuery in die Version vom Theme. Zum Abschluß wird dann eine jQuery Version geladen, die WordPress mitbringt (korrekt von NGG programmiert) und überschreibt die zuvor geladene Version. Damit sind alle Erweiterungen nicht mehr in jQuery vorhanden, weswegen es letztlich auch den

    Code
    /*---------- loopedSlider ----------*/
    
    
    jQuery(window).load(function(){
        jQuery("#loopedSlider").loopedSlider({
            autoStart: 5000, 
            slidespeed: 500, 
        });
    });

    loopSlider als Erweiterung nicht mehr gibt, was die Fehlermeldung auch aussagt:

    Code
    jQuery("#loopedSlider").[I][B]loopedSlider [/B][/I]is not a function

    Das Theme sollte jQuery per wp_enqueue_script() direkt von WordPress benutzen, und das Problem ist gegessen. Das sollte man dem Theme Author mitteilen, denn dieser sollte sein Theme schleunigst reparieren.

    Wenn man mal den Aktivierungsprozess abbricht, dann bekommt man den richtigen Text zu Gesicht, den die Aktivierung vermutlich darstellen wollte, aber in neueren WP Versionen anders behandelt:

    Damit dürfte das Plugin nicht kompatibel noch funktionsfähig sein. Da kannst du dich nur an den Plugin Athor wenden.

    Hast du dir mal dein Frontend angesehen, was für eine Seiteninhalt da generiert wird?

    Das ist ein ineinander geschachtelter HTML. Ich befürchte, das irgend ein Plugin das verursacht und auch vor dem Admin Bereich nicht Halt macht. Damit wird ein Plugin-Update nie funktionieren, denn der überflüssige HTML Code wird vermutlich auch bei jedem Ajax Call generiert und führt deine saubere Funktion des Blogs ad absurdum.

    Deaktiviere mal alle Plugins und test danach auch, ob eine Installation eines neuen Plugins geht.

    Fehlerbeschreibung anhand von "Invite Anyone"
    Der Author lädt die Sprachdatei nach eigenem Ermessen und nicht passend zu dem, was für Plugins standard ist:

    PHP
    function invite_anyone_locale_init () {
        $plugin_dir = basename(dirname(__FILE__));
        $locale = get_locale();
        $mofile = WP_PLUGIN_DIR . "/invite-anyone/languages/invite-anyone-$locale.mo";
    
    
          if ( file_exists( $mofile ) )
                  load_textdomain( 'bp-invite-anyone', $mofile );
    }
    add_action ('plugins_loaded', 'invite_anyone_locale_init');


    Anstatt load_plugin_textdomain zu benutzen, wird auch hier der Dateiname selbst konstruiert und mittels load_textdomain geladen. Dies wiederum führt dazu, wie die Warnung meines Plugins bereits aussagt, daß es im Ladeverhalten zu Problemen kommen kann.
    Da der Author außerdem noch die Textdomain im PHP Code so verwendet:

    PHP
    <?php _e( 'name of your website', 'bp-invite-anyone' ) ?>


    wird mein Plugin nur Sprachdateien erzeugen und/oder akzeptieren, die dem Plugin Schema unterliegen, also:

    bp-invite-anyone-de_DE.po
    bzw.
    bp-invite-anyone-de_DE.mo

    Der Author versucht allerdings eine Datei "invite-anyone-de_DE.mo" zu laden, die mein Plugin gar nicht erzeugt.
    Der Ladecode und die Sprachdateinamen müssten angepasst werden, damit das auch dem Standard entspricht. Du kannst das gern anpassen aber teile dies auch dem Author mit, denn Abweichungen von der standardisierten Ladeprozedur für Sprachdateien (Plugin, Themes oder Core) führen meist zu weiteren, nicht einfach zu lösenden Problemen oder Fehlverhalten von WordPress.

    Um Sprachdateien anzulegen, modifizieren und generieren zu können, hab ich für WordPress ein Plugin zur Verfügung gestellt, das über wordpress.org ebenfalls gepflegt wird: http://www.code-styling.de/deutsch/entwic…ng-localization

    Allerdings kann es sein, daß du auch im PHP Code ggf. Anpassungen machen müsstest, wenn die Zusammensetzung der bisherigen Textteile nicht den entspricht, was du final haben möchtest.