@ danielgoehr
Du meinst das?
# Allow access to wp-admin/admin-ajax.php
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
Ja, genau ![]()
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 erstellen@ danielgoehr
Du meinst das?
# Allow access to wp-admin/admin-ajax.php
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
Ja, genau ![]()
Localhost-Installationen sind für die Lösung von Problemen keine gute Idee... Und solange auf einem Localhost gebastelt wird, ist es letztlich ziemlich egal, ob eine Installation funktioniert oder nicht.
Um das etwas zu ergänzen... (Es ist tatsächlich ein bisschen missverständlich geschrieben).
Es spricht natürlich ganz nichts dagegen, dass du mit deiner Website erstmal lokal arbeitest. Es ist nur ausgesprochen schwierig für uns, Tipps zu geben oder Fehler zu finden, wenn wir keinen Zugriff auf die Seite haben.
Auch wenn du schreibst, wie das Theme heißt, werden es vermutlich die wenigsten kennen und dir auf Anhieb helfen können...
Das ist einfach ein Fehler. Du schreibst ja, dass sie nicht gelöscht werden, obwohl du sie gelöscht hast.
Das Problem ist aber (und das ist jetzt nicht böse gemeint):
Wenn dich das Löschen der Themes per FTP überfordert, wird dich die Fehlersuche und Fehlerbehebung auf jeden Fall auch überfordern.
Insofern würde ich sagen, entweder du lebst damit oder (wenn es dich sehr stört) such dir einen Dienstleister, der dich unterstützt (z.B. hier im Jobforum).
Gibts noch andere Möglichkeiten?
Du kannst die Themes einfach per FTP löschen.
Die Themes liegen im Verzeichnis "wp-content/themes".
Warum? "10 Zeichen"
Weil alle Ajax Requests in WordPress über die Datei "admin-ajax.php" laufen (nicht nur die, die den Admin-Bereich betreffen, sondern tatsächlich alle).
In vielen Fällen kein Problem, ich hab aber selbst schon Seiten mit den eigenartigsten Fehlern gehabt, die am Ende genau daran lagen.
https://www.wordfence.com/blog/2014/05/p…-for-wordpress/
Edit:
Hier noch die offizielle Doku (da steht es auch nochmal drin, wenn auch nicht so explizit):
https://codex.wordpress.org/Brute_Force_Attacks
Und sichere wp-admin durch einen zusätzliche Passwortabfrage mit der .htaccess Datei ab.
Denk and das whitelisting der "wp-admin/admin-ajax.php". ![]()
oder die API URL hat sich geändert.
Das hatte ich auch vermutet wegen des "connection refused. Ein direkter Aufruf der URL klappt aber."
Aber nochmal: Wenn es ein Premium Plugin ist, wende dich doch mal an den Support. Der kennt sein eigenes Plugin ja am besten und kann vielleicht am ehesten helfen...
Das was du machen möchtest ist im Prinzip ein Umzug, auch wenn du bei dem gleichen Hoster bleibst.
Du musst natürlich in dem Fall keine Dateien kopieren oder die Datenbank ex- oder importieren. Aber du musst trotzdem in der Datenbank alle Verweise auf deine alte Domain auf die neue ändern. Das geht z.B. mit dem Plugin "Better Search Replace".
Danach sollte normalerweise alles ok sein.
Noch kurz für dich zum Verständnis:
WordPress braucht immer genau eine Hauptdomain. Du kannst zwar beliebig viele Domains weiterleiten, es gibt am Ende aber eben immer nur eine Domain, mit der dein WordPress "läuft".
Das Plugin, importiert alle Fahrzeugdaten von mobile.de via API auf die Website.
Seit kurzem funktioniert das nicht mehr korrekt. Ich habe nichts an WP geändert.
Wie heißt denn das Plugin?
Ich finde nur Premium Plugins, die sowas machen. In dem Fall könntest du ja mal den Support kontaktieren.
Hallo Daniel,
das würde dann bedeuten, dass diese Ausdrücke je nach Browser(einstellung) auf Deutsch oder Englisch sind? Das wäre aber eigentlich eine gute Nachricht, denn die Kunden sind ja außerhalb Deutschlands (z.B. USA) und würden es dann richtig angezeigt bekommen.
Genau, also ich würde im Moment davon ausgehen, dass die Sprache von der Browsersprache abhängt.
Ok, das wäre ja quasi die zweite Version in ausführlich beschrieben ![]()
Ist bei shared Hosting auch kein Problem.
Auf Verzeichnisse oberhalb des Web-Root zugreifen? Klar, technisch ist das kein Problem. Mir ist nur kein Anbieter bekannt der das erlauben würde...
Oder meinst du die andere Variante? Also alles Domains nur auf Verzeichnisse unterhalb des Web-Root "legen"?
Vielleicht bin ich auf der falschen Fährte, weil ich das Tool nicht kenne (und es ja auch keinen Link zur Seite gibt).
Aber der https Tester liefert folgenden Fehler:
Zitat
http_request_failed
Warum denn eigentlich http_request und nicht https_request? Mixed content?
Abgesehen davon ist mir aber auch noch nicht ganz klar, was der Zusammenhang zwischen "Plugin geht nicht mehr", einem Testergebnis von HTTPS Tester und einem absoluten Pfad ist.
Ich glaube, es wäre nützlich zu wissen, um welches Plugin es sich handelt, was das Fehlerbild ist und seit wann es auftritt.
Wo nimmst du denn das her?
Das habe ich tatsächlich auch noch nie gehört. Mir ist auch noch nicht ganz klar, inwiefern das sicherer sein soll.
Es sei denn, man legt die wp-config in ein Verzeichnis, dass von aussen nicht erreichbar ist. Wobei mir nicht ganz klar ist, wie WordPress dann darauf zugreifen soll (oder geht das trotzdem?).
Das wäre aber eh nur eine Lösung für einen eigenen Root-Server. Bei Shared Hosting hat man ja eigentlich nie Zugriff auf Verzeichnisse oberhalb des Webroot.
das Auslagern von wp-config.php u.ä. aus dem "public_html" Ordner des Users, da dieser bzw. die Config-Datei von anderen Usern auf dem gleichen Server per PHP lesbar war.
Das höre ich auch zum ersten Mal und ich hoffe, dass das auch in der Vergangenheit nie so war. Das wäre ja die ultimative Sicherheitslücke!
Das ist auf jeden Fall keine Standard-Funktion.
Jenachdem wie gut deine PHP Kenntnisse sind, könntest du dir aber etwas basteln...
Das hier sieht z.B. nach einem ganz viel versprechendem Ansatz aus:
Ich glaub du hast recht. Kläre das morgen mit dem Kunden
Es gibt einen Kunden? Heißt das, du bist Dienstleister und wirst dafür bezahlt?
Danke für den Tipp, hat leider nicht geholfen, das memory limit kann dennoch nicht über 92 erhöht werden.
Du wirst nicht drumherum kommen, dein Hosting-Paket upzugraden...
Deine neue Datenbank unterstützt keine FULLTEXT Indizes.
Das kann z.b. an der verwendeten Engine oder der mySQL Version liegen. Ohne weitere Informationen ist das schwer zu sagen.
Da du "Providerwechsel" schreibst, nehme ich an, du hast ein Webhosting-Paket? Wenn ja, kannst du daran vermutlich nicht viel ändern (zumindest nicht du selbst). Kontaktiere am besten mal den Support...
Interessanter ist, daß keinerlei Einträge - für keines der beiden fehlgeschlagenen updates - in der error_log angelegt werden.
Leider also keinerlei aufschlußreiche Infos.
Das ist tatsächlich merkwürdig. Irgendwas scheint doch da im Hintergrund schief zu gehen. Du könntest auch mal während des Updates in die Webkonsole gucken. Vielleicht lässt sich da ein Hinweis entdecken.
Steht denn in der error.log wirklich gar nichts drin oder nur nichts zu dem konkreten Problem? Eine komplett leere Error.log Datei habe ich (fast) noch nie gesehen. Irgendwelche Warnings stehen da eigentlich so gut wie immer drin.
Manchmal hilft das manuelle Update auch solche Probleme zu lösen. Insofern würde ich in dem Fall vielleicht einfach wirklich manuell updaten und beim nächsten Mal wieder das automatische versuchen...