Beiträge von codestyling

    Kann es sein, dass PHP bei dir nicht mit dem FTP Nutzer ausgeführt wird sondern z.B. mit "www-run"?
    Dann bekommt das Zipfile u.U. die falschen Rechte und kann dann nicht ausgepackt werden.

    Weiterhin ist es auch möglich, das PHP für sämtliche Inputs ggf. so konfiguriert ist, dass es automatisch Dateiinhalte escaped. Dann wäre die Datei durch einen Automatischen Download kaputt und kann auch nicht entpackt werden.

    Das Handling von Sprachdateien bei Themes kann unterschiedlich sein. Relativ neu ist, dass diese im Ordner /wp-content/languages/themes/ sein müssen und die textdomain im Namen vorangestellt werden muss: also, in diesem Fall etwa avada-de_DE.po und entsprechend auch .mo


    Ja, das ist mir bekannt, kann aber derzeit nicht mit den Versionen 1.x meines Plugins benutzt werden. Allerdings arbeite ich, sowie ich ein Krümelchen Zeit übrig habe, weiter an Version 2.0, die sowohl Backup als auch den Support aus anderen Ordnern unterstützen wird.
    Momentan kann man das lösen, indem man die *.po/*.mo in das entsprechende Verzeichnis des Themes/Plugins verschiebt. Bei Themes muß man es dann zusätzlich umbenennen in z.B. "de_DE.mo"

    Gabe den Fehler mal, da hat wordpress.org fehlerhafte Plugins/Theme *.zip files per download ausgeliefert.
    Kann auch passieren, wenn das zip beim Speichern auf deinem Server korrumpiert wird oder eine Länge von 0 bekommt, weil es nicht geschrieben werden kann.
    Sind die *.zip auf nach Installation und/oder Upload ok, wenn du die per FTP runterlädts und prüfst?

    Für ein 64bit System und WP3.5 ist das zu wenig, wenn Plugins laufen.
    Folgende Werte sind für WP grobe Minimum Richtwerte, wenn man vernünftig arbeiten will:

    OS Platform Plugin Erweiterungen Standard WP 3.5 Multisite WP 3.5
    32bit wenig 48M 64M
    32bit viel 64M 80M
    64bit wenig 70M 128M
    64bit viel 128M 128M

    Das sind Erfahrungswerte und schwanken stark, je nachdem, wie der Provider die entsprechenden OS konfiguriert hat. Es kann auch mit weniger gehen, aber 40M sind für WP 3.5 teilweise viel zu wenig.

    Ein lokaler Patch eines Plugins, der beim Update verloren geht, ist eigentlich großer Mist.
    Deswegen löst man sowas auch auf die dafür vorgesehene Weise, wenn der Pluginautor es nicht selbst noch besser macht.

    Für TinyMCE Einstellungen gibt es einen Filter, den man dafür benutzen kann. Folgender Code macht das, was dein Patch auch macht. Man kann das entweder in die functions.php deines Theme hinzufügen (dann ist es vom aktuellen Theme abhängig oder packt die paar Zeilen in ein Miniplugin und aktiviert das.

    PHP
    function change_tinymce_date_button_formats($params) {
        if (isset($params['plugin_insertdate_dateFormat'])) 
            $params['plugin_insertdate_dateFormat'] = '%d. %B %Y';
        if (isset($params['plugin_insertdate_timeFormat'])) 
            $params['plugin_insertdate_timeFormat'] = '%H:%M Uhr';
        return $params;
     }
     add_filter('tiny_mce_before_init', 'change_tinymce_date_button_formats', 20);

    Normalerweise hat das der Pluginauthor aber zu handhaben und per Sprachdatei anpassbar zu gestalten. Das würde dann im Plugincode so aussehen müssen:

    Code
    $initArray['plugin_insertdate_dateFormat'] = [B][COLOR=#ff0000]_x('%B %d, %Y', 'Ultra TinyMCE - Date Format', 'jwl-ultimate-tinymce')[/COLOR][/B];  // added for inserttimedate proper format
        $initArray['plugin_insertdate_timeFormat'] = [COLOR=#ff0000][B]_x('%I:%M:%S %p', 'Ultra TinyMCE - Time Format', 'jwl-ultimate-tinymce')[/B][/COLOR];  // added for inserttimedate proper format


    Hätte der Autor das so eingebaut, dann könnte man den Formatter leicht per Sprachdatei ändern und hätte je nach Backendsprache immer die richtige Ausgabe.

    Müsste sich in einem template befinden, das den Content baut bzw. einer der loop templates.

    PHP
    <div id="before-content"><p>&nbsp;</p></div> 	<div id="main">div id=		<div id="container"> 			<div id="content" role="main"> 			   			<div class="entry-actions">								<div class="timestamp">

    Aktuell ist die Version 1.99.29 mit einer Menge Anpassungen für einige Bugs. Unter anderem was bis 1.99.29 eine .htaccess Datei im Plugin Ordner, welche aber auf manchen Systemen zum Absturz führte bzw. ein Update verhinderte.
    Kannst du bitte mal das Plugin auf dem Webspace per FTP (ganzen Ordner) löschen und dann vom Repo die 1.99.29 installieren?


    Ein Problem dieser Art mit meinem Plugin ist mir noch nie begegnet. Im aktivierten Zustand ohne auf die Pluginseite zu gehen, verbraucht das Plugin minimale Resourcen und Speicher.

    Welche Version der Plugins setzt du ein?
    Welche PHP Version ist bei dir beim Provider aktiv?
    Ist das ein Apache (linux) basierter Server oder Windows IIS basiert?
    Hat der Provider dein Möglichkeiten limitiert?

    Für einige spezielle Seiten wird in deiner style.css des Themes die Sidebar richtig gesetzt, zum Beispiel auf der Home Seite, weil dort das primary Area richtig positioniert wird:

    Code
    .home #primary {    
     float: left;     
    margin: 0 -26.4% 0 0;     
    width: 100%;     
    background-color: #ffffff; 
    }


    Offensichtlich wird hier selektiv gearbeitet, d.h. das nicht jede Art der Ansicht mit Sidebar vorgesehen ist.
    Wenn jede Ansicht eine Sidebar haben soll, dann reicht diese Änderung:

    Code
    #primary {    
     float: left;     
    margin: 0 -26.4% 0 0;     
    width: 100%;     
    background-color: #ffffff; 
    }


    Ansonsten muß du dir die entsprechenden Ansichten aufrufen, in denen das nicht stimmt und die entsprechende body class genauso definieren wie die body class für home Seite.