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 erstellenWenn man Bilder nicht als Datei, sondern als Inline-Image in eine Webseite einbindet, haben sie keinen Dateinamen. Hier habe ich mal ein Beispiel (das große Bild "Alles Liebe zum Valentinstag" :-))
https://schnurpsel.de/bilder-absichern/
Das hat aber auch einige Nachteile.
Ja, warum sollen die Dateinamen ausgeblendet werden bzw. was genau ist damit gemeint?
Gruß
Ingo
@nische7
So, noch vier Beiträge hier im Blogshow-Forum, dann hast Du es geschafft. :-)
Gruß
Ingo
Aha, interessant.
Liegts vielleicht an der PHP-Version? Bei All-Inkl bekommt man ja immer die zum Zeitpunkt der Bestellung aktuelle Version von PHP und MySQL. Ggf. muß man das dann selber per .htaccess anpassen, was aber möglicherweise andere Nachteile haben kann:
http://all-inkl.com/wichtig/faq/#faq_software
Gruß
Ingo
Schwierig, da habe ich auch erstmal keine Idee.
Habe zum Test bei mir auch mal ein Bild mit 3000x1974 Pixel (hat aber nur 2,2MB) hochgeladen. Es gab keine Probleme.
Gruß
Ingo
Auf den Kategorie-Seiten werden die Artikel scheinbar irgendwie dynamisch Nachgeladen, warum auch immer. Auf den anderen Seiten ist das nicht der Fall. Da wird wohl diese Nachlade-Funktion ein Problem mit dem Zeichensatz haben. Könnte die Funktion eines Plugins oder des Themes sein.
Gruß
Ingo
Meist ist das kein Problem beim Upload selbst, sondern bei der Weiterverarbeitung der Bilder in Wordpress.
Die Ursache ist oft zu wenigig PHP-Speicher, was hier aber eher nicht der Fall sein dürfte. Trotzdem meine Frage, bei welchem Webhoster liegt die Seite?
Ich habe mal die Erfahrung gemacht, das es Probleme beim Upload gibt, wenn im Photoshop die Optionen "Progressiv" bzw. "Optimiert" aktiviert sind. Probier mal, die Problem-Bilder ohne diese Optionen zu speichern und dann erneut hochzuladen.
Gruß
Ingo
Ansich ist die Idee schon gut, Wordpress nicht im Hauptverzeichnis des Webspace zu installieren. Allerdings sollte dann die Domain auf dieses Unterverzeichnis zeigen, so daß es von außen betrachtet eben das Wurzelverzeichnis der Domain ist. Das läßt sich in Kundenmenü des Webhosters einstellen.
Ich gehe meistens so vor:
Gruß
Ingo
Hmmm, wenn ich dem Anmelden-Link oben folge, lande ich ganz normal auf der Installations-Seite von WP.
Gruß
Ingo
Ich finde es erstaunlich, wie oft hier in einem deutschen Forum auf Englisch nach einem Livechat-Plugin gefragt wird:
http://forum.wpde.org/plugins-und-wi…-wordpress.html
http://forum.wpde.org/plugins-und-wi…press-blog.html
http://forum.wpde.org/plugins-und-wi…hat-plugin.html
Ich vermute mal, daß morgen dann wieder ein neu angemeldeter Benutzer mit dem eAssistance Pro um die Ecke kommt. :-)
Gruß
Ingo
Erstaunlicherweise hat bei drei meiner Seiten sogar das automatische Update funktioniert. Das ging bisher überhaupt nicht.
Gruß
Ingo
...
Bei meiner Empfehlung hatte ich folgendes Problem des TS als Grundübel ausgemacht "Wenn ich Wordpress auf die höchste Ebene ("/") hochlade, dann lässt sich install.php nicht aufrufen.". Nur deshalb hat er angefangen Unterverzeichnisse zu verwenden.
Mag ja sein, aber auch hier kann ich nicht erkennen, was das mit der Art der PHP-Konfiguration zu tun hat. Entweder PHP läuft (egal ob als Modul oder CGI) und eine PHP-Datei wird ausgeführt oder PHP läuft gar nicht und dann wird die Datei als Quelltext angezeigt.
Zugegebenermaßen ist die Fehlerbeschreibung "lässt sich install.php nicht aufrufen" aber auch nicht sehr präzise. Im einfachsten Fall war sie einfach nicht vorhanden. Wer weiß...
Gruß
Ingo
...
FastCGI nimmt dem Anwender diese Themen ab, weil PHP im Userkontext läuft...
Und da PHP im Userkontext läuft, hat ein erfolgreicher Angreifer über eine Sicherheitslücke auch gleich schreibenden Zugriff auf alle Dateien des Nutzes, inkl. .htaccess usw.
Man erkauft sich das mehr an Komfort mit einem Verlust an Sicherheit. Zudem ist die Gefahr größer, das sich der Nutzer selbst sein Wordpress abschießt, da er ja nun direkt online an allen Theme- und Plugin-Dateien rumeditieren kann.
Für die Updates habe ich übrigens schon seit längerer Zeit einen Kompromiss gefunden. Ich versetze den Admin-Bereich mit einer .htaccess im /wp-admin/-Verzeichnis temporär nur für diese Zeit in den FastCGI-Modus.
Zudem denke ich, daß es für das Ausgangproblem unerheblich ist, wie PHP läuft. Es ist wohl eher eine Konfigurationsproblem im KAS.
Gruß
Ingo
Bei ALL-INKL musst Du PHP auf FastCGI umstellen. ...
Warum denn das? Mein Wordpress läuft dort schon seit Jahren ganz normal mit PHP als Apache-Modul.
In den FAQ schreibt All-Inkl übrigens:
Bitte beachten Sie, dass bei PHP-CGI strengere Restriktionen für Ressourcen gelten. D.h. Sie sollten ein Umschalten möglichst vermeiden, wenn der Server standardmäßig bereits in der von Ihnen benötigen Version läuft.
Aus meiner Sicht muß da nichts umgestellt werden.
Gruß
Ingo
Robiin
Beim ersten Post den Link vergessen, was? :-)
Gruß
Ingo
Das normale Wordpress lädt die Bilder immer im Original und unverändert hoch und erstellt daraus dann anschließend die Bilder in den anderen Größen (Thumbnail, Beitragsbild usw.). Was aber nicht auszuschließen ist, daß möglicherweise ein Plugin oder das Theme in den Prozeß eingreift und so doch das originale Bild nicht erhalten bleibt.
Gruß
Ingo
Dann liegt es möglicherweise an der Summe des Speicherverbrauchs aller Plugins. Welche und wieviel Plugins hast Du denn installiert?
Es scheint nicht genügend PHP-Speicher für die Bearbeitung des Bildes zur Verfügung zu stehe. Ein Bild mit einer Dateigröße von 4MB hat vielleicht eine Bildgröße von 12 bis 16 MP (MegaPixel). Zur Verarbeitung muß das Bild komplett im PHP-Speicher entpackt werden und belegt dann gut und gerne 40M bis 50M Speicher. Da kann es schon mal eng werden.
Entweder Du verzichtes auf nicht unbedingt notwendige Plugins oder Du verkleinerst die Bilder vor dem Hochladen in der Bildgröße (Breite x Höhe). Letzteres würde ich empfehlen.
Gruß
Ingo
Das könnte daran liegen, daß Dein Hostingpaket nicht das Apache-Modul mod_rewrite unterstütz. Bei welchem Webhoster liegt denn die Seite?
Gruß
Ingo
... Meine Homepage ist auch selbstgehostet aber eben über Wordpress erstellt. ...
Bitte nicht Domainanbieter und Hoster in einen Topf werfen. Das kann zwar derselbe sein, muß es aber nicht.
In Deinem Fall verwendest Du vermutlich eine eigene Domain mit wordpress.com. Damit ist Wordpress.com weiterhin der Hoster und alle Fragen sind dort zu klären.
Gruß
Ingo
Bist Du Dir sicher? Hast Du in der richtigen wp-config.php nachgesehen?
Ich habe es gerade mal bei mir getestet. Wordpress gibt bei der Fehlermeldung den Datenbanknamen exakt so aus, wie er in der wp-config.php steht. Warum auch sollte WP da die Groß- in Kleinschreibung ändern.
Mein Test hat auch ergeben, daß das DB vorne groß geschrieben werden muß, sonst kann die Datenbank nicht ausgewählt werden.
Überprüfe nochmal Deine wp-config.php-Datei.
Gruß
Ingo
Ich bin mir jetzt zwar nicht sicher, ob beim Datenbanknamen Groß-/Kleinschreibung unterschieden wird. Aber bei Strato beginnen die Datanbanken mit einem großen DB. Probier doch mal, ob es mit DB1752258 funktioniert.
Gruß
Ingo
