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?

    Dann versuche ich mal ein wenig fundierte Kritik.

    Die Seite selbst sieht sehr "steril" aus und wenig einladend.

    Die Links der Footerboxen "flattern" sehr und sollten ggf. auf gleiche Höhen angepasst werden, gibt ein besseres Bild.

    Die Fonts für die Links sind alles andere als augenschonend, denn sie werden je nach OS und Browser derbst daneben dargestellt, Beispiel: Anchor Font

    CSS
    Ubuntu Condensed !important;

    Die Farbgebungen sind kontrastarm und für sehbehinderte wenig hilfreich.

    Beim Zoomen der Seite greifen Media Types, die die Seitendarstellung komplett umbauen und anders anordnen. Damit können sehschwache nix anfangen, da sie die Orientierung verlieren, wenn sich die Aufteilung der Seite durch Zoom komplett ändert.

    Deine eigenen Seiten (wie im Impressum verlinkt) machen keinen guten Eindruck, weil sie im Wartungsmode bis September stehen bzw. ein frisches WordPress ohne Inhalt haben.

    In Zusammenfassung würde ich das als ersten Einstieg sehen, es würde mich aber nicht überzeugen.