Beiträge von finno

  • Upload nicht möglich

    Zitat von b3317133

    ...gibt es evtl. bei Strato derzeit auch anderweitige Lastprobleme...


    Da bin ich mal gespannt. Ich bin da aber eher pessimistisch, dass es ein temporäres Problem ist. Hatte das Upload Problem am 27.4. festgestellt, am 29. und 30. keine Besserung. Und übrigens fällt mir da auf, dass ich eigentlich schon immer Probleme mit Uploads bei Strato hatte. Das war allerdings immer nur jede 10. oder 20. Datei. Beim zweiten Upload-Versuch ging es dann immer. Die Fotos kamen bis vor ein paar Tagen auch noch von einem anderen Fotografen und waren etwas kleiner. Ich vermute also stark, dass das Problem schon lange besteht, mir aber jetzt erst aufgefallen ist.

  • Upload nicht möglich

    Ok, Schreibberechtigungen würde ich mal ausschließen. Ich habe gerade nochmal zig Bilder hochgeladen. Alle bis ca 2,5 MB funktionieren, alle größeren nicht. Mit Filezilla gibt es bei Bildern überhaupt keine Probleme, selbst ein 27 MB großes Video konnte ich übertragen.

    Außerdem fiel mir noch ein, dass ich auf einer Subdomain noch eine alte Testumgebung laufen habe. Dort läuft dieselbe Website (mehr oder weniger dieselbe Wordpress Konfiguration) nur ohne Updates seit WP 7.4.5. Das Upload Problem besteht hier auch. Allerdings kann ich hier problemlos alles mögliche testen.

  • Upload nicht möglich

    Danke mensmaximus! Ich habe jetzt auf php 7.2 umgestellt. Soweit ich weiß ist php-fpm aber bei Strato nicht möglich. phpinfo() sagt "Server API: CGI/FastCGI". Mit php-fpm müsste es "FPM/FastCGI" lauten, oder?

    media-new.php gibt weiterhin 408 zurück und wird im Browser geöffnet (wenn ich den Browser-Uploader benutze). Der Inhalt lautet

    Zitat

    Request Timeout
    Server timeout waiting for the HTTP request from the client.

    Selbigen Header und Inhalt gibt, wenn ich den Wordpress-Uploader verwende, die async-upload.php aus. Die media-new.php zeigt in diesem Fall ganz normal das Wordpress Backend an.

    Auch die Rechte für den Upload-Ordner zu ändern hat nichts gebracht. Allerdings habe ich seit heute eine neue Fehlermeldung im Strato Errorlog:

    Code
    30.04.2019 11:08:19 domain.de [client 91.64.38.0] AH01225: Error reading request entity data

    Den Ansatz, dass es um ein Sicherheitsproblem geht, finde ich aber ganz plausibel. Vor allem weil der Upload mit Filezilla funktioniert.

  • Upload nicht möglich

    Zitat von b3317133

    Den angebotenen Download starten, Datei herunterladen, Endung auf .txt ändern oder einfach mit irgendeinem Texteditor öffnen.


    Achso, dann hatte ich mich vielleicht missverständlich ausgedrückt. Das Verhalten mit dem Download trat gestern früh 2 oder 3 mal auf. Danach nicht mehr. Es gibt sogar eine Fortschrittsanzeige für den Upload, die bis 100% läuft. Danach ist aber die Datei nicht auf dem Server und Chrome meldet 408 für die media-new.php.

    Ich war nur neugierig, wie ein solches Script aussehen könnte. Deshalb die Idee, nochmal etwas nachzuhelfen, damit ich es runterladen kann.

  • Upload nicht möglich

    Zitat von b3317133


    Funktioniert der Upload mit einem Standardtheme wie Twenty Nineteen und allen Plugins deaktiviert?


    Leider immernoch ein Timeout.

    Zitat von b3317133


    Das würde mich sehr wundern, denn dann wäre PHP auf dem Server nicht aktiv.


    Hmm, man lernt ja nie aus. Könnte ich nicht irgendwie testen, was dann ausgegeben wird? Könnte ich nicht irgendwo in der media-new.php ein paar Zeilen einbauen, die den Browser zum Download der Datei zwingen?

    PHP
    $file_name = 'media-new.php';
$file_url = 'http://domain.de/wp-admin/media-new.php';
header('Content-Type: application/x-httpd-php');
header("Content-Transfer-Encoding: Binary");
header("Content-disposition: attachment; filename=\"".$file_name."\"");
readfile($file_url);
    Zitat von b3317133


    Ist evtl. der Punkt "Sicherheit -> ServerSide Security" bei Strato aktiv?


    Is nich.

  • Upload nicht möglich

    Zitat von b3317133

    Link zu einer solchen Beispieldatei?


    https://abload.de/img/img_3637lrjo9.jpg

    Zitat von b3317133


    Funktioniert der Upload mit einem Standardtheme wie Twenty Nineteen und allen Plugins deaktiviert?


    Das probiere ich heute Nacht aus. Aber, wie gesagt: Das Plugin Health Check simuliert eigentlich genau diesen Fall. Der Upload hat in diesem sogen. Problembehandlungsmodus nicht funktioniert.

    Zitat von b3317133


    Wieviel Platz ist auf dem Server frei?


    105 GB

    Zitat von b3317133


    Was steht in diesem Fall in der Browser-Console im Netzwerk-Tab als Server-Antwort? Nur der 408 Header und leerer Inhalt?


    Der genaue Response Header:

    HTTP
    HTTP/1.1 408 Request Timeout
Date: Mon, 29 Apr 2019 13:30:57 GMT
Server: Apache/2.4.39 (Unix)
Content-Length: 221
Connection: close
Content-Type: text/html; charset=iso-8859-1


    Der Inhalt:

    HTML
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>408 Request Timeout</title>
</head><body>
<h1>Request Timeout</h1>
<p>Server timeout waiting for the HTTP request from the client.</p>
</body></html>
    Zitat von b3317133


    Was steht in dieser Datei, wenn Du sie runterlädst?


    Habe den Download gar nicht gestartet. Falls es nochmal vorkommen sollte, schau ich mal in die Datei. Mich würde aber wundern, wenn das nicht die Original Datei wäre, wie man sie auch bei wordpress.org findet.

  • Upload nicht möglich

    Hallo!

    Ich versuche ein Problem mit dem Media Upload zu lösen und bin langsam mit meinem Latein am Ende.

    Die Symptome:

    • Bilder (ich habe bisher nur jpg probiert) lassen sich nicht über die Uploadfunktion hochladen

    Meine Lösungsansätze:

    • Browser-Uploader, Wordpress-Uploader und die Einfügefunktion im Editor probiert, nix geht
    • FTP-Client funktioniert aber!
    • Kleine Dateien (ich habe <1MB probiert) machen keine Probleme
    • Eine Datei, die sich nicht hochladen ließ, ließ sich in einer anderen WP-Installation (anderer Server) problemlos hochladen
    • Es ist noch genug Speicherplatz auf dem Server frei
    • Ich kann mich an keine Wordpress-Konfiguration erinnern, die das Problem ausgelöst haben könnte. WP-Core und Plugins waren total veraltet als das Problem plötzlich auftrat. Nun ist alles upgedatet, aber keine Besserung.
    • Ich habe zwischen php 7.0, 7.1 und 7.3 hin- und hergeschaltet und dabei "PHP Boost" (einen Service von Strato) ein- und ausgeschaltet -> nix passiert
    • Konfiguration von php scheint (für mich) normal (max_execution_time: 300, memory_limit: 256M, upload_max_filesize: 64M)
    • Mit Hilfe des Plugins Health Check kann man eine Installation ohne Plugins und mit Standard-Theme simulieren. Das Ergebnis: Auch ohne Plugins ist kein Upload möglich


    Fehlermeldungen:

    • Wenn ich ein Bild direkt über den Gutenberg-Editor hochladen möchte wird diese Meldung ausgegeben: "Die Antwort ist keine gültige JSON-Antwort."
    • Chrome Dev Tools zeigt mir dabei für die Datei /wp-json/wp/v2/media?_locale=user im Header einen Status "408 Request Timeout"
    • Denselben Statuscode gibt /wp-admin/media-new.php zurück, wenn ich den Browser-Uploader verwende (kurioserweise wurde aber auch manchmal die Datei media-new.php zum Download angeboten sobald ich auf den "hochladen"-Button geklickt hatte)
    • Benutzt man den Wordpress Uploader wird der 408 von /wp-admin/async-upload.php zurückgegeben
    • Der Errorlog von Strato gibt diese Zeilen aus:
    Code
    29.04.2019 12:29:03 domain.de [client 91.64.38.0] FastCGI: comm with server "/home/strato/http/fastcgi/rid/63/82/52576382/htdocs/wp-admin/async-upload.php" aborted: write failed
29.04.2019 12:29:10 domain.de [client 91.64.38.0] FastCGI: "/home/strato/http/fastcgi/rid/63/82/52576382/htdocs/wp-admin/async-upload.php" aborted: incomplete headers (0 bytes) received from server after 19 sec

    Wer weiß Rat?

  • Relaunch Strategie

    Zitat von b3317133

    Wenn man alle Dateien in einen neuen Ordner kopiert, die Datenbank in eine neue Datenbank kopiert, dann den Plesk-WordPress-kram löscht, die Domain auf den neuen Ornder setzte und die Datei wp-config.php dort auf die neue Datenbank anpasst, wäre man diese Plesk-Probleme los.

    Wenn man denn wollen würde. Wie gesagt, viel Erfolg. Bin hier raus.


    Kein Problem. Danke b3317133!

    Kann mir dann jemand anderes sagen, um welche "Probleme" es hier überhaupt geht? Datenbank und Dateien mit einem Klick zu synchronisieren klingt für mich immernoch viel einfacher. Die Prozedur mit Duplicator und Search & Replace habe ich selbst schon durch und so ganz ohne ist das auch nicht. Zumindest wenn man es nicht regelmäßig macht und sich immer wieder einlesen muss.

  • Relaunch Strategie

    Zitat von r23

    Nur auf einer Maschine entwicklen ist unpraktisch und widerspricht dem gelebten Open Source Workflow bei uns.


    Auch wenn's nicht ganz der Kern dieses Threads ist - gib mir mal Nachhilfe. Warum unpraktisch? Warum entgegen dem Open Source Workflow?

    Zitat von r23

    Plesk verwendet und [size=24]empfiehlt [size=14]WordPress Toolkit[/SIZE][/SIZE]

    [size=24][size=14][/SIZE][/SIZE]
    [size=24][size=14]Das Toolkit läuft ja bei mir. Ich seh da jetzt immernoch kein Argument dagegen...[/SIZE][/SIZE]

  • Relaunch Strategie

    @b3317133
    Nein! Genau das spricht FÜR Plesk. Zumindest in meiner Situation (wenn Wordpress nicht manuell installiert wurde). Wie schon gesagt, kann ich nämlich das Basisverzeichis nicht ändern, was wiederum heißt, ich kann deine Methode so nicht umsetzen.

    Eine weitere Idee, um bei Problemen weiter dieses Forum bemühen zu können, wäre:

    • Klon erstellen (Duplicator)
    • Entwickeln und Testen
    • Wordpress via Plesk deinstallieren, um dann die Domain auf ein anderes Basisverzeichnis umschalten zu können

  • Relaunch Strategie

    Zitat von r23

    Ich würde auch einem Anfänger ein Server-Staging fehlen.

    [size=18]Server-Staging für Einsteiger
    https://t3n.de/news/server-staging-wordpress-597583/[/SIZE]

    Wenn ich den verlinkten Artikel richtig verstanden habe, macht die dort vorgestellte Staging-Lösung nur Sinn, wenn man mit min 3 Instanzen arbeitet. Bei mir ist "Entwickeln" und "Präsentieren beim Kunden" dieselbe WP-Installation (auf demselben Server, wie die Live-Version).


    Zitat von b3317133

    Alleine schon dieser eine Punkt ist bzgl. Plesk ein "no-go" bzw. nicht nachvollziehbar für mich, ob das wirklich so der Fall ist:


    Ja, keine Chance! Wenn Wordpress über Plesk installiert wurde kann das Basisverzeichnis nicht mehr geändert werden.

    Zitat von b3317133

    Das über Plesk zu machen, halte ich für sehr ambitioniert. Viel Erfolg.


    Was genau spricht gegen Plesk? Google mal "wordpress staging guide". Es wird regelmäßig empfohlen, die Staging-Lösung des Hosters zu nutzen. Die Vorteile sind zB

    • kein runter- und hochladen nötig
    • Datenbank und Subdomain wird automatisch erstellt
    • kein editieren der wp-config.php nötig (glaube ich zumindest)
    • Wiederherstellungspunkt wird automatisch erstellt
    • statt FTP-Client, Editor, phpMyAdmin, Wordpress und Webhosting Panel dürfte nur eine einzige Oberfläche nötig sein
    Zitat von b3317133

    Die von mir beschriebene Variante zielt darauf ab, dass man jederzeit einen Rollback zum Original machen kann, ... weil das Original unangetastet bleibt.

    Der Restore-Point erfüllt denselben Zweck.

    Ich finde auch das Mapping der Domains irgendwie eleganter. Aber da das bei mir ohnehin nicht geht, werde ich wohl der Plesk-Klon-Methode mal eine Chance geben.

  • Relaunch Strategie

    Hallo b3317133,

    das klingt vernünftig. Vor allem weil es relativ sicher sein sollte. Dass Wordpress aus Plesk heraus installiert wurde (von meinem Vorgänger) hat mir auch erstmal Sorgen gemacht. Habe aber gerade entdeckt, dass Plesk da ein paar ziemlich nützliche Funktionen bietet. Nämlich Klonen, Synchronisieren und Wiederherstellen einer Wordpress Instanz. Der werden zB auch gleich Tabellenpräfixe angepasst uvm (vgl). Ich denke ich werde es so machen:

    • Klon erstellen (mit Plesk)
    • Bearbeitungen am Klon dokumentieren
    • Kurz vor dem Relaunch via Plesk synchronisieren mit Klon als Ziel(!) und Originalseite als Quelle(!) (dabei werden aber nur neu erstellte Dateien synchr. - vor allem Bilder)
    • Beim Relaunch (nachts) alle Dateien synchronisieren mit Klon als Quelle und Original als Ziel (diesmal geänderte Dateien auf Ziel ersetzen und auf Quelle fehlende löschen)
    • Die zu synchronisierenden Tabellen manuell auswählen


    Den Zwischenschritt mit dem 2. Klon würde ich mir sparen, weil alles, was im 1. Klon funktioniert im Original ja auch funktionieren sollte (bleibt natürlich ein Restrisiko wegen inzwischen evtl upgedateten Plugins). Außerdem macht es mir immernoch Kopfschmerzen, dass ich Wordpress erst im laufenden Betrieb deinstallieren muss, bevor ich die Domain umschalten kann.

  • Relaunch Strategie

    Da ich mit einer großen Website betraut wurde, muss(!) der Relauch möglichst reibungslos ablaufen. Genauer geht es dabei um

    • Erstellung eines Child-Themes
    • Zahlreiche Einstellungen in Wordpress (Menüs, Permalinks uvm)
    • Abschalten und Neuinstallieren von Plugins
    • Ersetzen von (zu großen) Bilddateien
    • ...


    Zum testen werde ich einen Klon der Website auf einer Subdomain installieren. Und während ich die neue Website erstelle, werden auf der alten weiter Inhalte veröffentlicht. Möglicherweise auch Nutzerprofile geändert, gelöscht oder neu angelegt und irgendwelche Plugins mit Daten gefüttert.

    Meine Frage ist jetzt: Wie bringe ich am Ende beide Seiten zusammen?

    1. Spät in der Nacht alle Dateien im Webspace austauschen.

    2. Beim Webhoster das Basisverzeichnis der Domain auf dasjenige, in welchem die Testumgebung läuft, ändern (um das Basisverzeichnis in Plesk ändern zu können muss ich jedoch erst Wordpress deinstallieren).

    In beiden Fällen frage ich mich, wie ich mit der Datenbank vorgehen soll. Hier wurden ja in der Zwischenzeit beide Seiten editiert.

    Kennt jemand ein gutes Tutorial? Nichts, was ich bisher zum WP-Relaunch gelesen habe, berücksichtigt, dass während der Entwicklungszeit auch auf der alten Seite weiter gearbeitet wird.

    Grazie, Merci, Thanks und recht herzlichen Dank an alle!

  • Problem nach Änderung der URL

    Mann verdammt! Danke @b33 für den Tipp mit der .htaccess!

    Und recht hattet ihr auch mit dem Hinweis auf die regelmäßig gestellte Frage ;-)

    Nach anpassen der htaccess und einem Eintrag in der functions.php läuft wieder alles:

    PHP
    update_option( 'siteurl', 'http://example.com' );
update_option( 'home', 'http://example.com' );

    vgl hier.

    Problem gelöst, danke euch und schönes Wochenende!

  • Problem nach Änderung der URL

    Hallo,

    ich hoffe, ich kann mein Problem präzise beschreiben. ...schauen wir mal ;-)

    Vor ein paar Tagen habe ich WP komplett neu installiert unter html/http://www.domain.de/wordpress auf dem Server. Und alles lief gut. Da ich die Seite erst in Ruhe anlegen wollte, habe ich das /wordpress in der URL belassen. D.h. der Blog war vorerst unter https://www.domain.de/wordpress erreichbar.


    Das erste Problem trat auf, als ich eine Seite veröffentlicht habe und sie sich anschließend nicht aufrufen ließ. Es stellte sich heraus, dass WP die .htaccess nicht beschreiben konnte (Besitzer und Gruppe waren unterschiedlich). Ich glaube, ich hatte sie dann einfach via ftp gelöscht und eine neue mit gleichem Inhalt hochgeladen. Besitzer, Gruppe und Rechte stimmten dann jedenfalls und ich konnte wieder Seiten veröffentlichen und aufrufen.

    Jetzt aber zum eigentlichen Problem: Nachdem ich in den Einstellungen -> allgemein die Wordpress-Adresse in https://www.domain.de (statt https://domain.de/wordpress) geändert habe geht gar nichts mehr (evtl habe ich das "s" im https auch vergessen, kann ich jetzt aber nicht mehr nachvollziehen). Wenn ich die Seite oder das Backend aufrufen will, kommt nur noch ein "500 Internal Server Error".

    Ich habe inzwischen die Weiterleitungen beim Webhoster angepasst: domain.de -> /http://www.domain.de/wordpress und http://www.domain.de -> /http://www.domain.de/wordpress

    Habe außerdem testweise eine index.html ins Verzeichnis /domain.de/wordpress gelegt und die .htaccess von Wordpress gelöscht. Da ich die index.html mit dem Browser aufrufen konnte, würde ich das Problem jetzt bei Wordpress sehen. Muss ich da noch irgendwo den Pfad anpassen? Wenn ja, muss ich da an die Datenbank? Ins Backend komme ich ja nicht mehr. Die .htaccess liegt jetzt übrigens wieder in /http://www.domain.de/wordpress und sieht so aus:

    Apache Configuration
    # BEGIN WordPress<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [
</IfModule>
# END WordPress

    Was kann ich da noch machen (außer neu installieren)?

    lg finno

  • page.php gibt nichts mehr aus nach falschem Gebrauch von post_password_required()

    Hallo,

    manchmal füge ich testweise eine Zeile Code ein und mache es im Fehlerfall Sekunden später rückgängig. Scheinbar sollte man wohl nicht alles so leichtfertig ausprobieren.

    Um zu verhindern, dass auf meiner Website die Thumbnails von passwortgeschützen Childpages in einer Übersicht erscheinen, habe ich in der loop-page.php folgende Zeile ersetzt:

    alt:

    PHP
    while ( $the_query->have_posts() ) : $the_query->the_post();


    neu:

    PHP
    while ( $the_query->have_posts()  & ! post_password_required()) : $the_query->the_post();

    Kann der falsche UND Operator das verursacht haben? Oder der falsche Gebrauch von post_password_required() ? Und warum kann ich es nicht rückgängig machen?

    Mit error reporting in php kenn ich mich nicht so aus. Konnte jetzt auf die Schnelle nichts finden. Ich les noch mal etwas...

    Gruß Finno

  • Fehlermeldung bei Formularen (Pflichtfelder)

    Also das lag wohl daran, dass die Fehlermeldungen per Javascript erzeugt wurden (jQuery Validation Plugin). Mittels .mo und .po Dateien wird meines Wissens nur php Code übersetzt. Jedenfalls hält das jQuery Validation Plugin auch eigene Übersetzungen der Fehlermeldungen in js-Sprachdateien bereit. Diese fehlen aber in dem Plugin, in dem das jQuery Validation Plugin verbaut ist, nämlich Strong Testimonials. Verbessert mich gerne, falls ich da falsch liege. Zumindest hat sich mein Problem erledigt, indem ich die fehlenden deutschen Javascript Sprachdateien eingefügt habe.