Beiträge von Melewo

    Jedoch nicht die Daten von meinem Hoster wo er im Backend neue Benutzer etc. anlegen kann.


    Wie was im Einzelnen abgeht, weiß ich nicht, doch das Backend ist nur über HTTP ein Backend, nicht aber über FTP, da ist es nur ein Verzeichnis wie jedes andere, angefüllt mit Files, die sich ergänzen lassen. So ein Virus wird keine geparsten Dateien aufrufen, sondern den Quellcode verändern. Oder zumindest so ähnlich.

    Nur am Rande bemerkt, derartige Fehler sollten sich ab und an durch eine einfache Typumwandlung beseitigen lassen.

    Beispiel:

    PHP
    $SearchIndex = $response->SearchIndex;
    $bezeichner  = array (...);
    
    
    // Illegaler offset
    $bezeichner[$SearchIndex]; 
    
    
    // Einfache Typumwandlung, kein illegaler offset mehr
    $bezeichner[(string)$SearchIndex]

    Wenn ich allen per MySQL hinzugefügten Seiten (ca. 52.000 Stück) per MySQL-Befehl den post_status auf "inherit" statt "publish" setze, funktioniert Wordpress im Adminbereich wieder tadellos - obwohl die Einträge in der Datenbank sind.


    Da schaue ich bisher genau so wenig durch. Wenn der Fehler nur bei "publish" auftritt, würde es ja bedeuten, dass bei den Aufrufen im Adminbereich alle 52.000 in den Arbeitsspeicher geladen würden.

    Wenn ich nun 268435456 Bytes durch 52.000 Seiten teile und das Ergebnis dann noch einmal durch 1.024 Bytes, komme ich auf etwa 5 kB Content pro Seite, was durchaus eine vorstellbare Größe ergibt. Die Frage ist nur, warum werden alle 52.000 Seiten in den Speicher geladen (falls es denn wirklich so sein sollte, sei angemerkt)?

    Habe mir nur mal die Zeile von der Fehlermitteilung herausgesucht, wobei line von der Version abhängig ist. In post.php on line 606 sehe ich bei Version 3.6 eine Konstruktor-Methode mit $post und einer Schleife. Die Methode wird richtig arbeiten, doch es ist ja eine öffentliche Methode, auf der so ziemlich alles zugreifen kann. Genau da geht mir mein Latein aus, weil ich nicht wissen kann, was $post bei Dir alles enthalten könnte.

    Ist jetzt keine richtige Antwort, die Dir weiterhelfen könnte. Nur, ich habe bisher schon mehrfach etwas von einer Erhöhung des Memory Limits gelesen und kann es leider immer noch nicht so richtig nachvollziehen, da die Datenbank bei einer Abfrage eigentlich nur durchlaufen wird, um dann nur einen einzigen Datensatz mit einigen wenigen kB zuliefern. So eine DB soll angeblich aber locker einige Millionen Datensätze aufnehmen können. Nun frage ich mich, wo die Probleme mit dem Memory Limit dabei entstehen.

    All diese Miniskripte setzen allerdings die die jquery.js voraus - die also zuvor geladen werden muss.

    Was ich persönlich schon immer für Nonsens hielt, statt JavaScript zu lernen, lernen viele nur noch den Umgang mit jQuery. Da wird ein über 90 kB schweres JS-Framework eingebunden, nur für ein paar kleine Aufgaben. Hatte mal etwas geschrieben, um in einem speziellen Fall die Ladezeit zu halbieren und kommt selbstverständlich ohne jQuery aus: Ajax-Parallel-Requests

    Vielleicht kannst Du ja damit etwas anfangen, um Deine Ladezeiten zu verkürzen.

    Bitte wo/wie gebe ich an, dass die jquery "async" geladen werden soll?

    Kann mir nicht vorstellen, dass Du die jQuery-Datei asynchron laden kannst. Erst einmal muss die jQuery ja geladen werden, um im Anschluss, also wenn die jQuery geladen ist, asynchrone Ajax-Request mit jQuery zu realisieren.

    Ob synchron oder asynchron wird beim Öffnen der Verbindung bzw. des XMLHttpRequest-Objektes als dritter Parameter mit true oder false angegeben. Wo da was bei WP oder jQuery zu finden ist, weiß ich hingegen nicht. Wenn, so denke ich, müsste eine Übergabe des Parameters im Zusammenhang mit der Ajax-Funktion erfolgen.

    Und eine CSS sollte nach meiner Meinung immer so schnell wie möglich geladen werden, da diese nicht nur alle Angaben enthält, wie eine Seite dargestellt werden soll, sondern zusätzliche Referenzen auf noch zu ladende Hintergrundgrafiken usw., die mit dem nächsten Schub angefordert werden sollten.

    Habe das noch einmal probiert, Du kopierst aus irgendeiner Ansicht, in der sowohl ein HTML-Tag für einen Zeilenumbruch eingefügt wurde, als auch Steuerzeichen, um diesen Zeilenumbruch darzustellen. Es genügt jedoch, wenn <br /> nicht mit notiert wird, was ja zum Beispiel beim Kopieren von Text aus einem Schreibprogramm auch nicht gemacht wird. Wenn jedoch beim Kopieren und Einfügen Leerzeilen entstehen, einfach entfernen und gut ist es.

    Abgespeichert wird weder <br /> noch </p>, wenn ich das richtig sehe, in den Posts von der DB sehe ich im Augenblick zumindest nur:

    Code
    Eine kleine und schnelle Testseite.\r\n\r\n

    Da könntest Du auch nach einem Plugin zur Einfügung von Quelltext suchen, was <br /> in /n und nicht in /r/n wandelt oder wie auch immer.

    Firebug sowie der Quelltext zeigen auf einmal vom Editor selbst eingefügte <p>-Absätze die so nicht vorgesehen sind.


    Da machst Du irgendwie aus einer Mücke einen Elefanten:

    nur die Zeilenumbrüche müssen korrigiert werden, was ja kein Problem sein sollte.


    Zeilenumbrüche bestehen aus unsichtbaren Steuerzeichen und wenn ein Editor nur \n (für Zeilenumbruch) und ein anderer \r\n (für Zeilenumbruch und Wagenrücklauf) verwendet, ist so etwas vorprogrammiert. Ob es daran liegt, das weiß ich zwar nicht, doch die lassen sich ja nach dem Einfügen in der Textansicht spielend leicht korrigieren.

    Ich wusste doch, dass ich schon einmal versucht hatte eine ähnliche Frage zu beantworten. Musste erst einmal suchen und da keine weitere Rückmeldung mehr kam, weiß ich leider auch nicht, woran es eigentlich lag und wie es weiterging.

    http://forum.wpde.org/installation/1…esterreich.html

    Doch so allgemein, erst einmal die phpinfo abfragen, dann die Datenbank auf Erreichbarkeit testen, würde ich vorschlagen. Wenn da bereits der Wurm drinne stecken sollte, dann den Support vom Hoster kontaktieren.

    Naja...vielleicht ist dein HTML Code auch absoluter Mist und wird deshalb zerschossen..


    <span class="span12">
    <h1>Headline</h1>
    </span>


    Da erzählt mir mein "richtiger" Desktop-Editor doch mal gleich, dass in HTML5 kein H1-Tag etwas in einem span-Tag verloren hat und genau das ist es dann auch, was der TinyMCE als erstes rausfeuert. Alles andere bleibt hingegen bei einem Wechsel der Ansicht oder beim Abspeichern erhalten (falls ich nichts übersehen habe), nur die Zeilenumbrüche müssen korrigiert werden, was ja kein Problem sein sollte. DIVs oder so kommen scheinbar nicht abhanden. Also nur weil der versucht valides HTML abzuspeichern, deshalb soll der schlecht sein?

    Gut, ich weiß nicht, was der Editor von Joomla kann, doch ein JS-Editor ist und bleibt ein JS-Editor und den wirst Du halt nicht mit einem aus der Expression Web Reihe oder einem Dreamweaver vergleichen können.

    Es ist auch nicht richtig, dass derjenige, der eine WPSeite installiert, Ahnung von php haben muss.

    Nein, ist nicht erforderlich, sonst könnte jeder mal gleich sein eigenes CMS entwickeln, in dem er dann jede Codezeile kennen würde. Einige Grundkenntnisse sollen aber vorhanden sein, wenn man in einer PHP-Datei verändernd eingreifen möchte.

    Sorry, jetzt wird es noch komplizierter: was ist ein Inline-Style???

    Inline-Style sind die Angaben, die in einer Linie mit dem Text oder mit den Elementen direkt in einem Dokument oder bei WP halt direkt in einem Artikel notiert werden und nicht in einer CSS-Datei. Siehst Du bei Benutzung der Text-Ansicht im Editor.

    Beispiele:

    HTML
    Möchte nur ein Wort <span style="color: #013d01">farbig</span> hervorheben.
    <p style="text-align: center">Nur dieser Absatz soll mittig ausgereichtet werden</p>

    Ehrlich gesagt finde ich die Styles erdrückend schwer. Wenn bei einer meiner eigenen Seiten eine CSS über 10 kB hinauswuchs, habe ich mir schon ernsthafte Gedanken gemacht. Bei WP wird man jedoch gleich mal von einer 35 kB großen CSS erschlagen. Vermutlich weil der Aufwand sich durch das responsive Webdesign (einen Begriff, den einige Einsteiger zum ersten Mal hören) erhöht. Als ich nach ein oder zwei Wochen dachte, alles Wesentliche angepasst zu haben, stolperte ich erst über die CSS-Datei für IE, in der müssen ebenfalls Änderungen vorgenommen werden, da ja immer noch Besucher mit IE 6 bis 9 unterwegs sind.

    Nun habe ich aber meine ersten Seiten vor 10 Jahren gefertigt, als Einsteiger wäre ich denke ich auch hoffnungslos überfordert.

    In Foren treiben sich aber solche und solche Fragesteller umher, oft habe ich es wirklich schon erlebt, dass einige lieber Fragen in einem Forum stellten, statt die Suche zu benutzen. Ein Forum kann aber immer nur Hilfe zur Selbsthilfe sein.

    kann mir wirklich keiner helfen?
    komme langsam in Zeitnot.


    Du bist hier aber in einem Forum, einige wenige, die sich mit Deinem Problem möglicherweise auskennen, kommen vielleicht erst in den Abendstunden von der Arbeit. Einen Tag später so eine Nachfrage zu stellen, wäre verständlich.

    Also, direkt so etwas wie von Dir geschildert, das ist mir noch nicht passiert. Was mir aber schon mal passierte, das ein älterer Wysiwyg-Editor Bilder nicht richtig erkannte, die ich mit einem neueren Bildbearbeitungsprogramm bearbeitet hatte. Sage nicht, dass es auch bei Dir daran liegt, sage nur, vorstellen könnte ich es mir.

    Was Deine andere Frage betrifft, das ist nicht so einfach bei Deiner Seite. Der Firefox zeigt mir Styles an, die dann aber nicht zu öffnen gehen, ich nehme an durch den Import. Bei anderen Seiten hätte ich einfach mal die Styles geöffnet und im Sandkasten einen Wert verändert.

    Du kannst den größeren Teil allein herausfinden, wenn Du im Firefox Deine Seite öffnest, ein Element mit der Maus markierst und dann Extras->Web-Entwickler->Inspektor aufrufst. Mehr mache ich ja auch nicht. Nur halt bei Deiner Seite öffnet dann nicht die verwendete CSS-Datei.

    Mit den anderen Browsern geht das auch mehr oder weniger, nur etwas mehr Klickerei durch den Dokumentbaum, wie es mir vorkommt.

    Ich hätte in einer Testumgebung einfach mal probiert in der

    /wp-includes/js/jquery/jquery.js

    den Kommentar von 1.10.2 auf 1.9.2 oder so zu ändern. Habe aber keine Ahnung, ob das aus diesem Kommentar ausgewertet wird oder welche sonstigen Auswirkungen das haben könnte. Aus diesem Grund würde ich da immer zuerst einen Test bei einer Installation unter Localhost durchführen, bevor ich was bei einer Installation im Web vermurksen könnte.

    Code
    /*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license
    //@ sourceMappingURL=jquery-1.10.2.min.map
    */

    Ja, dieses Problem haben einige zurzeit. Liegt nicht an jQuery, sondern daran, dass die Versionskontrollen einiger Plugins nicht bis 2 Stellen hinter dem ersten Punkt zählen können. Die vergleichen nur 1.1 ist kleiner als 1.7 und somit veraltet. Die vergleichen aber nicht 1.10 mit 1.7 und somit neuer, darauf sind die nicht eingestellt.

    scheint aber tatsächlich kompiziert. kanonen auf spatzen, quasi! :)

    Na, nicht ganz, zu leicht soll es ja auch nicht sein. Habe mal einen kleinen Anfang fertig gemacht. Nur bei mir gibt es erst zwei Verzeichnisse von zwei Monaten mit nicht mehr als 22 Bildern, die listet es mir erst einmal auf, zusammen mit der Größe der Bilder in kB.

    Abgespeichert im Verzeichnis /wp-content/uploads mit dem Dateinamen bilderliste.php und dann aufgerufen mit "http://www.example.com/wordpress/wp-c…bilderliste.php" mit oder ohne /wordpress, je nach Installation.