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 erstellenEs 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
...
Dabei sind die Bilder nicht einmal besonders groß, (das letzte hatte um die 500KB)...
Die Dateigröße ist bei manchen Problemen nicht maßgeblich, sondern die größe des Bildes (Breite und Höhe in Pixel).
Der Grund könnte ein zu geringer Arbeitsspeicher sein.
Bei welchem Webhoster hast Du welches Hosting-Paket?
Gruß
Ingo
Bei All-Inkl läuft der Webserver mit dem Benutzer www-data. Wenn in Wordpress Verzeichnisse oder Dateien z.B. für Uploads angelegt werden, ist der Owner dann www-data.
Man kann bei All-Inkl aber auch andere PHP-Versionen über die .htaccess konfigurieren. Diese laufen dann als CGI/Fast-CGI im Kontext des FTP-Benutzers. Entsprechend ist der Owner von neuen Verzeichnissen und Dateien nun der FTP-Nutzer.
Hattest Du irgendwann mal die PHP-Version geändert?
Man kann im KAS unter Tools->Besitzrechte den Owner ändern. Dann muß man aber ggf. auch die Zugriffsrechte anpassen, damit die Uploads funktionieren.
Gruß
Ingo
... Natürlich kannst du auch auf deinem lokalen Server einen Apachen Webserver inkl. PHP usw. aufsetzen (Vorausgesetzt Linux läuft auf dem Server), ...
Wieso Linux? Apache, PHP und MySQL laufen auch prima unter Windows, habe ich seit vielen Jahren hier in meinem Heimnetzwerk im Einsatz.
Gruß
Ingo
Die 40M-Speichergrenze ist etwas ungewöhnlich, üblicherweise sind es 30, 60, 80 oder 120 bei 1&1:
https://goo.gl/eTxhxM
Mehr Speicher bekommst Du normalerweise nur durch ein Paket-Upgrade. Welches 1&1-Paket hast Du denn zur Zeit?
Gruß
Ingo
Danke für den Hinweis, habe ihn gerade angeschrieben.
Ich antworte jetzt mal hier.
Wenn es am zu kleinen Arbeitsspeicher liegen täte, würde sich das Problem genau anders herum darstellen. Du könntest keine großen Bilder hochladen, kleine aber schon.
Die Erklärung "weil es aufwändiger sei, kleinere Bilder hoch- als größere Bilder runterzurechnen" ist Unsinn. Wordpress rechnet kleine Bilder nicht hoch. Falls das ein Plugin machen sollte, würde ich das schleunigst deinstallieren.
Ich denke nicht, daß mein Plugin bei Deinem Problem helfen wird.
Wie auch immer, um das Plugin in Betrieb zu nehmen, kannst Du eine vorkonfiguriert Datei von der Pluginseite herunterladen.
Diese dann einfach an Stelle der Datei aus dem ZIP-Paket auf den Server hochladen.
Gruß
Ingo
...
1. Von einem google pagespeed von 94 mal eben auf 80 runter - kein problem :) der neue Server muss nur ein paar module nicht haben.
2. Cache Plugins verwenden, die auf dem Server Dateien schreiben sollen - bei dem Umzug einfach die Rechte für die Verzeichnisse nicht beachten... die erzeugten Server 500 fehler sorgen dann für eine Mial von Google. Die Webmastertolls teilen dir dann mit - ätsch deine Seite haben wir jetzt gleich im index gelöscht oder so ähnlich.
3. mit dem Serverumzug auch die technik vom Server eben ändern . also aus php 4.4.0 auf PHP 7.0.3 wechseln _ohne_ die Scripte zu ändern :)
4. den Umzug immer selber machen wollen.
...
Das ist ja das schöne an einem internen Umzug beim Hoster, man muß es nicht selber machen.
Bei All-Inkl ist es so, daß auf dem neuen Server alles wieder so hergestellt wird, wie es vorher war. Auch die Dateizugriffsrechte werden nicht verändert.
Allerdings wird vermutlich die PHP-Version eine andere sein, standard ist dort z.Z. 5.6.
Gruß
Ingo
Da sich mit dem Serverwechsel die IP-Adresse ändert, sollte man prüfen, wo diese irgendwo explizit verwendet wird.
Ich hatte bei einem Umzug mal vergessen, den DNS A-Record einer extern aufgeschalteten Domain anzupassen, wodurch die Seite dann für einige Zeit nicht erreichbar war.
Gruß
Ingo
Es funktioniert bei mir auch nicht im Chrome.
Ich finde es ungewöhnlich, daß ein Kontaktformular über den WP-Admin-Bereich läuft. Dort kommen eigentlich nur angemeldete Benutzer rein.
Bei Dir funktioniert es im Chrome vermutlich nur deshalb, weil Du dort im WP-Adminbereich eingeloggt bist.
Gruß
Ingo
...
Fatal error: Out of memory (allocated 34340864) (tried to allocate 65536 bytes) in /homepages/34/d311446286/htdocs/wordpress/wp-includes/functions.php on line 3092
...
Das sieht nach einem alten 1&1-Hostinpaket oder dem aktuell billigsten Paket (Starter) aus. Da gibt es nur ca. 30M Speicher, der betriebssystemseitig begrenzt wird (kein PHP memory_limit!).
Du solltest über ein Paket-Upgrade nachdenken.
Kurzfristig kann das deaktivieren von Plugins helfen. Dazu das Verzeichnis mit dem/den Plugins per FTP umbennenen.
Gruß
Ingo
Das Plugin DoFollow 4.0 läuft übrigens nicht mit PHP 7.
Gruß
Ingo
... ist zwar ein "Home 5.0"-Paket, ...
Bei den alten Paketen liegt das Memory-Limit sogar bei nur 32M (Out of memory).
Insofern ist ein Paket-Upgrade sehr zu empfehlen. Es sollte dann aber mindestens "Unlimited" (60M) oder besser "Unlimited Plus" (80M) sein. Kostet dann allerdings 6,99 bzw. 9,99 € im Monat.
Gruß
Ingo
...
Es gab unter dem globalem Sprachverzeichnis languages/plugins/ auch noch diese beiden Dateien, und die hatten nur 644
...
Und Du hast sie nun auf 666 und nicht etwa 777 gestellt, hoffe ich doch. :-)
Gruß
Ingo
Jetpack hat 40 Sprachen, bei 39 davon funktioniert das 777,tiefere einstellungen machen Probleme.
...
Auch wenn es für 39 von 40 mit 777 funktioniert, ist es trotzdem falsch. Die 39 von 40 würden aber auch mit 666 funktionieren. Und die eine nicht.
Egal.
Wenn Du die gelöscht hast und sie ist immer noch da, ist das schon seltsam.
Möglicherweise greift ein anderer Prozess darauf zu und verhindert das Schreiben/Löschen.
Gruß
Ingo
Je nach Hostingpaket hat mein bei Strato Zugriff auf die vom Hoster erstellten Datensicherungen:
https://goo.gl/X68MoS
Gruß
Ingo
Hallo
obwohl ich die Ordner -Wp-content / Plugins / jetpack /languages alle auf 777 gesetzt habe,
und ich Ordner languages auch alle Dateien auf 777, ...
Nur der Ordnung halber, für Dateien ist 777 falsch, richtig wäre 666. Die Rechte 777 gelten für Verzeichnisses oder bei Dateien bedeuten sie, daß diese ausführbar sind.
Manche Systeme verweigern aus Sicherheitsgründen den Zugriff für Dateien, die als ausführbar deklariert sind, obwohl sie es nicht sein dürften.
Gruß
Inho
Stelle einfach die Permalinks auf "Beitragsname" (%postname%), die Links der Form /?p=1234 funktionieren auch weiterhin und leiten auf /beitragsname um.
Gruß
Ingo
