Beiträge von Synonym

Dito. 13x -1, der Rest unverändert. Da freue ich mich dann schon auf die Abrechnung von Teliad, noch eine Einnahmequelle die wegbricht.

Hm, schwierig.

Das kommt auf die beteiligten Hoster und vor allem auf die TLD an. Einige brauchen nur den Authkey, dann geht das alles online. z.B. von Strato nach Prosite. Bei Strato online den Authkey anfordern. Bei Prosite online den Providerwechsel einleiten und den Authkey mitteilen. Fertig (auch bei .de).

.com etwa geht fast genauso, nur dass man da den Wechsel nochmals extra bei einem anderen Unternehmen bestätigen muss. Entsprechende Hinweise und Aufforderungen gehen an die Email-Adresse des Admin-C.

Bei anderen muss man noch händisch den KK-Antrag ausfüllen. Bei wieder anderen geht es auch mit Auth-Key, den muss man da aber schriftlich anfordern und bekommt ihn per Post.

Kurz und knapp: Lässt sich so nicht pauschal sagen, das handhaben leider viele gänzlich unterschiedlich.

In Sachen Sprites finde ich den hier nicht schlecht: *** Link veraltet ***

Ist ein kleines Javascript, das man sich in die Favoriten legen kann. Auf einer beliebigen Webseite dann ausgeführt erstellt es dynamisch die Sprites und zeigt die Seite dann auch gleich mit Sprites an (dynamisch per JS natürlich). Wenn alles passt, dann liefert das Tool die fertigen Sprites und auch CSS-Code der ergänzt und oder vorhandene Stellen ersetzt.

Und CatCat, das mit dem Lokal installieren meine ich als Service (Schmankerl) vom Hoster. Gerade das smush, minify oder dieser Bildkompressor von Google. Sind alle drei nicht schlecht, aber die Installation ist alles andere als ein Kinderspiel. Ehrlich gesagt kenne ich da leider auch keine Seite, wie (Ausnahme Minify) online verfügbar ist und man auf die Api zugreifen könnte. Das sind sehr mächtige Tools, aber ohne Installation eher weniger gut.

Hm, ich weiß nicht. Vielleicht liegt es auch einfach nur an meiner Einstellung - ich halte davon einfach nicht viel. Ist ja nicht so, dass ich es nicht auch schon selbst versucht habe, aber überzeugt hat es mich eben nicht. Es ist halt nichts Halbes und nicht Ganzes. Wenn man so was macht, dann richtig oder gar nicht. Das meiste, was pagespeed da macht, ist sehr einfach selbst umzusetzen. Der Unterschied ist halt nur, dass man das selbst einmal macht und pagespeed es immer wieder im Hintergrund dynamisch. Genau davon halte ich nichts. Es ist einfach nicht meine Logik, etwas permanent dynamisch zu komprimieren und kombinieren, wenn man es einmal per Hand machen könnte und des dann so bleibt, bis es geändert wird.

Klar, als Hoster sowas anzubieten ist sicherlich nicht schlecht, das könnte auch ein Alleinstellungsmerkmal werden. Dagegen sage ich gar nichts. Auch nichts gegen die Verwendung. Eher gegen Google, die das so als Wunderwaffe anbieten und einen aufdrehen wollen, wobei es die Wunderwaffe gar nicht ist. Gut, einige wundern sich dann schon, dass es nicht mehr so geht wie es soll. Mal so gesagt. Einfach mal so dynamisch ein Expires an der falschen Stelle und Bilderwechsel führen zu Problemen.

Im Grund ist es so wie viele andere Anleitungen auch, wo empfohlen wird mod_deflate einfach so pauschal zu aktivieren, für alles. Die schreiben oft aber auch nicht dazu, dass das zu Lasten der CPU geht und gerade sehr kleine Dateien durch die Kompression größer werden als vorher (Metadaten). Andere jagen da sogar noch jpg mit durch.

So in Sachen Hoster sehe ich da zahlreiche andere Punkte, die für Kunden sinnvoller wären. Memcache, Filecache, APC, Expires, header etc. Oder Tools wie minify, smush, sprite etc., also nützliche Tools, die ein normaler User gar nicht kennt und alleine schon gar nicht bedienen kann. Das sind auch Dinge, die enorm die Leistung steigern und sehr viele Hoster (wohl die meisten) gar nicht anbieten.

Richtig, so ist das. Unterschiedliche URL, gleiche Datei, aber dennoch unterschiedlicher Hash. Der wird ja gebildet aus Domain, Dateipfad, Dateiname, Größe, Datum etc. Dazu kommen dann noch die Dinge wie Etag, Expires ect. Die sind im Cache ja auch zur Herkunft hinterlegt. Wäre ja fatal, wenn der Browser da Werte einer fremden bzw. anderen Seite nehmen würde.

Selbst bei Dir auf Deinen Seiten. Geht einer auf seiden-handel und dann auf seidenhandel, dann lädt der da zwei mal die jQuery (falls beide noch nicht im Cache waren), auch wenn es die selbe Datei ist. Oder auch bei Deinem jetzigen Umbau. Einmal von http://www.seiden-handel und einmal von script.seiten-handel, das sind wieder zwei verschiedene.

Der, der sich das ausgedacht hat, hat sich schon war dabei gedacht. Das muss so sein. Der Browser kann ja nicht wissen, ob die in der Datei nicht irgendwelche Modifikationen vorgenommen hast.

Bei den Fonts ist es das gleiche. Ist ja auch nur eine Datei. Egal was, das zählt für alles.

Bei Dir im Verbund lässt sich das also nur verbessern, wenn Du die Files alle auf die gleiche URL legst, z.B. script.seiden-handel und diese jQuery dann auf allen Seiten von Dir verwendest. Dann reicht ein Download, wenn man sich auf Deinen Domänen bewegt. Hat aber den Nachteil, dass wenn die Quellurl mal offline ist, dass das Script dann auf allen Domänen fehlt.

Nee, das geht nicht. Selbst wenn würdest Du da nichts gewinnen, im Gegenteil. Hier ist je der zeitliche Ablauf falsch.

1. Browser sendet Anfrage
2. Server antwortet mit HTML
3. Browser parst und lädt gegebenenfalls jQuery nach

Hier ist kein Ansatzpunkt. Der Browser müsste ja quasi schon rein aus Verdacht beim ersten Zugriff seine Cache-Daten senden, denn es könnte ja sein, dass der Server das möchte. Nee, das geht nicht. Es müsste aber der erste Zugriff sein, denn nur so hätte Dein Server bei Punkt 2 die Chance mit einer entsprechenden, vorliegenden Version zu antworten.

Wenn Du die nicht von Google ziehen willst, dann lege die auf den eigenen Server und fertig. Hier ist halt nur der Unterschied, dass sehr viele Browser die Google-Version schon im Cache haben werden, Deine aber nicht, auch wenn das die gleiche Versionsnummer ist. Gleiches Script ist für den Browser ja eben nicht gleiches Script, die Herkunft muss auch identisch sein.

Sprich, bei dem was Du Dir da denkst müsste die Frage an den Browser ja nicht lauten "hast Du EIGENDEINE jQuery bereits im Cache", sondern "hast du MEINE im Cache". Und genau das fragst Du ja indirekt an, indem Du Deine einfach pauschal einbindest.

Nun, ich bin dennoch der Meinung, dass man das nicht braucht. Wenige ja, die keine Ahnung von der Technik haben, aber der Großteil ist mit eigenen Optimierungen besser bedienst - z.b. so wie CatCat es nun machte. Das ist 1000mal besser.

Ach ja. Als Seite, die für mod_pagespeed wirbt und auch als Hoster, der es anbietet, sollte der Wert "Page Speed Score: 71/100" deutlich besser sein Denn das ist schlechte Werbung...

Gerade hier sieht man es ja wieder, was mod_pagespeed eigentlich macht oder ist. Solche Dinge wie die fehlenden Größenangaben bei den Bildern (z.B. Smilies) kann das Modul nämlich nicht einfügen und das ist HTML-Grundkurs. Sprites kann es auch nicht erstellen und gerade die sind oft sehr wichtig und nützlich.

Nein, nicht wirklich. Eigentlich ist das aber doch auch egal, oder? Google liefert die auch per Expires von einem Jahr aus. Wenn der User sie hat, dann fertig, wenn nicht, dann wird sie geladen.

Wozu willst Du das vorab wissen?

Noch ein kleines Fizzelchen... Dein Favicon gibt es nicht - Fehler 404.

Ich kann es lesen und habe es nun leider auch ... reicht wieder die nächsten Wochen. Ignore finde ich selbst auch doof - ich mag keine verhackstückelten Threads...

Jo, Guppy hat es ja schon geschrieben.

Bei mir ist der Code etwa so:

<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault A0


	ExpiresByType image/jpeg "access plus 1 years"
	ExpiresByType image/gif "access plus 1 years"
	ExpiresByType image/png "access plus 1 years"
	ExpiresByType image/icon "access plus 1 years"
	ExpiresByType image/x-icon "access plus 1 years"
	ExpiresByType text/css "access plus 1 years"
	ExpiresByType text/javascript "access plus 1 years"
	ExpiresByType application/javascript "access plus 1 years"
	ExpiresByType application/x-javascript "access plus 1 years"
	ExpiresByType application/pdf "access plus 1 years"
</IfModule>

Aber wie Guppy sagte, Expires muss aktiviert sein.

Wobei Du aber auch differenzieren musst zwischen Cache und Etag. Für eines von beiden musst Du Dich eigentlich entscheiden. Ich persönlich finde Expires für echte Files besser.

Also, das letzte Element im Array bei unbestimmter Länge...

Nur mal so als Anhaltspunkte, da ich nicht genau weiß, was da nun als letztes selektiert werden soll.

Setze vor das foreach einen Zähler und ermittle die Anzahl der Elemente im Array:

$anzahl = count($sidebars); // Anzahl der Elemente im Array
$n = 1; // Zähler für Arraydurchlauf

Dann im foreach, ganz am Ende immer den Zähler um eins erhöhen:
$n++;

Jetzt könntest Du eigentlich im foreach, da wo das if else ist, entsprechend $n prüfen und "selected" setzen oder nicht. Also in der Art: if($n == $anzahl) { echo 'selected';}

Aber wie gesagt, das ist nur so als Gedankenstütze.

Edit:
Du könntest aber auch einfach das
<option value="0"<?php if($selected_sidebar[$i] == ''){ echo " selected";} ?>>WP Default Sidebar</option>

ans Ende setzen, also oben im Code nach der letzten Klammer (PHP-Tags <?php ?> beachten). Dann wäre allerdings nicht die letzte Sidebar im Array selektiert, sondern die "WP Default Sidebar" würde einfach am Ende stehen.

Wie gesagt, keine Ahnung wie es genau sein soll

Hast Du auch einen Antrag auf erneute Überprüfung gestellt? Muss man nämlich, ansonsten wird der gar nicht beachtet. Und, hast Du in der Liste nur URLs stehen oder auch Gründe, warum Du die da aufgeführt hast? Letzteres ist laut Google nämlich auch Pflicht. Einfach so eine Liste hochladen ist nicht - leider.

Muss mich hier auch mal zu Wort melden, da meine Sache damals ja ziemlich identisch war bzw. teilweise noch ist.

Folgendes: 1.7 Mio Links bei den "404", was tun damit. Da stand ich auch, aber nicht mit 1.7 Mio, sondern "nur" mit 1.3

Das ist einfach zu viel und das bekommt man nicht mehr wirklich geregelt. Man muss hier also Prioritäten setzen und unterscheiden zwischen "Google" und "Besucher".

Alles auf die Startseite weiterleiten: mache es nicht!

Lösungsansatz, der aus mehreren Teilen besteht:
Leite alte URLs an neue Ziele weiter, wenn das möglich ist. Aber Achtung: Leite nur eine URL an ein Ziel weiter. Also nicht 10 alte URLs an eine neue. Die Folge hier wäre nur, dass die zwar aus den "404-Fehlern" verschwinden, aber später dann in den "Soft-404-Fehlern" erscheinen.

Also, wenn weiterleiten, dann immer 1 zu 1. Das machst Du mit den wichtigsten Seiten, wenn es möglich ist.

Das war jetzt für Google und für Besucher.

Die restlichen Links, also alle, die nicht 1 zu 1 weitergeleitet werden, die bleiben als 404 stehen und werden auch entsprechend als 404 beantwortet. Lass Dir hier nicht einfallen, die auf die Startseite zu leiten, auf eine andere Seite oder gar einen 200 zu senden. Die bleiben einfach 404.

Das ist das beste, was Du für Google machen kannst! Für Besucher kannst Du hier allerdings noch etwas tun, indem Du nicht diese normale doofe 404-Seite hast, sondern was spezielles für Besucher, so dass die auch direkt wieder weiter kommen und direkt wissen was wo zu finden ist. Noch besser wäre es, wenn Du das dynamisch lösen könntest und quasi die 404-Seite dynamisch auslieferst. So könntest Du bei jedem fehlerhaften Zugriff direkt drauf reagieren und entsprechende Verweise einbinden, denen der Nutzer dann direkt folgen kann. Somit wäre das für den nur ein einziger Klick mehr und Google wäre auch "zufrieden". Hier würde es auch keine Rolle spielen, wenn der Ziellink mehrfach ist, da es eben nur ein Link auf einer 404-Seite ist und keine Weiterleitung.

Canonical: Ist auch nicht unbedingt eine gute Lösung. Es ist ohnehin schon so, dass die Nutzung freiwillig ist und oft nicht funktioniert. Bei mir zeigte sich jedoch, dass je mehr Canonical auf eine Seite verweisen, der jeweilige Canonical immer seltener beachtet wird.

Anmerkung zu 404-Fehler und Soft-404:

Die Soft-404-Fehler verschwinden nicht von alleine aus der Liste. Die verschwinden nur, wenn daraus ein echter 404 gemacht wird.

Die 404 hingegen verschwinden von selbst, wenn es ansonsten keine Verlinkungen mehr auf die Seiten gibt. Das dauert aber und kann schon im Bereich 3 Wochen bis 6 Monaten liegen. Nachhelfen kannst Du nur, indem Du die Fehler als "korrigiert" markierst, wobei das aber auf 1000 pro Tag limitiert ist. Und ja, bei 1.7 Mio Links und 1000 möglichen Markierungen am Tag, wobei Google ja auch bereits markierte teilweise wieder finden wird, ich weiß wie lange das dauert - wie gesagt, hatte das gleiche Spiel.

Ok, das ist natürlich so eine Sache, wenn die Daten ständig wechseln. Aber ein Ansatz mit der IP und dem UA ist es schon mal, denn einen Teil fängt es ab.

Weiter könnte es gehen mit mod_security und dort die Zugriffe pro Sekunde beschränken. Wäre dann zwar nicht gesperrt, aber der Server kann wieder atmen.

Boa
Bot-Trap ist gut, habe ich auch drauf, aber für die wirklich großen Kaliber nicht wirklich geeignet, denn dazu muss das Script auch ständig ausgeführt werden. Und Bot-Trap ist nicht gerade klein. Viel effizienter ist hier schon per Server zu blockieren und Bot-Trap den Rest machen zu lassen.

Nachtrag:
Der ganze Bereich gehört dem Provider aus China:
182.112.0.0 - 182.127.255.255

Wie viele Besucher hast Du von diesem Provider?
Du könntest also die ganze 182.118. sperren

Selbiges mit dem anderen Bereich:
101.224.0.0 - 101.231.255.255

Also die 101.226. zu machen.

Wenn es sein muss, und noch gänzlich andere IPs dabei sind, auch sperren oder eben die beiden Kompletten Ranges von den Providern.

Würde ich hier auch ohne Mod_Rewrite machen, denn das ist auch serverlastig.

<Directory "/var/www/dein-pfad/public_html"> 
	order allow,deny
	allow from all
	deny from 182.118.
	deny from 101.226.
</Directory>

So in der Art zumindest.

Schon mal versucht?

*** Link veraltet ***

Also wenn die alten und neuen Links alle so aufgebaut sind, dann kannste die mit einer oder sehr wenigen Rules abfangen. Wichtig ist hier ja nur eine eindeutige Erkennung und dazu hättest Du /download/Nummer.pdf. Die alten "haben einen Text davor", die neuen nicht.

Der Verzeichnisschutz würde ihn blockieren, aber auch alle anderen Nutzer.

Mal soviel vorab. Der Depp war sehr stümperhaft. Der hatte teilweise das gleiche Versucht wie ich und hat es nicht geschafft. Aber hätte er den richtigen Weg, dann hätte er eventuell auch Zugriff bekommen.

Zitat

Ich möchte nur wissen was der Drecksack von einer privaten Seite hat.

Im Zweifel Dinge wie:
Seite als Virenschleuder verwenden
Server als Spamschleuder verwenden
Server als Teil eines Botnet verwenden

So, sehe gerade, das Formular ist wieder offline. Nun sehe ich auch mal die Einträge (waren vor meinem Post noch nicht da - so gegen 09:48 ). Das ist nun aber kein Spaß mehr, denn hier versucht einer auf Deinen Server loszugehen und Passwörter auszulesen. Die Zugriffe sind auch nicht per Hand (so wie meiner), sondern automatisiert. So schnell kann keiner Tippen und Senden.

Ah, Du bist am Löschen. Ein SQL-Angriff wird auch versucht.