Beiträge von Melewo

Kaum jemand wird hier die Größenordnung erreichen, wo er sich Gedanken über CDN machen müsste. Bisher habe ich auch nur davon gehört, dass der eine oder andere Bilder nach Amazon auslagerte, weil angeblich die Server von Amazon so superschnell sein sollten. Eine Zeit später las ich dann, dass der Geschwindigkeitsvorteil doch hinter den Erwartungen zurückblieb.

Und bei den wenigen, die da mit Millionen von Aufrufen zu kämpfen haben, las ich mehr von Sachen wie Load Balancing als von CDN. So richtig Gedanken machte ich mir bisher um beides nicht, da nicht meine Größenordnung.

Ja, was die Bedeutungslosigkeit von Meta-Tags anbelangt.

Über Bilder fürs Impressum wird sich schon seit Jahren gestritten, ob die für Abmahnungen geeignet sind oder nicht, da die zum Beispiel von Screenreadern nicht gelesen werden können. Somit müsste dann die Adresse im Alt-Text aufgenommen werden, den aber Google nun wieder lesen könnte und auch wird, wenn die Seite nicht mit robots content="noindex" als gesperrt für die Aufnahme in den Index ausgewiesen wird.

Warum die robots.txt nur zweite Wahl ist, verweise da immer am liebsten auf das was Google dazu schreibt:

Zitat

Zwar werden die Inhalte der Seiten, die durch die Datei "robots.txt" blockiert sind, weder gecrawlt noch indexiert, möglicherweise erfolgt jedoch dennoch eine Indexierung der URLs, falls diese auf anderen Webseiten gefunden werden.

https://support.google.com/webmasters/answer/156449?hl=de

noindex im Head sollte hingegen von Google bei jedem Besuch der Seite beachtet werden. Für Crawler, die sich nicht daran halten, eine leicht auffindbare E-Mail-Adresse zum Wegwerfen im Noscript-Bereich und eine vernünftige für die restlichen Besucher im Scriptbereich. Beim Posteingang ist dann noch leichter erkennbar, was über Spam-Bots gefunden wurde.

Nun gut, soll nur eine Standard-Warnung sein, falls versucht wird SSL / https zu benutzen, falls ich das richtig verstehe (was nicht der Fall zu sein braucht)?

Zitat

[Mon Aug 26 23:07:11.442431 2013] [ssl:warn] [pid 8040:tid 244] AH01909: RSA certificate configured for http://www.example.com:443 does NOT include an ID which matches the server name

Zitat

its a default warning (not error) and will not affect XAMPP unless you want to run SSL/HTTPS.

http://www.apachefriends.org/f/viewtopic.php?f=17&t=53055

Zitat

[Mon Aug 26 23:07:11.442431 2013] [ssl:warn] [pid 8040:tid 244] AH01909: RSA certificate configured for http://www.example.com:443 does NOT include an ID which matches the server name

Findet der nicht nur Dein Zertifikat nicht?
Hast Du ein gültiges Zertifikat, wenn Du SSL und 443 benutzt?
Oder ist das vielleicht gestern abgelaufen?

Nicht dass ich mich richtig auskennen würde, Appendix und formateins kennen sich da bestimmt besser aus, doch mich erinnert das erst einmal an meine Versuche mit einem selbstgebastelten Zertifikat über 443 eine SSL-Verbindung benutzen zu wollen, die dann auch nur Errors lieferte.

Meinst Du mo/po Sprachdateien?
Dafür gibt es Editoren und Plugins.
Keine Ahnung, ob die etwas mit Woo Commerce zu tun haben.

Beispiel: http://wordpress.org/plugins/codestyling-localization/

Zitat von knuppel

Ich sollte noch dazu sagen, dass in jedem Artikel ein anderer Code eingefügt werden soll.

Jetzt wird es interessant, wie möchtest Du das machen? Ich meine ich sehe da 5 Parameter-Werte-Paare und die Du möchtest nicht wirklich alle einzeln übergeben und das vielleicht in 300 Varianten oder mehr. Somit benutze CDATA, wie unter dem ersten Link beschrieben, ist die einfachste Lösung. Würde ich zumindest so machen.

Vor </head> einfügen, die Id ist im Quelltext der Seite zu finden und eigentlich sollte das so genügen. is_page, wenn es eine statische Seite ist.

<?php if (is_page("241")) echo "<meta name=\"robots\" content=\"noindex,nofollow\">\n"; ?>
</head>

Ohne Zeilenumbruch, der erscheint nur hier, bzw. Zeilenumbruch erst hinter ?>.

robots.txt ist zweite Wahl, da die Seite dennoch über Querverweise besucht und indiziert werden kann. Im Head ist besser und da kannst Du recht genau abfragen, ob es die richtige Seite ist.

Beispiel:

if (is_single('168')) {
    echo "Gebe aus oder lasse es bleiben.";
}

Weitere Beispiele:

http://codex.wordpress.org/Function_Reference/is_page
http://codex.wordpress.org/Function_Reference/is_single

Besser ist es auch den Punkt zu maskieren und + statt * zu verwenden, denn Du willst ja keine namenlosen Dateien regeln.

^(.+?)\.html$

Und Du bist Dir sicher, dass Du dort nicht nur das L für letzte Regel am Ende der Zeile vergessen hast?
Ich würde es dann an dieser Stelle probieren und vor jedem Test den Browsercache löschen. Falls die lexikon-begriff.php im Root liegt, ansonsten im Root und /verzeichnis/lexikon-begriff.php mit angeben oder wie bei Deinem Beispiel im Verzeichnis ohne / notieren. Ohne [L] würde die nächste Regel unter Umständen noch mit ausgeführt oder für Verwirrung sorgen, doch das kann ja nicht Deine Absicht sein.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /


RewriteRule ^(.*).html$ /lexikon-begriff.php?begriff=$1 [L]


RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress

Wer es besser versteht oder besser übersetzen kann, mag es machen:

Einzeiliger Code in einer Datei wird häufig von Hackern als zu einem Theme oder Plugin gehörende Datei verkleidet. Ist dies geschehen, wird wohl erst einmal geprüft, welche Möglichkeiten für einen Request bestehen und ob eine Index, eine htaccess oder ein Favicon zu finden sind, zumindest eine von diesen Dateien? Dann werden die Schreibrechte neu vergeben, Spam in die Seiten geschrieben und nach Möglichkeiten für eine Weiterverbreitung gesucht?

So in etwa habe ich das zumindest verstanden. Kann sein, dass Deiner beim Versuch Spam in die Index zu schreiben, den Fehler auslöste und so keinen weiteren Schaden anrichtete.

Hatte vergessen, Passwörter ändern genügt nicht, wenn ein Trojaner sich auf dem Rechner einistete, der die neuen Passwörter gleich wieder ausliest und sich per FTP Zugang verschafft. Somit solltest Du unbedingt auch Deinen Rechner prüfen.

Von einer möglichen SQL-Injektion der Datenbank lese ich nichts, vielleicht hast Du auch da Glück gehabt.

Ich muss mir das ja auch alles dreimal mit Translator durchlesen und dann versuchen zu verstehen, wie der Zugriff erfolgte. Passwörter solltest Du wohl auf jeden Fall erst einmal ändern.

Sieht mir hiernach aus (Backdoor):

http://blog.aw-snap.info/p/example-of-backdoor-script.html

Hier lernt man auch nicht aus, wobei ich aber nur lerne, um meine eigenen Seiten besser zu schützen. Verstehst Du die Beschreibung? Wenn nicht, dann muss ich mir das erst übersetzen und dann versuchen es so gut es geht zu formulieren.

Zitat von bienchen

Dieser Ordner existiert seit dem 23.08. - 3:32Uhr - schon etwas seltsam.

In welchem Verzeichnis?
Soll ja auch Plugins geben, die Verzeichnisse anlegen.
Eine PHP-Datei enthält meistens den einen oder anderen Kommentar zwischen /* und */ oder hinter //.

Ich meine, Google erzählt mir:

Zitat

Es wurden keine mit Ihrer Suchanfrage - "enginei/sysy.php" - übereinstimmenden Dokumente gefunden.

Zitat

Es wurden keine mit Ihrer Suchanfrage - "enginei/sysy.asp" - übereinstimmenden Dokumente gefunden.

Einzeln brauche ich nicht suchen, dann wird es zu ungenau.
Schaue Dir einfach den Quellcode der Dateien an, ob da Kommentare enthalten sind.

Finde keine Beschreibung für eine sysy.php und wenn es sich um Malware handeln sollte, müsste die eigentlich irgendwo erwähnt werden.

Zitat von bienchen

Habe ich gemacht und jetzt funktioniert die Seite wieder. Allerdings kann ich den Fehler nicht nachvollziehen.

Was hast Du gemacht, nur ausgetauscht und weißt nun nicht ob da etwas stand?
Oder was stand in dieser Zeile?

Zitat von Gerd-E.

Hallo bienchen,

Tipp: Die index.php herunterladen, mit einem Editor (z.B. Notepad++) die entsprechende Zeile suchen und das störende Zeichen entfernen. Dann Datei wieder hochladen.

Meine Index-Dateien von 3.5.2 und 3.6 haben nur 17 Zeilen plus eine Leerzeile, da sollte wohl eigentlich nichts mehr folgen?

Vorausgesetzt Du hast keine Veränderungen vorgenommen, in dem Du irgendetwas mit <einfügen oder verändern> wolltest, dann war es im schlimmsten Fall ein Hacker.

Die htaccess würde ich erst einmal nicht löschen oder verändern, bevor Du nicht weißt, was Du da tust. Dann mal ein konkretes Beispiel für einen Link, der dann nicht mehr gefunden wird. Worauf verweisen diese angeblich richtig angepassten Links? Auf Seiten, die unter einer anderen Domain erreichbar sind?