Beiträge von codestyling

  • Beitrag veröffentlichen Problem und noch ein Problem [..]

    Irgendwas stimmt nicht mit deiner Domain. Deine Seiten enden aprupt immer so:

    PHP
    </div>
<!-- CLOSE sidebar-->
<div class="clear"></div>
<center>This Blog was made with  L O V E
<br>
<br></center>
    <script src="http://layer-ads.de/la-11423-subid:p113261.js" type="text/javascript"></script>


    Entweder modifiziert dein Hoster deine Seiten-Ausgabe mit seinen unsäglichen Werbe-Popups und macht dadurch deine Seite kaputt, oder du hast einen alte WP per Update auf WP 2.6 gebracht und einen "Trojaner mit genommen". Das kann ich so nicht beurteilen.

  • WordPress - gettext / unpack Fehler - Ursache gefunden

    Nach langer und intensiver Recherche, Tests und vielen grauen Haaren mehr, hab ich endlich den Schuldigen gefunden, der das verursacht:

    Code
    Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\streams.php on line 66
Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\wp-db.php on line 359

    Eine Ausführliche Beschreibung hab ich bereitgestellt unter: Code Styling Project » WordPress Fehler durch Sprachdateien - die Ursache
    Das Problem lässt sich auch auch ohne Patch beheben, jedoch kann eine andere Domain in Shared Hosting Systemen (die mit auf deinem Server läuft) deine Domain "abschießen". Ich hab versucht, das so einfach wie möglich zu erklären und Lösungen angeboten.

  • Probleme mit Firefox und tinyMCE-Editor

    Zitat von marX

    Nur so ins Blaue geraten. 2.6 hat ja jetzt "Google Gear" an Bord, vielleicht blockt NoScript ja das und es gibt Probleme. Ich würde NoScript für WP und alle verwendeten Scripte jedenfalls deaktivieren. Sonst sind mir keine Probleme mit WP 2.6 bekannt, ich hab erst vor wenigen Tagen ein paar neue FAQ-Beiträge mit FF3 geschrieben.


    Hast du evtl. auch direkte Links zu den FF3 FAQ's, denn ich finde keine und würd mir die mal ansehen wollen :D

  • Probleme mit Firefox und tinyMCE-Editor

    Java != JavaScript, wollen wir erstmal festhalten. WordPress braucht nur ein einem Browser, der JavaScript fähg ist, Java ist nicht nötig. Im FireFox 2.0.0.16 geht auch alles einwandfrei. Da ich selbst noch nicht auf Firefox 3 umgestiegen bin, kann ich nicht sagen, ob der evtl. Probleme hat.
    Einige Probleme können mit den Javascript Bibliotheken auftreten (jQuery/Prototype etc.), wenn dort nicht Besonderheiten bestimmter Browser berücksichtigt wurden. In den meisten JavaScript-Bibliotheken gibt es kistenweise Code, der für Opera, Safari, IE und Fox was anderes macht. Es ist gut möglich, das die Script-Interpretation im FF3 etwas geringfügig anders macht als der FF2 und somit geht es dann nicht mehr. Alle JavaScripts, die WP2.6 beigelegt sind, wurden im Rückblick zu WP2.5.1 auf den neuesten Stand gebracht (alle eine höhere Version jetzt). Somit ist eine Inkompatibilität nicht auszuschließen.

    Ich würde folgendes zu Testzwecken vorschlagen:

    1. Benutz mal einen FireFox 2.x und teste ob es geht (bei mir ok)
    2. Deaktiviere mal das NoScript Plugin und teste dann.

    Wenn allein die Benutzung von FF2 reicht aber FF3 nicht geht, dann müsste man rausfinden, welches Script "spinnt" und den Autor des Scripts benachrichtigen bzw. dort nachlesen, ob es schon einen Patch gibt.
    Wenn es an NoScript liegt, dann solltest du es besser konfigurieren.

  • Fehlermeldung

    Leider nicht Geschichte, denn wenn du ein @ davor machts und es trotzdem nicht geht, den include_path zu setzen, dann unterdrückst du nur die Ausgabe der Fehlermeldung!
    Und die restlichen Dateien können nicht geladen und gefunden werden, denn WP 2.6 bringt alles mit, wie ich schon dachte. Nur muß der Pfad auch zu setzen gehen, damit WP seine mitgebrachten Unterordner und Dateien erreichen kann!

    Also hast du nix weiter gekonnt, als eine Fehlermeldung zu unterdrücken aber dann weiterhin Code ausführen zu lassen, der beliebige Fehler macht und ggf. ganz abbricht und zufällige Ergebnisse liefert.

    Werte in der .htaccess für php setzen:

    Code
    php_value include_path "korrekter voller Pfad"

    Allerdings mußt du alle bisherigen Pfade aufnehmen, die momentan aktive sind und den von der Funktion benötigten noch anfügen.
    Besser den Provider fragen, oder umprogrammieren .

    Oder aber (hab 2.6 immer noch nicht installiert aber daliegen) man kann das Revisionsfeature in den Einstellungen abschalten. Dann wird der Textdiff nicht benutzt (soweit ich mich an die WP Ankündigungen erinnere). Dann könnte es auch funktionieren.

  • Fehlermeldung

    Es scheint auf abgesicherten Providern ini_set() verboten ein Problem mit der TextDiff Implementierung zu geben, denn der neue Code aus WP 2.6 sieht so aus (wp-includes/pluggable.php):

    Es wird versucht, den include_path temporär zu setzen (wird weiter unten wieder hergestellt), was aber einige Provider nichtzulassen ! Somit bekommt man dann auch die Probleme und Fehlermeldungen aus dem Eingangsbeitrag. Ich denke, hierfür gibt es 3 Lösungsansätze:

    1. Den Provider um Freigabe der ini_set() Funktion bitten.
    2. versuchen, die betroffenen ini Werte per .htaccess Datei zu setzen
    3. Alle betroffenen Dateien des Bereiches wp-includes/Text so patchen, dass es immer funktioniert.

    Punkt 3 ist eigentlich Sache des WP Core Teams und hätte auch vor Freigabe mal simpel getestet werden können, Punkt 2 kann man ohne Garantie (und wenig Hoffnung) probieren und Punkt 1 wird vermutlich nicht durchführbar sein, denn nicht viele Provider lassen in diesem Punkt mit sich reden.

    Hat jemand Lust, den Patch zu programmieren? Würde auch unterstützend tätig werden :)

  • Deutsche Sprache für wp-ban 1.31, wie einstellen?

    Ich greif mal folgenden code von oben auf:

    Code
    ### Create Text Domain For Translation
add_action('init', 'ban_textdomain');
function ban_textdomain() {
    if ([COLOR=Red][B]![/B][/COLOR]function_exists('[COLOR=Red][B]wp_print_styles[/B][/COLOR]')) {
        load_plugin_textdomain('wp-ban', 'wp-content/plugins/wp-ban');  //<-- alles kleiner WP 2.6
    } else {
        load_plugin_textdomain('wp-ban', false, 'wp-ban');  //<-- WP 2.6 Fall
    }
}

    Da hat der Autor ? teilweise mitgedacht und an WP 2.6 anpassen wollen ([COLOR=Red]rot markiert[/COLOR]). Die Funktion wp_print_styles gibt es erst ab WP 2.6 somit wird mit diesem if entschieden, ob der Blog schon 2.6 oder niedriger ist. Also ein auskommentieren ist sicher nicht die beste Wahl, eine Korrektur ist angemessener.
    Da ich selbst noch keine Zeit hatte, die WP 2.6 zu installieren (liegt nur ausgepackt in einem deaktivierten, lokalen vhost rum), kann ich noch nicht viel zur Arbeitsweise der erweiterten load_plugin_textdomain Funktion sagen. Die schau ich mir aber später noch an.

    Ergänzungen:

    Die Sprachdatei für diese Plugin muß, um es nochmal eindeutig und exakt zu sagen, "wp-ban-de_DE.mo" für deutsch heißen und im wp-ban Ordner liegen.
    Desweiteren muß in der wp-config.php folgendes drinstehen:

    PHP
    define ('WPLANG', 'de_DE');

    Dann sollte die Übersetzung auch geladen werden, denn die WP 2.6 Funktion ist intern so definiert:

  • außergewöhnliche Schriftarten verwenden--Hilfe

    Ich werd mal hier antworten, auch wenn du dich durch mehrere Threads mit der selben Frage gerade durchwühlst :)
    WordPress betreibt ein (X)HTML konformes Konzept was Webseiten betrifft. Deshalb wird auch strikt darauf geachtet, das Inhalt und Darstellung voneinander getrennt sind. Der Inhalt (also das was du eingibst im Editor) kannst du per Themes in HTML auszeichnen. Das gibt dem ganzen Struktur aber noch kein Aussehen. Deshalb wird zu den php Dateien, die das Theme bilden im Theme Ordner immer auch eine Stylesheet Datei (style.css) liegen, die beschreibt, wie und wo die einzelnen HTML Auszeichnungen samt deiner Inhalte zu präsentieren sind. Diese Stylesheet Dateien enthalten dann die Angaben zu Fonts, Größen, Farben, Bildern, Positionen etc.
    Du solltest dich mit dem, was hinter HTML und CSS steht, näher beschäftigen, denn WordPress ist trotzdem keine Textverarbeitung nur weil Word im Namen vorkommt. SELFHTML 8.1.2 (HTML-Dateien selbst erstellen)

  • WP 2.5.1 - Problem mit "Seiten"

    Das liegt an der Art der Seitengestaltung. Du hast alles, was im body ist entweder mit relative oder absolute aus dem Fluss des body rausgenommen, so dass dann natürlich height: 101% nicht helfen kann.
    Da müsste man sich ein anderes Designkonzept ausdenken, oder der Kunde lebt damit, das im FF der Sprung drin möglich ist.

    Und was den IE betrifft, fliegt mir MooTools 1.11 mit TypeConflict um die Ohren. Von MooTools gibt es aktuell v1.2, mag sein dass die korrekt geht. Ohne funktionierendes Moo kann man nicht sagen, wie es aussieht.

  • WP 2.5.1 - Problem mit "Seiten"

    Zitat von diltigug

    Hi,
    ich habe ziemlich sicher genau das selbe Problem. Braucht der Content mehr Platz als der Bildschirm bietet, kommt es zu dem Ruck nach links.:-?
    Nur die genannte Lösung zeigt bei mir keine Lösung, trotz Cache löschen und Seite neu laden.
    Gibt es sonst noch einen Grund, der zu dem Verhalten führen kann?


    Sogar mehrere:

    1. Du hast massive JavaScript Fehler im IE7, wer weis was die Scripts in anderen Browsern machen.
    2. Die Seite hat ca. 70 HTML Fehler: [Invalid] Markup Validation of http://www.janimnetz.de/ - W3C Markup Validator

    Bevor du das nicht repariert hast, kann man nix fundiert dazu sagen.