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 erstellenZitat von BitpalastEs wurde ein anderer Server verwendet, nicht nur eine andere Festplatte.
...
Die spürbare Performance-Verbesserung ist aber in erster Linie der SSD zu verdanken, weniger dem neuen Server. Oder anders gesagt, ein neuer Server mit herkömmlicher Festplatte hätte nicht diesen Geschwindigkeitszuwachs bewirkt.
Gruß
Ingo
Zitat von BitpalastSSD: Wird zwar als Gerücht immer weiter und weiter verbreitet, ist aber falsch...
Kann man so pauschal aber auch wieder nicht sagen.
Bei einem meiner Projekte, was allerdings kein Wordpress ist, hat der Umzug der Datenbank auf einen Server mit SSD eine deutlich spürbare Performance-Verbesserung gebracht. Es hängt also, wie so oft, vom konkreten Anwendungsfall ab. Ein Allheilmittel ist die SSD aber nicht, das stimmt schon.
Gruß
Ingo
Würde ich so nicht machen. Weil wenn du die Seite http://www.linkzurwebseite.de/seite1/seite2/seite3/ aufrufst und dort ein link mit /seite1/seite2/seite3/ gesetzt ist kommst du auf http://www.linkzurwebseite.de/seite1/seite2/…/seite2/seite3/
...
Das stimmt so nicht.
Wenn ein Link mit dem Schrägstrich beginnt, bezieht er sich immer auf die Wurzel, also auf die Domain, egal von wo aus er aufgerufen wird.
Problematisch sind nur URLs, die ohne Schrägstrich beginnen, also seite1/seite2/seite3/, diese beziehen sich auf den aktuellen Kontext, werde also einfach an die aktuelle URL angehängt.
URLs, die mit einem Schrägstrich beginnen, sind aus meiner Sicht unproblematisch, ich verwende sie auch fast immer. Was daran "bad" sein soll, weiß ich nicht.
Gruß
Ingo
Da das Einfügen eines Bilder mit dem Button "In den Beitrag einfügen" per JavaScript funktioniert, könnte es etwas mit JavaScript zu zun haben. Entweder wird ein Script nicht richtig geladen oder es wurde im Browser etws an den JavaScript-Einstellungen geändert.
Gab es da in lezter Zeit Upates? Könntest Du mal einen anderen Webbrowser probieren?
Gruß
Ingo
Klar geht das, funktioniert genau so, wie bei einem normalen Link:
https://wiki.selfhtml.org/wiki/HTML/Link…nterne_Verweise
Nur das anstelle des Linktextes das Bild steht.
Gruß
Ingo
...
Ich versuche gerade eine bessere Ladezeit für meinen Blog zu bekommen - ein Punkt wäre die Nutzung der neuen PHP Version 7.0,
das soll ja einiges an Geschwindigkeit bringen. Jetzt habe ich bei Strato mal die neue Version aktiviert, ...
Die Umstellung auf PHP 7.0 bei Strato bringt für die Geschwindigkeit keinen merkbaren Gewinn.
Ich habe vor ein paar Wochen umgestellt. Gefühlt als auch "gemessen" hat sich die Geschwindigkeit nicht verbessert.
Gruß
Ingo
[LEFT][COLOR=#000000][FONT=Helvetica Neue]... Ja das ist der tatsächliche Speicherwert pro Prozess. Es kann also problemlos auch der RAM als memory_limit genutzt werden...[/FONT][/COLOR]
[/LEFT]
Danke für die Info, gut zu wissen. Dann sollten eigentlich auch keine Probleme mehr z.B. beim Upload großer Bilder auftreten, wie früher:
http://forum.wpde.org/konfiguration/138694-mediathek.html
http://forum.wpde.org/allgemeines/14…on-dateien.html
http://forum.wpde.org/konfiguration/…http-error.html
Oder seid Ihr nicht webgo24?
Gruß
Ingo
Das ist übrigens nicht nur ein Problem für interne Links, sondern auch z.B. für Bilder.
Ich verwende daher schon länger Plugins, welche interne Links und Bilder per Shortcode mit der ID in die Artikel einfügen. Dadurch ändern sich die URLs bei Änderungen automatisch.
Gruß
Ingo
...
Bekomme ich das wieder geändert ?Und ist das jetzt schlimm in Bezug auf Google ? Stichwort: duplicate content...
Genau deswegen macht Wordpress ja die Umleitung.
Ändern mußt Du es nicht, es sei denn, du willst unbedingt wieder das www davor haben.
Falls Du es ändern willst, kannst Du das bei den allgemeinen Einstellungen machen:
WordPress-Adresse (URL):
Website-Adresse (URL):
Allerdings mußt Du dann noch in allen Beiträgen die "fest verdrahteten" URLs bei Bildern und internen Links ändern.
Gruß
Ingo
Du hast Deine Seite in Wordpress ohne www konfiguriert. Entsprechend werden alle Aufrufe mit www auf ohne www umgeleitet.
Genau das wird dann natürlich auch so in der Google-Suche angezeigt.
Gruß
Ingo
Könnte am zu geringen Arbeitsspeicher liegen (PHP-Memory).
Für die Bearbeitung muß das Bild komplett in den Speicher geladen werden.
Gruß
Ingo
Was heißt "die Domain wird angezeigt"?
Verstehe ich nicht wirklich, kannst Du mal bitte ein konkretes Beispiel nennen?
Gruß
Ingo
Ich hätte da mal eine technische Frage.
Wie ist unter "Paketpower RAM" genau zu verstehen? Ist das der tatsächlich pro Prozess nutzbare Speicher, konkret also z.B. das PHP-Memory-Limit?
Oder ist es der gesamte pro User zu Verfügung stehende Speicher, so wie bei 1&1. Da steht beim größten Paket z.B. auch "2 GB RAM garantiert", was aber geteilt durch die Anzahl der max. gleichzeitigen Prozesse von 16 eben konkret 128M (PHP-Memory-Limit) ergibt.
Gruß
Ingo
E-Mail-Absender lassen sich beliebig fälschen. Dazu muß die E-Mail-Adresse nicht existieren.
Und eigentlich hat das auch nichts mit Wordpress zu tun.
Gruß
Ingo
Üblicherweise löscht Wordpress auch die von WP selbst erzeugten Bilder (Thumbnails usw., auch Versionen, die durch das Bearbeiten enstanden sind).
Wenn diese aber z.B. von einem Plugin erzeugt wurden, werden sie möglicherweise nicht mit gelöscht.
Gruß
Ingo
Was genau heißt "dass ich keine Fotos hochladen kann"?
Gibt es den Upload-Button nicht oder wird eine Fehlermeldung angezeigt?
Gruß
Ingo
Es könnte daran liegen, daß Google die Kategorieseite als besser passend zur Suchanfrage bewertet, als die einzelne Beitragsseite.
Um das zu verhindern, müßte für Kategorie- (und Tag-) Seiten im Header ein noindex gesetzt werden. Das sollte mit einem SEO-Plugin einstellbar sein.
Gruß
Ingo
Die mit einer statischen html-Beispieldatei funktioniert. Typischerweise enthalten Plugins ganz viele html-Dateien, das ist natürlich ein Problem.
...
http://www.golem.de/news/cross-sit…504-113636.htmlwenn ich 50 Plugins durch gehe, finde ich in der Regel _leider_ immer noch add_query_arg...
Was aber nur funktioniert, falls das Plugin aktiv ist. Sonst werden die enthaltenen Funktion ja wohl kaum ausgeführt.
...
Aber du hast R E C H T:Alle Plugins sind sicher - es gibt keine Sicherheitslücken - mehr als 50 Plugins solltet ihr in eurem Blog haben!
Ich gebe Dir auch R E C H T:
Alle Plugins sind unsicher - jedes hat mindestens eine Sicherheitslücke - verwendet in eurem Blog 0 (in Worten: keine) Plugins.
Und wenn wir schon dabei sind, verwendet auch auch keine Themes, die sind auch unsicher. Ach was sag ich, verwendet am besten kein Wordpress, da gibt es auch immer wieder Sicherheitslücken.
Du hast Dein Blog ja nicht mit Wordpress erstellt, oder etwa doch?
Gruß
Ingo
...
auch deaktivierte Plugins sind ein Sicherheitsproblem! Ob das Script aktiv ist oder nicht spielt für einen Angreifer K E I N E rolle.
...
Naja, wenn es ordentlich programmiert ist, wird es im nichtaktivierten Zustand (per Direktaufruf) nichts tun oder bestenfalls eine Fehlermeldung ausgeben. Aber dann hätte es vermutlich auch keine für Angreifer ausnutzbare Sicherheitslücke. 
Gruß
Ingo
Nein – aber ich hatte schon mal das Gefühl, der Eintrag hat sich geändert. WIrd das von all-inkl vielleicht im Rahmen von Updates mal angehoben? Oder weil eine neue WP-Version das erfordert?
Nein, bei All-Inkl wird die vorkonfigurierte PHP-Version, die als Apache-Modul läuft, nicht geändert. Um eine andere Version zu nutzen, muß man das selbst per .htaccess konfigurieren. Dabei läuft dann PHP aber als CGI/FastCGI nicht mehr im Kontext des Webservers, sondern in dem des FTP-Nutzers. Das hat dann entsprechende Konsequenzen für die Zugriffsrechte auf Dateien und Verzeichnisse.
Falls Du eine aktuelle PHP-Version als Apache-Modul haben willst, mußt Du Dich beim Support melden. Deine Daten werden dann auf einen neuen Server umgezogen.
Ah – das klingt doch eigentlich vernünftig. Ich habe es jetzt so verstanden, dass der Besitzer eigentlich www-data sein sollte. Wenn man nun über das Upload-Tool in KasServer oder per FTP-Client etwas auf den Server schiebt, bekommen die Files trotzdem den Besitzer www-data – richtig? Das will man doch, oder?
Es hängt halt davon ob, wie PHP läuft.
Falls als Apache-Modul, gibt es zwei Möglichkeiten:
- Der Besitzer ist der FTP-Nutzer, dann werden zum Schreiben die Rechte 777 (Verzeichnisse) bzw. 666 (Dateien) benötigt
- Der Besitzer ist www-data, dann reichen die Rechte 755 bzw. 644
Falls als CGI/FastCGI (im Kontext des FTP-Nutzers):
- Der Besitzer ist der FTP-Nutzer, dann werden zum Schreiben die Rechte 755 (Verzeichnisse) bzw. 644 (Dateien) benötigt (was die Vorgabe ist), Damit kann PHP auf alle Dateien schreiben
Falls der Besitzer dem PHP/Webserver-Kontext entspricht, hilft es nicht mal, die Schreibrechte komplett zu entziehen (555 bzw. 444), um das Schreiben sicher zu vehindern. Denn der Besitzer hat natürlich das Recht, die Rechte zu ändern.
Kurz gesagt, da wo nicht vom Web aus geschrieben werden soll, müssen Besitzer und PHP/Webserver-Kontext unterschiedlich sein und die Rechte auf 755 bzw, 644 stehen.
Das ist bei All-Inkl praktisch die Voreinstellung, sofern man WP selbst per FTP isstalliert und keine PHP-Version in der .htaccess konfiguriert hat.
Um die Schreibzugriffe z.B. auf den uploads-Ordner zu erlauben, vergibt man dem Verzeichnis die Rechte 777 oder setzt den Besitzer auf www-data und läßt sie auf 755. Letzteres hat den Nachteil, daß am selbst dann keine Dateien mher per FTP löschen oder in das Verzeichnis kopieren kann.
Gruß
Ingo
