Beiträge von Melewo

    Zuweilen wird folgendes im Web empfohlen, nur meisten bringt es nichts, da die Hoster die Vorgaben machen und mehr Memory-Limit in der Regel mit einem Upgrade des Paketes verbunden ist. Einmal beim Support vom Hoster nachfragen und nur zur Info gedacht:

    http://faq.wpde.org/exhausted-php-memory/

    64 MB sehen die meisten hier als Mindestvoraussetzung an, besser sind 128 MB, zumindest dann, wenn mit der Zeit noch das eine oder andere Plugin hinzukommen soll.

    Punkte oder andere Sonderzeichen außer Bindestrich und Unterstrich haben dennoch nichts in einem Dateinamen verloren, da (anders als auf dem Rechner) WP daraus einen Bestandteil für eine gültige URL basteln muss. Und bei einer URL dienen Punkte zur Unterteilung.

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

    [FONT=Helvetica][COLOR=#ff0000]File does not begin with ‚%PDF-'.[/COLOR][/FONT]


    Die Fehlermeldung ist normal und verständlich, da ein PDF-Dokument im Quellcode eigentlich mit %PDF beginnt, zumindest die ich gerade zur Hand habe beginnen so im Inneren.

    Code
    %PDF-1.4
    %âãÏÓ
    312 0 obj 
    <</Linearized ...


    Eine 0 Byte Datei kann aber nichts enthalten, hat ja kein Inneres, was erkannt werden könnte.

    • Memory limit : 268435456 MB

    Was ist das für eine Zahl?
    MB auf keinen Fall, falls Bit, so entspricht es 32 MB, wenn ich mich mit dem Umrechner nicht vertan habe sollte und 32 MB sind mächtig gering für WP.

    Sonderzeichen, die in einem Dateinamen nichts verloren haben,
    zu geringes Memory Limit (ersichtlich in einer phpinfo),
    irgendwelche Datei-Rechte-Fragen und
    fehlerhafte Pfade,

    sind so die allgemeinen Fehlerquellen, würde ich jetzt einmal sagen, was ich hier so seit dem letzten Jahr las. Diese vier Punkte darfst Du nun abarbeiten und was zum Beispiel Windows als Dateinamen schluckt, schluckt WP noch lange nicht.

    Ja, ist richtig, komme nur nicht auf die Idee es einmal mit einer anderen Schreibweise auszuprobieren, es könnte ja dadurch zumindest eine mögliche Fehlerquelle ausgeschlossen werden. Sich Stück für Stück vortasten bringt ja nichts, man hätte ja weniger zu rätseln.

    Vorhanden ist es mit 0 Bytes.

    "http://www.tauchclub-reutlingen.de/wp-content/upl…R-8.3.20141.pdf"

    Was macht WP eigentlich bei einem Upload mit den Punkten in 8.3.20141.pdf?
    Entfernen und in 8320141.pdf oder in 8-3-20141.pdf umwandeln?

    Die Extension bleibt zwar mit PDF, doch wenn ich ein Upload-Script schreiben würde, dann würden die da rausfliegen, weil der umgekehrte Weg mit ein_bild.jpg.exe zumindest in grauer Vorzeit ab und an nur mit ein_bild.jpg in Mail-Anhänge angezeigt wurde (bei der Einstellung Ordneroptionen "Bekannte Dateiendungen ausblenden" oder "Erweiterungen bei bekannten Dateitypen ausblenden"), las ich mal irgendwo, dadurch nur ein_bild.jpg angezeigt wurde und anschließend ein Schadprogramm sein Unwesen trieb.

    Sollte bei WP nicht passieren, denke ich mir, doch vielleicht setzt die WP ja auch gleich auf 0 Bytes, damit so etwas nicht passiert? Ich meine, ich weiß ich nicht, deshalb meine Frage.
    Enthielten die anderen auch Punkte?

    Ja, da werde ich mir wohl auch noch einige anschauen müssen, was es bereits gibt und wie die was gemacht haben. Das mit static hatte ich bei meinem jetzigen Plugin nach einigen Fehlermeldungen mitbekommen. Lässt sich durch Instanziierung umgehen.

    in PHP steht dir dafür md5-file zur Verfügung
    http://www.php.net/manual/de/function.md5-file.php

    man könnte auch die Datei-Größe verwende
    http://www.php.net/manual/de/function.filesize.php


    Habe gerade ein paar kleinere Tests gemacht, weil ich eigentlich bei einem Vergleich auf filesize aus war. Doch wie ich festellte, filesize ist bestechlich, wenn die hinzugefügte Anzahl an Bytes zum Ausgleich zum Beispiel aus Kommentaren entfernt werden würde. md5_file scheint da dann doch die bessere Wahl zu sein, weil da ein verändertes Zeichen im Code genügt, um einen anderen Wert auszuspucken.


    Und beim Rest, werde mal sehen wie es weitergeht, ein Anfang ist ja erst einmal da. Dann halt mit Fallunterscheidungen, sind jetzt wieder nur erste Tests, mehr noch nicht.


    Schreibe gerade noch an einem Plugin, welches ich zuerst fertigstellen wollte. Danach weiß ich noch nicht so genau, was das Leben mit sich bringt, soll heißen, wie es mit der Zeit bestellt sein wird.

    beispiel aus der wp-config.php


    Eigentlich hast Du wohl damit recht:

    PHP
    echo ABSPATH;   // liefert C:\xampp\htdocs\worddreiacht/

    Sollte genügen, wenn der letzte / entfernt wird. Nur was ist, wenn WP nur noch eine weiße Seite hat, dann wird ABSPATH wohl auch nichts mehr liefern. Im Augenblick meldet sich das Script, obwohl nicht eingebunden, was auch ungesund ist. Nun gut, das wird wohl noch einige Wochen oder länger dauern.

    Könnte mir das bislang etwa so vorstellen, dass da zwar eine Seite im Dashboard zugehört, wo dann ein paar Optionen gesetzt werden können, doch wenn die WP Funktionen auf Grund widriger Umstände nicht zur Verfügung stehen, dass das Script dennoch abrufbar bleibt oder so. Dann jedoch nur über einen anderen Schutz, damit es nicht jeder von außen aufrufen kann.

    Für den Privatgebrauch würde es auch genügen, wenn eine "Ohne WP Version" abrufbar auf dem Rechner verbleibt, die nur schnell hochgeladen zu werden braucht. Doch ein Plugin, bei dem die Hälfte auf dem Rechner für den Notfall eingemottet wird, hört sich auch nicht so gut an.

    Es ging mir eigentlich darum, hier liegt das Script bei den Tests,

    C:\xampp\htdocs\example\wordpress\wp-content\plugins\neuer-ordner
    C:\xampp\htdocs\wordpress\wp-content\plugins\test-verzeichnis

    und der Durchlauf sollte hier beginnen (beginnt da nun augenblicklich auch):

    C:\xampp\htdocs\example\wordpress
    C:\xampp\htdocs\wordpress

    Weil das den Root von den beiden entspricht:

    "http://example.localhost"
    "http://localhost/wordpress/"

    Rufe die Datei jetzt aber noch so auf, sind ja nur Tests bislang. Überlege noch, wie ich das mit den Hooks mache. Wenn zu sehr an WP gekoppelt, würde es ja im Ernstfall zusammen mit WP den Dienst quittieren. Liefert nun erst einmal die Dateien als Liste, die in den letzten 24 Stunden bearbeitet wurden.

    Dirname hatte ich in anderen Scripts auch oft verwendet, wüsste jetzt nicht welche Variante oder Funktion die bessere wäre.

    Ja, hat geholfen. Habe 'site_root' in die Suche eingegeben, bin dann zwar nicht direkt bei WP fündig geworden, doch bei Stack Overflow. Das letzte Beispiel auf der Seite liefert site_root, egal wo die Datei liegt, Hauptsache unterhalb von wp- im Beispiel:

    Wordpress - Get root directory?

    Da es jedoch eigentlich ins Plugin-Verzeichnis sollte, habe ich es etwas für einen Test geändert:

    ich habe wirklich viel Zeit und vorallem Geld in "SEO" gesteckt, nur Früchte hatte es nie wirklich getragen...


    Was nicht unbedingt nur an den SEOs gelegen haben muss. SEO hat sich in den letzten Jahren stark gewandelt und eine einzelne Maßnahme, die vor einigen Jahren noch 5 bis 10 Plätze Steigerung eingebracht hätte, kann heute einen Rutsch oder nichts oder eine Steigerung bewirken. Was hilft ist nur ein langfristiges Gesamtkonzept, von dem man keinen kurzfristigen Erfolg erwarten sollte, sondern eher eine Verbesserung übers Jahr gerechnet.

    Auch diese kann dann darauf hinauslaufen, dass kein Boden gewonnen wird, sondern nur kein zusätzlicher oder weiterer Boden verloren wird. In diesem Fall würde der Beauftragende Früchte erwarten, dann den SEOs die Schuld geben, dass die Erwartungen nicht erfüllt wurden. Ohne SEO hätte es aber bereits einen Abfall gegeben, weil SEO in diesem Fall nur darauf hinauslief, die Positionen zu halten, was aber für den Beauftragenden nicht feststellbar ist, denn der sieht nur keine Veränderung. Feststellbar wäre hingegen ein Verlust bzw. ein Abrutschen gewesen, wenn keine SEO-Maßnahmen durchgeführt worden wären.

    Sicherlich, es gibt auch genügend zweifelhafte Angebote, doch dann solltest Du Dir detaillierte Angebote erstellen lassen und eine monatliche Aufstellung, was genau gemacht wurde.

    Hatte mal gestern einen Anfang gemacht, wie ich mir das vorstellen könnte. Gebe das Listing jetzt ohne PHP-Code-Tag ein, damit die Zeilen nicht umgebrochen werden. Statt in zwei nach filetime und filesize sortierte Listen auszugeben, könnte ich mir vorstellen, dass so in einer Tabelle in die DB einzulesen. Dann ein zweites Script um festzustellen, bei welchen Dateien ein Unterschied bei filetime und/oder filesize. Diese dann näher betrachten.

    Wenn die Datei im Plugin-Verzeichnis liegt, erhält man zwar mit Dirname den Pfad bis Plugin, aber nicht den Pfad bis Root, der müsste ja irgendwie eingekürzt werden, damit der Durchlauf ab Root erfolgt. Habe den hier nur manuelle eingefügt, wäre für ein Plugin kein Zustand. Wenn Datei im Root liegt, genügt hingegen ein "." Punkt, statt "C:/xampp/htdocs/wordpress".

    Apache Configuration
    [FONT=verdana]RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC][/FONT]
    
    
     [FONT=verdana]RewriteRule ^(.*)$ - [F,L][/FONT]


    Ich vergesse bei den Request-Methoden den Namen PROPFIND immer wieder und musste erst wieder suchen. Da kamen vor Jahren tausende Aufrufe einzelner Images über PROPFIND im Sekundentakt. Die erreichten zwar nicht viel, versauten mir aber die Statistiken. Seither habe ich es so.

    Apache Configuration
    RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$ [NC]
    RewriteRule .* - [F,NS,L]
    
    
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteCond %{REQUEST_URI} !^/favicon\.ico
    RewriteCond %{REQUEST_URI} !^.*?/feed/
    RewriteRule .* - [F,NS,L]

    Wenn für Favicon keine Ausnahme, wurde es nicht in G WMT in der Übersicht angezeigt. Meine ersten Feed-Reader sendeten noch keinen User Agent, PHP sendet von sich aus keinen mit, selbst als ich bei einem Plugin mit wp_remote_get einen als Option angab, suchte ich nach einem Fehler, bis ich mitbekam, dass ich für getimagesize noch zusätzlich einen mit ini_set(), setzen musste.

    Ohne NS konnte ich mal einen Feed von Verzeichnis A nicht im Verzeichnis B laden. Sollte ich wohl noch einmal überdenken, wo wirklich erforderlich, ebenso bei HEAD, braucht man wohl eigentlich auch kaum.

    Habe ich eigentlich nicht so verstanden. Habe zwar auch noch nicht viel gemacht, doch zum Beispiel genauso wie mit einer rekursiven Funktion die Verzeichnisse durchlaufen werden, um eine XML Sitemap für "normale" HTML-Seiten zu erzeugen, könntest Du bei der Gelegenheit gleich noch nach filemtime sortieren.

    Langsam wird die Angelegenheit erst, wenn dabei viele Dateien noch geöffnet werden sollen, um den Inhalt zu kontrollieren. Da kommen pro 100 Dateien schon einige Sekunden an Laufzeit zusammen. Nur könnte das ja beschränkt werden auf die Dateien, bei denen filetime neuer als die letzte Kontrolle ist.

    Das kann wohl so nichts werden und wie es ausschaut, da solltest Du es wohl lieber bleiben lassen und Dir jemanden suchen, der weiß was er tut. Oder Dich zumindest erst einmal mit dem Aufbau von Formularen befassen:

    http://de.selfhtml.org/html/formulare/

    Dann mit der Absicherung von Eingaben und Daten, bevor Du da weiter machst. Finde jetzt gerade nichts Besseres:

    http://www.web-tuts.de/sichere-formulare-teil-1.html

    Wenn Du damit durch bist, dann könntest Du hiermit weiter machen:

    http://codex.wordpress.org/Function_Reference/get_permalink