Beiträge von Melewo

    Die verhält sich nicht viel anders als ein normaler Funktionsaufruf. Mal eine einfache Testfunktion, dann ein einfacher Funktionsaufruf, danach einer mit dieser call_user_func_array Funktion. Die Ausgabe unterscheidet sich nicht. Einen Unterschied würde ich mal darin sehen, dass die Argumente als Array übergeben werden können.

    Das nutzt Dir nur nicht viel, praktisch nichts eigentlich.

    Was macht das [COLOR=#333333]call_user_func_array eigentlich?[/COLOR]


    Ich habe damit noch nichts programmiert und englischsprachige Texte im Translater verstehe ich immer erst (halbwegs) richtig, nachdem ich die zugehörigen Beispiele selbst getestet habe.

    Jedenfalls die restlichen Fehler werden nur darauf beruhen, dass PHP eine Warnung wegen call_user_func_array() rauswirft, nehme ich mal an. Zu call_user_func_array und WP lassen sich zwar einige Hinweise finden, doch die lesen sich teilweise reichlich abenteuerlich.

    Das ist nicht meine, dass ist die von Version 3.7 und 3.7.1, die Fehlermitteilung und die Zeile 406 stimmen nur bis Version 3.6.1 überein.

    Nun ja, mal unabhängig von der Version, hatte mal eine Liste mit Dateien gefunden, die besonders anfällig für Leerzeilen usw. waren, nur finde ich die gerade nicht wieder. Wenn ich mich richtig erinnern sollte, so hat auch schon einmal Schadcode in der index.php von WP so einen Fehler ausgelöst.

    Wenn Du in den letzten Tagen davor keine Datei bearbeitet hast, könnte es zumindest nicht schaden, mal per FTP nachzuschauen, ob da eine Datei ab dem Auftreten des Fehlers aktualisiert wurde. Durch die Verzeichnisse klicken und nach Datum sortieren und mal schauen, ob sich etwas zu erkennen gibt. Falls ja, Deine Site für den Zugriff aus dem Web sperren.

    Falls Plugins vorhanden, alle durch umbenennen des Plugin-Verzeichnisses deaktivieren, falls der Fehler dadurch beseitigt, eins nach dem anderen wieder aktivieren, wäre auch noch eine Möglichkeit.

    Jetzt bin ich durcheinander gekommen, hatte im IE, Chrome und FF getestet und der Chrome hat mir statt 'container' in der CSS einfach 'Behälter' angezeigt, als automatisch übersetzte Version. Da ich mit dem Chrome selten arbeite, wusste ich nicht, dass der eine CSS eigenmächtig übersetzt. Deshalb war mein letzter Post praktisch Unfug mit den Umlauten.

    Na ja, Du hast die Namen geändert und möglicherweise hatte der IE noch die CSS mit den alten Namen im Cache. Ich würde nicht unbedingt Namen mit Umlauten verwenden, weil Umlaute oft zu Problemen führen, wenn eine Datei unter einem Zeichensatz bearbeitet und gespeichert wird, unter einem anderen jedoch verarbeitet. Doch da zumindest kein Fehler im IE und FF bei mir zu sehen war, kannst Du die wohl auch so lassen. Doch wenn Du noch einmal so etwas machen möchtest, schreibe dann lieber Behaelter.

    Der Dokumentanbau wird ja durch JavaScript mit aufgebaut, wie es scheint und die Seite wird erst geladen, wie sie ist, dann erst JavaScript ausgeführt. Da kann es schon einmal für Bruchteile einer Sekunde flackern. Die Frage wäre somit nicht ob, sondern wie sich das am günstigsten so gestalten ließe, dass es nicht ins Auge fällt. Nur eine Lösung aus dem Stegreif kenne ich da auch nicht, weil ich nicht weiß, wie da was ineinander greift.

    Nicht nur die Sicherheitsschlüssel, auch DB_NAME und DB_USER sowie $table_prefix (falls geändert) würde ich für mich behalten. DB_NAME und DB_USER herauszubekommen, wird sicherlich für einen Hacker, der es nur auf Deine Seiten abgesehen hat, kein Problem darstellen, doch für Tools einen Mehraufwand bedeuten, wenn diese zusätzlich noch unterschiedliche Ziffern durchlaufen müssen. Je weniger bekannt, umso besser.

    Liegt Deine Installation in einem Verzeichnis oder im Root?
    Dann müsstest Du das Verzeichnis mit angeben, Beispiel:

    "http://www.destic.de/liesmich.html"
    "http://www.destic.de/wordpress/liesmich.html"

    Für strukturierte Daten gibt es ja auch nichts besseres, hier mal als Beispiel eine Seite von Google mit zwei Tabellen.

    HTML
    <table>
      <tr><th>Robots.txt URL</th><th>Valid for</th><th>Not valid for</th><th>Comments</th></tr>
        ... 
        ...


    https://developers.google.com/webmasters/con…ts_txt?hl=de-DE

    Nur bei einer Webseite mit ansonsten responsiven Design sollte man sich gegebenenfalls zusätzlich noch etwas einfallen lassen, da Zellen nicht einfach umbrechen.

    Zuweilen liegt es an einer falschen Position. Also zuerst die Rewrite Engine mit on einschalten, dann die Konditionen und Regeln für eine Weiterleitung und dann erst die Konditionen und Regeln für WP. Ich würde es zumindest in dieser Reihenfolge schreiben:

    Wenn es denn nicht nur am .com\.de liegt, hatte ich zuerst glatt mitkopiert, weil übersehen.

    Beispiel zur Verwendung: Datei ABC im Verzeichnis htdocs/ unter dem Namen abc.php abspeichern und im Browser mit "http://localhost/abc.php" aufrufen.

    Kopieren und unter abc.php speichern:

    Rufe "http://localhost/phpmyadmin/" auf, klicke auf Dantenbanken, unter "Neue Datenbank anlegen" tippst Du imnovember ein, bei Kollation lässt Du es wie es ist oder wählst UTF-8 aus.

    Anschließend suchst Du innnerhalb von htdocs/wordpress/ nach der Datei wp-config-sample.php und füllst diese nach besten Wissen und Gewissen aus, der Name Deiner Datenbank ist nun "imnovember", der berechtigte User ist "root", Passwort kann leer bleiben, falls Du keins vergeben hast und der Host, den kennst Du bereits als "localhost".

    Ist halt diese 5-Minuten-Installation.

    Dafür reicht es aber auch schon, ein Leerzeichen zu markieren


    Ist mir auch erst heute so richtig aufgefallen, dass allein die Position des Cursors nicht genügt. Dann sollte ich wohl meinen doch noch einmal weiterentwickeln. War ja nur ein Übungsobjekt, doch der versteht ja beinahe mehr, zumindest fügt der einen Link ein, wo sich gerade der Cursor befindet.

    http://www.seo-welten.de/webcoding/wysi/wysiwyg-editor-7.htm

    Der Editor basiert auf JavaScript und ist somit von den verwendeten Browsern abhängig und von den Nutzereinstellungen. Im Allgemeinen sollte es dabei keine Probleme geben. Wenn dann doch vereinzelt Probleme auftreten, dann kann können diese Fehler gegebenfalls nur im Browser des jeweiligen Benutzers auftreten, so dass sich das nur schwer nachvollziehen lässt. Eine Fehlersuche von extern ist dadurch zuweilen nicht möglich.

    Treten diese Fehler häufiger auf, also bei mehr als zwei Benutzern, dann könnte es sich auch um einen Fehler handeln, der am Script liegt. Dennoch, der Editor wird von WP nur benutzt, angepasst, also integriert, jedoch praktisch nicht entwickelt oder nur in einem gewissen Umfang mit weiterentwickelt.

    http://de.wikipedia.org/wiki/TinyMCE