Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenNein, das hat WordPress selbst garantiert nicht dahin geschrieben. Entweder hat das Theme eine eigene Optionsseite, in der du den Pfad eingetragen hast, oder du hast den falschen Optionspfad bei einem Import mit hineingetragen.
Suche mal nach »Inetpub« in der ganzen DB, wechsle das Theme und schalte alle Plugins ab. Tritt der Fehler dann immer noch auf?
Ich betreibe eine Website mit dem Tarif »Privat«; alles Folgende bezieht sich darauf und kann von »Privat Plus« abweichen.
1. Mir scheint die Testinstallation ohne Caching, z.Bsp. bei Aufruf des Backends sehr langsam im Vergleich zu Kontent. Da interessiert mich ob das beim gekauften Webspace dann wesentlich anders ist (Privat Plus wäre der Tarif bei All-Inkl, den ich nehmen würde). Klar verwende ich WP Super Cache. Läuft auch in der Testinstallation von All-Inkl.
Standardmäßig fehlt in meinem Paket mod_headers, deshalb funktioniert WP Super Cache nicht ohne weiteres. Kann bei dir aber anders sein. Frag nach.
Mit dem Tempo des Backends bin ich eigentlich zufrieden. Nicht gerade rasend schnell, aber auch nicht zu langsam. Ich benutze allerdings weniger Plugins.
2. Bei Kontent habe ich 67MB PHP Mem. Limit, bei der All-Inkl Testinstallation 64MB. Was mich nun irritiert ist, dass bei Kontent für meine Webseite 47MB verbraucht wird, bei All-Inkl 57MB. Beim Überschreiten des Limits läuft nichts mehr. Kann man von All-Inkl zus. Mem bekommen ?
Der Speicherverbrauch bei PHP ist sehr von der aktuellen Version abhängig. Manche Versionen füllen den Speicher bei Stringoperationen (Hauptarbeit in WordPress) besonders schnell.
Bei mir läuft PHP 5.2.10, und ich habe 20.09 MB Speicherverbrauch. Vielleicht betreibst du ein sehr gieriges Plugin, oder deine PHP-Version ist zu alt. Frag den Support.
3. Bei Kontent gehen alle Autoupdates von WP und Plugins reibungslos und schnell. Bei der WP 2.9 Testinst. auf All-Inkl langsam und mit der nervigen Zugangsdaten Abfrage. Ich meine gelesen zu haben, dass man das mit Einträgen in .htaccess in wp-admin abstellen kann. Versucht habe ich es nicht. Weiss jemand ob das geht ?
Das sollte gehen, wenn du PHP im Adminverzeichnis als Fast-CGI betreibst. Habe ich aber nicht probiert. Die Forumssuche verrät dir, wie das geht.
4. Beim (ziemlich kargen) KIS von All-Inkl fehlt mir ein Dateimanager mit dem man schnell mal direkt Dateiänderungen im Webspace machen kann. Da gibt es wohl nichts oder ?
Nein, All-Inkl bietet nichts an. Du kannst dir aber einen eigenen in ein passwortgeschütztes Verzeichnis legen. Freie Skripte dafür gibt es ja zuhauf.
5. Geht das POP3 Mailing in All-Inkl ?
Ja, kein Problem. Das Webinterface ist sehr spartanisch; ich benutze es nur, wenn es gar nichts anders geht.
Zur letzten Frage kann ich dir nichts sagen.
Bemerkenswert gut ist bei All-Inkl der Support. Sehr schnell und hilfreich, auch mitten in der Nacht und am Wochenende.
Gruß
Thomas
Du hast eine Volltextsuche nach »upload« durchgeführt? Steht nichts in der Tabelle »options« unter »upload_path« oder »upload_url_path«? Dann muß ich passen.
Logge dich mal in deine Datenbankverwaltung ein, und sieh nach.
Da steht entweder nichts drin, oder der absolute Pfad. Sieh mal in der wp-config.php nach, ob du da noch etwas eingestellt hast.
RedirectMatch benutzt mod_alias, nicht mod_rewrite. Das ist der einzige Unterschied. Mod_alias steht meist auch dann zur Verfügung, wenn der Hoster mod_rewrite (dämlicherweise) deaktiviert hat.
Wenn du die Umleitung mit dem Statuscode 301 vollziehst, verlieren die Seiten nicht im Ranking.
Beispiel mit einer Umleitung für [FONT="Courier New"]/foo.html[/FONT] und [FONT="Courier New"]/bar.html[/FONT]:
RedirectMatch Permanent ^/(foo|bar)\.html$ http://example.com/$1/Sieh im Errorlog deines Servers nach, was da schief läuft. Zur Not hilft dir da dein Hoster weiter.
Und probiere mal, jeweils nur eine Zeile des Codes einzugeben, bis du weißt, welche das Problem auslöst.
Wenn du beides hast, findet sich bestimmt eine Lösung.
Funktioniert hervorragend, auch mit den Permalinks für Tags und Kategorien. Offizieller wird das derzeit nicht. Wozu auch?
Wie kann ein Anker die Darstellung beeinflussen? Das ist doch bloß ein HTML-Attribut. Konkretes Beispiel?
Oh, das sehe ich jetzt erst richtig, sorry. Da mußt du den Pfad unter »Einstellungen/Verschiedenes« anpassen.
Das ist nicht merkwürdig, sondern normal. Wie sollte ein Browser denn sonst einen Button darstellen? Mit CSS (border, background) kannst du das leicht anpassen.
n den Meisten Fällen wird in die PHP s ein Code eingefügt der so in der Art
PHP<?php /**/eval(base64_decode('aWYoZnVuY3Rpb25fZX.....
anfängt er ist in jeder PHP datei zufinden das ist der eigentliche schlüssel zum finden des eigentlichen übeltäters
Nein, das ist nur das Resultat. Die wirklich gefährlichen Sachen sehen bei Weitem nicht so trivial aus.
Danke an das Team von PHP.de
Weil hier wird man ja leider allein gelassen.
Was haben die Betreiber der Seite php.de mit der Sicherheit deiner Website zu tun? Dafür bist nur du verantwortlich, niemand sonst.
Eine Totallöschung wer das beste aber meist nicht möglich
Was man meistens nicht komplett löschen kann, ist die Datenbank. Alles andere stellt man aus sicheren Backups wieder her, oder man bezieht es direkt von der Quelle. Das ist der Normalfall.
auch die php3 php4 datin html datein prüfen hab den code auch schon da drin gesehen
Normalerweise wird richtig böser Schadcode nicht in Dateien mit der Endung php(3|4|5) versteckt, sondern in vermeintlichen Bildern wie ›harmlos.png‹. Die müssen alle vor dem Weiderverwenden gründlich geprüft werden, sonst fängt man zwei Wochen später von vorne an.
Naja, dann schreib es doch einfach um:
<button><img src="/images/button.gif" alt="Suchen" /></button>Und die komplette .htaccess. Da sitzt die kaputte »Hotlinksperre« vermutlich.
Und wie du vorausgesagt hast, wird dadurch das Leerzeichen in Quelltext entfernt.
Sehr schön. Gib dem Autor bitte Bescheid.
habe ich bei der Accesslog einfach die Endung .gz in .txt umgewandelt. Damit kann ich dann die Datei im Editor ansehen.
Seltsam, da wurde die Datei offenbar nicht verpackt, sondern nur mit einer falschen Endung versehen.
Nur hilft mir dies nicht viel. Ich sehe nur eine Ansammlung von endlosen Zeilen:
Das sieht zunächst etwas seltsam aus, ist aber eine sehr nützliche Sammlung von Informationen.
Das Logformat im Webserver Apache sieht meistens so aus:
%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"Beispiel
Die Zeile …
mnhm-4d01aed3.pool.mediaways.net
- -
[30/Nov/2009:01:00:57 +0100]
"GET /2009/php-magic-quotes-entfernen/
HTTP/1.1"
200
5160
"http://toscho.de/2009/trennung-inhalt-layout/"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)"
… die ich hier mal der Übersicht halber umgebrochen habe, sagt mir:
Vom Host mnhm-4d01aed3.pool.mediaways.net aus wurde von jemandem, der sich nicht authentifiziert hat (- -) auf meine Seite zugegriffen.
Datum und Zeit stehen in den eckigen Klammern, die Methode war GET (POST und HEAD sind auch üblich, DELETE, PUT und TRACE eher nicht).
Dann kommt die angeforderte Ressource. Die sagt dir bei einem Fehler, welche URL da eigentlich kaputt ist. Wenn die am Ende ein [FONT="Courier New"]%20[/FONT] hat, dann hat jemand die falsch interpretierte »Canonical URL« angefordert.
Oft steckt auch feindlicher Code in der URL.
Dahinter steht das Protokoll, hier HTTP 1.1. Yahoo beispielsweise kann das immer noch nicht und benutzt 1.0 – Schande!
Der Statuscode lautete 200 (Gefunden); das ist die häufigste Antwort. 404 hieße: Nicht gefunden, 410: Für immer weg. Die 500er sind Serverfehler. Du findest also alle 404er, wenn du nach [FONT="Courier New"][Leerzeichen]404[Leerzeichen][/FONT] suchst.
Die nächste Zahl gibt die Menge der übertragenen Bytes an, hier 5160.
Dann kommt der Referer, die Seite, von der aus der Zugriff erfolgt ist. Sehr wichtig, wenn jemand woanders einen kaputten Link auf deine Seite gesetzt hat: Du kannst ihn dann anschreiben, und ihm genau sagen, wo er den Link reparieren möge. Einige Leute senden den Referer nicht mit, andere packen feindlichen Code hinein … das ist also nicht unbedingt eine vertrauenswürdige Quelle.
Zum Schluß noch der User-Agent (UA), ein Browser oder Crawler. Auch gerne gefälscht, vergiftet oder unterdrückt.
Spannende und wichtige Informationen also. Ab und zu solltest du einen Blick hinein werfen, denn nur so siehst du beispielsweise, ob ein durchgeknallter Crawler deine Ressourcen vergeudet.
So hatte ich oft einen UA mit der Kennung Java/1.6.0_04 im Logfile, der viermal pro Stunde sämtliche Feeds (auch die der einzelnen Artikel) abgeholt hat. Alles legale Zugriffe, die in keinem Fehlerbericht auftauchen, aber in der Masse eine ziemliche Zumutung.
Durch die regelmäßige Logfile-Analyse ist der mir immer wieder aufgefallen, und irgendwann habe ich ihn ausgesperrt mit einem Eintrag in der .htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !/greedy\.html
RewriteCond %{HTTP_USER_AGENT} ^Java/1\.\d [NC]
RewriteRule ^ /greedy.html [L,R=301]Die greedy.html hat 145 Bytes und ist eine einfache, statische HTML-Seite. Darin steht, warum ich das mache, und wer sich daran stört, kann ja mit einem richtigen Browser auf meine Seite kommen und mich anschreiben. Hat noch keiner gemacht. 
Im Kontrollpanell meines Webhosters habe ich dann unter den Statistiken für den Monat Dezember 2009 unter anderem folgendes gefunden:
Naja, das ist hübsch bunt und einfach, unterschlägt aber die wichtigen Details.
Fast 3% 404er finde ich ganz schön viel. Darum solltest du dich kümmern.
Sehr wohl habe ich aber folgenden ähnlichen Code-Schnipsel im Quelltext meines Wordpress-Plugins All in One SEO Pack gefunden […]
Aha. Dann schreib mal in die [FONT="Courier New"]functions.php[/FONT] deines Themes diese Zeile:
add_filter('aioseop_canonical_url', 'trim');Das sollte das Leerzeichen entfernen. Wenn es so ist, schick dem Plugin-Autor den Link auf diese Diskussion; sicher möchte er das übernehmen.
Die Datei access-2009120521-2009121921.log.gz kann ich mit 7-Zip leider auch nicht öffnen.
Was passiert denn, wenn du es versuchst? Ich habe mit diesem Programm selbst schon gearbeitet. Es kann ganz sicher Gzip-Archive öffnen. Die entpackte Datei kannst du mit jedem Texteditor ansehen.
In Filezilla sieht 775 so aus: http://img.toscho.de/screenshots/so…a-chmod-775.png
Vielleicht läuft PHP auf deinem Server als anonymer User und braucht 777, oder es kann generell keine Verzeichnisse anlegen. Dann (und auch sonst) wäre es besser, PHP in dieselbe Gruppe zu stecken, in der auch der Webserver läuft. Das hätte den Vorteil, daß du deine Dateien nicht mehr für jedermann als beschreibbar kennzeichnen mußt.
Diese Einstellung nimmst du entweder im Backend deines Hosters vor, oder du fragst den Support mal freundlich.
Es gibt keinen naheliegenden Grund, weshalb das Suchformular das Kommentieren beeinflußt. Eventuell fehlt dem ersten Formular das schließende </form>, aber sonst kann man ohne ein konkretes Beispiel nichts mehr dazu sagen.