Beiträge von MHensel

Nachtrag:

eben gerade noch einmal versucht, ob sich im Impressum nicht doch eine mail-Adresse findet,
aber nun ist die Webpräsenz lt. Strato "momentan nicht erreichbar..."
Hat sich damit erledigt.

Hallo zusammen,

vor einigen Tagen trudelte mal wieder eine dieser sattsam bekannten mails ein, in der mir die Sperrung meines PayPal Kontos angedroht wurde, wenn ich nicht umgehend meine Daten verifiziere...
Also nichts Neues an sich.
Interessant ist nur der Link hinter dem Button "Datenabgleich zwecks Sicherheit Pay.Pal GmbH":
_http://j??-ph??????.de/wordpress/wp-content/plugins/4623317048/625305350/_
(die Fragezeichen zur Anonymisierung).

Was macht man in einem solchen Fall am besten?

Den Betreiber des Blogs zu informieren? So, wie es aussieht, ist der aktuelleste Inhalt dort ein paar Jahre alt, eine mail-Adresse habe ich nicht gefunden.

Über Googles Webmasterservice die Seite melden?
An sich verteilt sie ja beim Besuch keinen Spam, oder?

Gruss
Manfred

Das sehe ich inzwischen auch so, leider.
Danke

Hallo zusammen,

der Titel sagt es eigentlich schon aus:
angeregt oder besser, aufgeschreckt von einem Artikel in einer aktuellen c´t zur Nutzung fremder Medien auf privaten Webseiten, habe ich mich vor nunmehr über zwei Wochen einmal an eine Firma aus Istanbul und einmal an eine Abteilung der Stadtverwaltung Istanbuls gewandt, und um die Erlaubnis zur Nutzung von Auszügen aus Touristenfaltkarten auf meiner privaten Webseite gebeten.
Die email-Adressen habe ich jeweils dem Impressum der Faltkarte entnommen und meine Bitte sowohl in Deutsch als auch in Englisch formuliert.
Bis heute ist keine Reaktion erfolgt, auch nicht als Lesebestätigung der mails und nicht einmal im Log der Webseite,
(ich hatte natürlich meine Webseite angegeben, als Nachweis für den nicht-kommerziellen Charakter).
Ich hätte sehr gerne die Schilderung unserer Woche in Istanbul auch mit Ausschnitten aus der besagten Touristenkarte garniert.

Ein Freund hatte bereits schlechte Erfahrungen gemacht, als er den Umzug seines Geschäfts von einer Ecke in die andere Ecke der Kleinstadt mit einem Kartenausschnitt und einer roten Linie darauf seinen Kunden erläutern wollte...

Eigentlich glaube ich ja nicht, dass irgendwer aus der Istanbuler Verwaltung auf meiner Webseite erkennen würde, dass dort Teile einer Touristenfaltkarte, die in jedem Tourist Information Office bzw. am Bahnhof am Hafen ausliegen, die Örtlichkeiten erklären...
aber wer weiß...

Was kann ich jetzt noch tun?

Gruß
Manfred

Hallo zusammen,

nach einigen Tagen erfolgloser "Hampelei" mit den Permalinks habe ich es zum Einen nun schriftlich von HostEurope, dass die Permalinks mit Hilfe .htaccess erst ab dem Paket "WebPack M 4.0" möglich sind - ich habe gerade auf WebPack M 3.0 "upgraded",
zum Anderen habe ich nun doch eine Umgehung dieses Problems geschafft.

Wie bereits an anderer Stelle geschrieben, erreicht man durch Einfügen von "index.php" in den eigentlichen Permalink einen suchmaschinenfreundlichen Link, ohne die Funktionalität von ".htaccess" und "mod_rewrite" zu erfordern.

Konkret wählt man unter Einstellungen/Permalinks zunächst die Option z.B. "Tag und Name";
in meinem Fall wird im gleichen Moment die zunächst leere letzte Option mit
"/%year%/%month%/%day%/%postname%/" ausgefüllt.
Dieser Zeile setzt man das besagte "/index.php" voran, editiert die einzelnen Parameter je nach Gust - löscht z.B. %day% - und setzt die Änderungen um.

In meinem Fall erscheint z.B. die Seite "Impressum" als "m-hensel.de/index.php/Impressum" in der Adresszeile, aber nicht als z.B. "m-hensel.de/?p=123"
UND es kommt keine Fehlerseite 404!!

Mit freundlichem Gruß
Manfred

Tja,
für eine Lösung dieses Problems wäre ich ebenfalls ein dankbarer Abnehmer...
in meinem Fall hatte ich die Permalink-Struktur bei einer vorhandenen WP-Installation in Richtung "sprechende" Links geändert...
die Folge, ebenfalls "404 Seite nicht gefunden"!
EIN Grund kann eine ".htaccess" sein, die diverse ReWrite Statements (mod_rewrite) enthält und deren Rechte verhindern, dass WP dort Änderungen vornehmen kann.
Zumindest ist diese Vermutung das Ergebnis einiger "googeleien" und die Aussage in "Praxiswissen Wordpress" von Olivia Adler, die "660" als Zugriffsrecht vorschlägt
In meinem Fall kommt erschwerend hinzu, dass mein Hoster HostEurope nicht vorsieht, die Rechte an dieser Datei ändern zu lassen, es bleibt hier also bei "640".

Als Ausweg für solche Fälle wird vorgeschlagen, den Permalink von z.B. "http://example.com/titel-des-postings/" manuell zu folgenden zu modifizieren:
"http://example.com/index.php/title-des-postings/".

Obwohl im Dashboard auch das Editieren des Permalinks vorgesehen ist, klappt es in meinem Falle nicht:
der Slash zwischen .php und title- ... wird beim Speichern gelöscht und damit ist der Witz gemordet.

Andere Tips und Hinweise sind erwünscht.

Manfred

Ich muss das Thema doch noch einmal hervorholen.

Nach den beiden Antworten s.o., wo die Revisionsgeschichte sich versteckt, war ich doch etwas verblüfft und unsicher, warum ich das so offensichtliche nicht gesehen haben soll, auch meine Frau war sich sicher, dass die Revisionsliste bisher NICHT unter ihrem Entwurf und nicht unter meinem zu finden war.
Ich hatte jedoch, nach dem Absetzen meines Hilferufs und vor den Antworten weiter in den Optionen jeglicher Art gesucht und quasi by-the-way die Permalink-Struktur von WP-Standard umgestellt auf die Option, in der die Artikelüberschrift mit im Link erscheint.

Keine gute Idee!

Glücklicherweise hatte/habe ich außer einer Startseite nur einen harmlosen Artikel und ein paar Artikel im Entwurfstadium... und das Impressum als Seite!
Weder der Artikel noch das Impressum ist beim Besuch meines Blogs mehr aufindbar --> Fehlermeldung 404.

Aber das soll jetzt und hier nicht das Thema sein.
Vielmehr ist auffällig, dass in der jetzigen Permalink-Enstellung

http://meinblog.de/..../.../Beispielartikel/

die Revisionen unter den Artikel sichtbar sind, auch die entsprechende Option mit Checkbox oben, aber im Urzustand

http://meinblog.de/..../.../?p=123

keine Revisionsliste und keine Option zum Anzeigen der Revisionen angeboten wird!
Immerhin hat das Zurücksetzen auf diesen Urzustand ohne Probleme funktioniert und auch das Impressum ist wieder erreichbar.

Ist das ein Feature, ist es gewollt?

Zum Thema, wie ich auf die suchmaschinenfreundliche Permalink-Struktur wechseln kann, ohne alles neu zu schreiben, setze ich gleich einen eigenen Artikel auf.

Mit freundlichen Grüssen
Manfred

Besten Dank!
beim Editieren ... in der Tat!
Dort finde ich nun tatsächlich die gesuchte Checkbox.

Hallo zusammen,

wie der Betreff verdeutlicht, habe ich das Problem, keine Revisionen meines Geschreibsels zu erhalten!
Gespeichert sind runde 50 "post revisions" und 2 "auto update revisions" und nun brauche ich wirklich mal die vorletzte Speicherung meines aktuellen Entwurfs.

Über Google finden sich zahllose Beiträge zum Löschen der Revisionen und nebenbei die Anmerkung, dass die Revisionen am Ende des Artikels aufgelistet sind.
Bei meinem WP nicht!
Ich finde auch keine Optionen, um ggfs. Revisionen anzeigen zu lassen!
Stichwort "Artikelüberarbeitung" ebenfalls Fehlanzeige.

Hat sich mit Version 3.4 etwas in dieser Richtung geändert?
(allerdings waren mir Revisionen davor auch nicht bewusst aufgefallen, außer, dass sie mit dem Plugin "WP-Optimize" entfernt wurden.

Ich bitte um einen Fingerzeig, Danke.

Manfred

Moin,

mit meinem Filezilla hole ich die Datei, die ich editieren möchte, in ein Verzeichnis auf meinem Rechner, ändere, speichere ab und lade wieder hoch auf den Server, wobei natürlich die Frage mit "ja, überschreiben" zu beantworten ist, wenn es heißt: "... Datei ist im Zielverzeichnis bereits vorhanden, überschreiben?"
Aber vielleicht mache ich das schon immer zu kompliziert...

Gruss
Manfred

Edit: ja, ich mache es wohl immer zu kompliziert :)
Rechtsklick --> Ansehen, Ändern geht ebenso

Hallo zusammen,

vorweg: für Fragen zur Sicherheit habe ich hier keine spezielle Rubrik gefunden. Installation oder Konfiguration ist die Frage...

Mein Anliegen:

Ich schaue mir regelmäßig die Log-Dateien an, die HostEurope für mich sammelt.
Ganz aktuell finde ich, neben den bekannten Besuchen der Suchmaschinen Crawler, folgende Zugriffe (etwas anonymisiert):

31.yxz.aaa.9 - - [17/Jan/2012:05:13:34 +0100] "GET /mein_blog/?p=124&cpage=1 HTTP/1.0" 404 1480 "http://meineseite.de/meineSeite/?p=124&cpage=1#comment-162" "Mozilla/4.76 [en] (Windows NT 5.0; U)" "meineSeite.de"
31.yxz.aaa.9 - - [17/Jan/2012:05:13:34 +0100] "GET / HTTP/1.0" 200 12153 "http://meineseite.de/" "Mozilla/4.76 [en] (Windows NT 5.0; U)" "meineSeite.de"
31.yxz.aaa.9 - - [17/Jan/2012:05:13:36 +0100] "GET /bl_og/w51p/wp-login.php HTTP/1.0" 200 2675 "http://meineseite.de/bl_og/w51p/wp-login.php" "Mozilla/4.76 [en] (Windows NT 5.0; U)" "meineSeite.de"
31.yxz.aaa.9 - - [17/Jan/2012:05:13:37 +0100] "POST /bl_og/w51p/wp-login.php HTTP/1.0" 200 3582 "http://meineseite.de/bl_og/w51p/wp-login.php" "Mozilla/4.76 [en] (Windows NT 5.0; U)" "meineSeite.de"

Die (verhunzte) IP-Nummer gehört zu einem St.Petersburger Provider, was mich zunächst nicht beunruhigte.
Was mich irritiert, ist der Vorgang des "GET /.../.../wp-login.php ", erfolgreich (200) mit einem anschließenden "POST /.../.../wp-login.php ", ebenfalls erfolgreich (200) aber mit einer anderen Größe (3582 ggü. 2675).
Die beiden ersten Zeilen zeigen einen ersten Fehlversuch, weil mein Blog nun nicht mehr dort liegt, dann der Abruf in der 2.Zeile, und anschließend dieses mysteriösen GET/POST Paar.
Wenn es nur der Versuch ist, mir etwas Spam als Kommentar getarnt unterzuschieben, bliebe ich recht gelassen... wäre nicht der erste Versuch.

Weil ich die "Innereien" einfach noch nicht recht begriffen habe, wäre es mir angenehm, wenn hier jemand etwas sachkundiges beitragen könnte.

Gruss
Manfred

Christoph,

die Vielfalt der Konfigurationen ist eben das Grundproblem hier und in jedem vergleichbaren Forum und was bei mir eine Lösung ist, kann bei Dir möglicherweise völlig unwirksam sein.

Folgendes etwas ausführlicher, weil es noch einige andere HostEurope Kunden hier gibt...

Als HostEurope Kunde habe ich die Wahl zwischen wpXXXXXX oder ftpXXXXXX als User/Owner (Besitzer) der Dateien und Ordner und ausschließlich ftpXXXXXX als Gruppenname.
(XXXXXX ist meine Paketnummer)
Wähle ich ftpXXXXXX als User, dann hat Filezilla keine Probleme mit dem Handling der Dateien/Ordner, aber WordPress "zickt" bei allen möglichen Gelegenheiten, auch dann, wenn ich die Zugriffsrechte für die Gruppe deutlich erhöhe (was ich nicht möchte):
Updates laufen nicht wegen fehlender Schreibrechte, Plugins werden zwar aktualisiert (angeblich), aber die alten Versionen können nicht gelöscht werden, und letztlich sind sie doch nicht aktualisiert, usw und so fort...

Ändere ich dagegen auf wpXXXXXX als User/Owner, läuft WordPress völlig problemlos... nur, dann bleibt Filezilla in vielen Dingen außen vor,
(einen ähnlichen Fall hatte hier ein Leidensgenosse bereits geschildert).

Das Geheimnis (bei HostEurope!) liegt im ftp-Account:
Zitat aus der FAQ:
(...| Webserver-Benutzer: Diese Option steht zur Verfügung, wenn Sie Ihr Paket ab dem 09.02.2011 bestellt oder aber Ihr WebPack auf das neue Rechtekonzept umgestellt haben. Hier legen Sie fest, ob der Benutzer für den FTP-Zugang dem Benutzer des Webservers entspricht (Standardeinstellung: hohe Skriptkompatibilität, kein www-run Problem) oder ob es sich um einen normalen FTP-Benutzer handelt. Weitere Informationen finden Sie hier:.... )

Mit "... Diese Option..." ist ein Häkchen bei den Zugangsdaten des ftp-Accounts gemeint, welches bei mir nicht gesetzt war!
(Lesen bildet und vermeidet Geschwätz... Leitspruch eines alten Kollegen :-) )
Das Häkchen ist nun gesetzt, WordPress kann weiter ungehindert agieren und dennoch habe ich Zugriff per Filezilla.

Auch wenn ich noch immer nicht alles zur Gänze verstanden habe, möchte ich obiges allgemein kundtun, in der Hoffnung, dass Du etwas für Dein Problem daraus ableiten kannst.

Gruss
Manfred

Hallo,

mein Filezilla zählt die Übertragungen und addiert unter "erfolgreiche Übertragungen" mit jeder Aktion auf,
d.h. Filezilla nennt mir die aktuell zu übertragenden Dateien und zählt die erfolgreichen zu den bereits vorher übertragenen Dateien dazu.
Der Spuk ist beim Neustart von Filezilla wieder vorbei.

Gruss
Manfred

Edit:
dieses Aufaddieren gilt natürlich auch bei den "nicht erfolgreich übertragenen Dateien"... d.h. ein paar fehlgeschlagene Versuche, eine Datei zu übertragen, zeigt dann erschreckende 3, 4 oder mehr Fehlversuche

Christoph,

vielleicht schaust Du mal nach, wer als Benutzer/Owner/User und was als Gruppe eingetragen ist.
Als HostEurope Kunde habe ich sicher andere Bezeichner, andere Strukturen als Du, aber eine ähnliche Dateiverwaltung wird Dir Dein Hoster auch bieten, denke ich.
Diese Dateiverwaltung brauchte ich dann, wenn es selbst mit Filezilla nicht möglich war, etwas auszurichten.

In meinem Fall sieht es wie folgt aus:
Besitzer/Benutzer fast aller Ordner ist ftpxxxxxx (wobei xxxxxx meine Web-Paketnummer ist, numerisch) und als Gruppe ist wpxxxxx eingetragen.
Fast deshalb, weil einige wenige Ordner mit wpxxxxx / wpxxxxx als Besitzer und Gruppe erscheinen und diese wenigen sind in den letzten Tagen "auffällig" gewesen.
Zum Beispiel der /wp-content/plugins Ordner, als eine Aktualisierung eines AntiSpam Plugins fehlschlug.
Welcher Besitzer in welchem Fall nun wirklich richtig ist, weiß ich schlicht nicht.
Zurück zu Deinem Problem:
eventuell kannst Du mittels Deiner Dateiverwaltung, oder wie sie auch immer heißt, die aktuellen "Besitzverhältnisse" der fraglichen Upload-Ordner feststellen?

Gruss
Manfred

PS: wenn Du Dir als FTP-Nutzer die Rechte erhöhst, kannst Du dann wieder in den Upload-Ordner schreiben?

Zitat von infected

Hm... Also ich würde niemals auf die Idee kommen, an den Rechten der einzelnen Dateien/Ordner (außer innerhalb von wp-content) etwas zu ändern, bloß weil mir das ein Plugin sagt...

Nein, hat es nicht. Zumindest nicht im Zusammenhang mit einem WordPress Update.

Ach?
Hatte ich nicht die Ordner /wp-content/themes und /wp-content/plugins explizit genannt?
Ich reagiere auch nicht darauf, was mir ein Plugin sagt... ich reagiere auf Fehlermeldungen des Wordpress-Systems... z.B. darauf, dass die Installation des Plugins mangels Schreibrecht im Ordner /content/plugins fehlgeschlagen ist.

Deinen letzten Satz lasse ich mit seiner schlichten Bestimmtheit einfach mal so stehen...

Zitat von KlyX

Hallo Manfred
...
Bei mir gehts weiterhin nicht. Wordpress schafft es zwar wieder den Ordner 2012 anzulegen... hat aber dann keine Schreibrechte und kann 01 nicht anlegen (siehe erster Post von mir in diesem Thread).

Gruss
Christoph

Christoph,

hast Du mal versuchsweise die Ordnerstruktur /2012/01 per Filezilla angelegt, ausreichend Rechte zum Schreiben erteilt und versucht, ob die Mediathek dann diese mundgerecht vorgelegten Ordner bestücken kann?
Wenn dies funktioniert, würde ich einfach das Jahr auf diese Art anlegen (/02 /03 ... ).

Gruss
Manfred

Zitat von B-52

das ist mehr als logisch. So eine Bastlerei die du hier machst kann niemals funktionieren...

eine etwas gewagte Aussage!
(und eine, die ich in dieser Art in diesem Forum nicht erwartet hatte...)

Eine solche "Bastlerei" blieb auch mir nicht erspart, um letztlich in kleinen Schritten das Problem zu lösen.
Manchmal liegt es nahe, die Verzeichnisse / Ordner, die automatisch angelegt werden sollten, händisch anzulegen und ggf. wieder zu löschen, um etwas anderes zu probieren.

Auch wenn es hier, in diesem Zusammenhang leicht OT sein wird:
Nach der Neuinstallation von WP3.3.1 (unter Verwendung der vorherigen Datenbank) waren etliche Dateirechte deutlich rigider eingestellt, als nach den Vorschlägen des Plugins "WP-Security Scan".
Und selbst nach dem Nachziehen auf diese Dateirechte musste ich zusätzlich für /wp-content/themes/ und /wp-content/plugins/ die Rechte erweitern!
(leider habe ich mir keine Notizen dazu gemacht, kann also nicht mehr genaue Hinweise geben).
Jetzt, nachdem soweit alles läuft und ich vorerst kein Theme und kein Plugin installieren werde, habe ich die Dateirechte wieder auf Werte zurückgeführt, wie sie der Auflistung von WP-Security Scan zu entnehmen sind.
Langer Rede, kurzer Sinn:
Es hat offensichtlich spürbare Änderungen in den Lese-, Schreib- und Ausführungsrechten gegeben und meine Probleme lagen darin begründet.

Schönes Wochenende
Manfred

Kollegen und Leidensgenossen,

bei mir funktioniert es wie folgt:
dem Verzeichnis /wp-content/uploads/ die Dateirechte "775" geben, dann wird durch die Mediathek automatisch und korrekt das Verzeichnis /2012/01 angelegt und ein Bild im Original und in drei Größen gespeichert.

Das Verzeichnis /wp-content/ hat bei mir "774", das WP-Security Scan Plugin schlägt "755" vor.
Ich werde es nachträglich entsprechend ändern.

Manfred

so, Kollegen, ich habe es!!

Mit Filezilla das Upload-Verzeichnis /uploads/2012/01 mit "776" berechtigt, öffentlich beschrieben zu werden.
Leider hatte ich das Verzeichnis /2012/01 bereits mit Filezilla händisch angelegt, kann also nicht behaupten, dass es grundsätzlich funktioniert...

Wartet mal ... ein Gläschen Roten... dann werde ich noch einmal die Basis wiederherstellen, also alle Probe-Uploads löschen/entfernen, Datenbank optimieren, per Filezilla die /2012/01 löschen und dann das gleich Prozedere noch einmal von vorne.
Ich melde das Ergebnis!
("... melden macht frei...")

Manfred

so, jetzt mal ganz langsam... :-)
Einen Schritt bin ich weiter:

MEIN Fehler war, dass in den Einstellungen zur Mediathek, die ich bis eben nicht überprüft hatte, noch der alte Pfad des ehemaligen Blogs eingetragen war! Dennoch klappt der Upload ohne jegliche Fehlermeldung... scheinbar...

(ich habe mein Blog in den letzten Tagen um eine Verzeicnisebene tiefer verlegt, die Pfadnamen geändert usw., die Probleme eines einfachen Updates auf 3.3.1 haben mir wohl nicht gereicht... ).

Also, Pfad zur Bilderablage war falsch, ist nun geändert...
nun sollte alles gut sein!?

Aber nun erhalte ich beim Upload, ob alte Methode per Browser oder mittels neuem Verfahren, folgende Fehlermeldung, die m.E. - wieder einmal - auf fehlende Rechte zeigt:
"Permission denied in /..../wp-admin/includes/file.php on line 348" und
"Cannot modify header information - headers already sent by (output started at /...../wp-admin/includes/file.php:348 ) in /....../wp-includes/pluggable.php on line 866"
(Die Punkte ersetzen meine realen Pfade auf dem Server)
Mit der Fehlermeldung bezgl. Zugriffsverweigerung hoffe ich weiter zu kommen, die zweite Meldung sagt mir adhoc erst einmal nichts.

Schau mer mal...

Manfred