Beiträge von Autor33

Im Customizer habe ich bislang noch nie etwas gemacht... aber in die Customizer-Box für CSS-Code ein paar Zeilen reinkopieren und speichern schaffe ich noch.
Also wenn ich mit dem FF auf das Bild klicke und per "Element untersuchen" den Inspektor aktiviere, sehe ich rechts u.a. folgenden Code:
.block-type-content div.entry-content img {
max-width: 100%;
height: auto;
width: auto;

Das müsste ich nun abändern wir vorgeschlagen und noch den Selektor für genau das eine Bild ergänzen bei .block-type-content div.entry-content img ?

width: 100%;
max-width: 368px;
height: auto;
width: auto;

Wäre dann wohl richtig, 368px ist die gewünschte kleine Breite, die nicht angezeigt wird.

Was ist der Selektor für genau dieses Bild? Kommt da das wp-image-310 hinten noch dazu, also dann:
.block-type-content div.entry-content img wp-image-310 ?

@b3317133:
Es ist nur eine Testseite (eine Kopie einer bestehenden Seite), die möglichst nicht "öffentlich" registriert werden sollte und die ich bislang nur als Entwurf gespeichert habe (Preview/draft). Weiß nicht, ob es da eine Möglichkeit gibt...Vielleicht wenn ich richtig speichere und dann die URL per PN mitteile, aber eine PN hier wird von Crawlern ebenfalls gelesen, schätze ich.
Kann ich noch weitere Infos nachliefern, die du brauchst?

Vielleicht noch wichtig: Die automatische responsive-Funktion von WP, die beim Hochladen versch. Größen erstellt und per srcset einfügt, habe ich in den media-Settings deaktiviert (überall "0" eingetragen). Deshalb bekomme ich beim Hochladen von Bildern bei den Attachment-Angaben nur "full-size" als einzige Option. Aber wie gesagt, selbst wenn ich das lösche im img-tag, ändert es nichts.

@Sailor56:
Die Breite zwei Mal definieren?
Diese CSS-Anweisung in meinem Stylesheet betrifft alle Bilder. Wenn ich das so ändere, hat das Auswirkung auf die Anzeige aller anderen Bilder meiner Site, vermute ich?

Grüße,

Autor33

Hallo,
vielleicht kann mir jemand erklären, warum bei einem großen Bild mit den tatsächlichen Maßen von 736 x 414px die manuell im Code korrigierte kleinere width/height-Angabe von 368 x 207px keinerlei Wirkung zeigt?

Das Bild wird nach Einfügung mit ca. 650px Breite angezeigt, also der max. Spaltenbreite für den Content (Artikel). Diese max. Spaltenbreite wird respektiert, also das Layout nicht zerstört, aber die von mir gewünschte kleine Größe bleibt unbeachtet.

Ich habe in meinem CSS-Stylesheet für alle einzelnen Content-Bilder
max-width: 100%;
height: auto;

festgelegt, aber da es ein "max"-width ist, sollte das doch den manuellen width/height-Angaben nicht im Wege stehen?

Der img-Code nach Einfügen des Bildes sieht so aus:
<img src="http://www.der-weg-nach-hause.de/wp-content/uploads/blabla.jpg" alt="blabla" width="736" height="414" class="aligncenter size-full wp-image-310" />

Wenn ich jetzt width/height manuell ändere und sogar das "size-full" lösche, bringt das beides leider gar nichts.

Hat jemand eine Erklärung?

Grüße,

Autor33

Hallo,
ich möchte einige fertig erstellte JSON-LD schema markups in meine WP pages einfügen, also in den WP Quellcode. So soll z.B. die Homapage ein "LocalBusinessMarkup" bekommen, ein "Article"-markup für bestimmte Contentseiten usw.
Es geht mir nicht ums Erstellen des Codes, sondern nur um das Einfügen der fertigen JSON-Codes (ein script-tag, der aber kein ausführbares JavaScript enthält, sondern nur Metadaten).

Ich möchte dazu weder ein extra Plugin verwenden noch den Google Tag Manager, sondern suche vielmehr eine manuelle, möglichst einfache, zuverlässige und langfristige (nicht bereits beim nächsten WP/theme-Update tangierte) Methode.

Ich habe im Web Beiträge gefunden, die das per WP custom fields lösen, habe diese aber noch nie gebraucht.

1. Empfehlen sich custom fields dafür oder welche Alternativen gäbe es?
2. Lassen sich damit auch Reviews und Sternebewertungen einfügen?
3. Wie kann ich festlegen, wo genau das markup plaziert wird?
Theoretisch kann man es überall plazieren; sofern es der Ladezeit nicht schadet, wohl am besten im head.

Danke für Anregungen,

Autor33

Ein normales PW-Reset per "Lost-your-PW-Link" hat geklappt. Die Ursache des fehlschlagenden Logins mit dem unveränderten WP-PW ist aber noch unklar im Moment.

Zitat von b3317133

Notiere per phpMyAdmin den bestehenden Hash, dann kannst Du ihn auch wieder manuell einspielen, falls nötig.

Und was lässt der Webserver denn nicht zu, das Du lokal machen musst und das dann aber über das Einspielen des Duplicator Pakets vom Ergebnis her irgendwie doch zugelassen wird?

Und wie lautet die "seltsame Fehlermeldung"?

Es geht darum, das alte theme mittels eines Konvertierungsplugins auf dessen Nachfolger umzuswitchen. Das Konvertierungsplugin tut das in zwei Schritten, zuerst legt es ein paar neue Tabellen an (für das neue theme) und dann befüllt es diese. Die neu angelegten Tabellen bleiben aber leer, das Beschreiben erfolgt nicht: "keine Einträge", "0 rows" laut phpMyAdmin.
Das Plugin bringt keine Fehlermeldung und auch per "display errors on" wird keine Fehlermeldung gebracht. Vermutlich irgendein Sicherheitsfeature auf dem Server. Der Support findet aber nichts.
Deswegen der ganze Zinnober. Würde es normal funktionieren, bräuchte ich alles andere (Duplicator ect.) nicht.

Für den Hostersupport hatte ich einen eigenen Account eingerichtet, fällt mir noch ein. Der ist mit dem Restore der DB vom 05.07. wieder verschwunden, weil am 05.07. gab es den noch nicht. In phpMyAdmin bin auch nur Ich als Admin in der wp_users jetzt zu sehen. Vielleicht hat es aber doch damit zu tun?

Und noch eine letzte Info kann ich geben: Die Site hat (noch) kein SSL/https, aber ins Backend komme ich immer mit einer entsprechenden Ausnahmeregelung im Browser per https rein. UpdraftPlus hat deswegen vor dem Restore eine Warnung gegeben (sinngemäß "restored wird http-Site, jetzt hat die Site aber https"). Hätte ich wohl ignorieren können, habe dann aber kurzfristig die Browser-Ausnahme gelöscht und das Restore mit http (und ohne Warnung von UpdraftPlus) gemacht.
Login funktioniert aber weder mit http noch mit https.

Zitat von b3317133

Und wie lautet die "seltsame Fehlermeldung"?

Die seltsame Fehlermeldung lautet
"Warning in .\libraries\sql.lib.php#615
count(): Parameter must be an array or an object that implements Countable".
Siehe Anhang.
Das Installieren von Mamp, das Anlegen der DB und das Importieren des Klons hat ganz normal funktioniert. Warum jetzt plötzlich diese Fehlermeldung in den Tabellen, k.A.
Ein paar Quellen in G sprechen von altem PHP, Mamp nimmt immer das neueste, laut Einstellungen 7.2.1. Die Site hatte 7.0 auf dem Server. Der Hoster unterstützt auf dem Webserver 7.2.3, 7.1.6, 7.1.10 und 7.1.15.

Zitat von b3317133

Nein, Du notierst den Hash und machst dann den Account wieder zugänglich, mit einem MD5 Hash via phpMyAdmin.

Dann loggst Du Dich ein

Dann setzt Du via WordPress in Frage kommende Passwörter...

In Frage kommende Passwörter? Hm, ich habe noch nie das PW geändert seit der Installation. Da liegt wohl die Herausforderung des Vorschlages.
Der im Klartext sichtbare Benutzer in der phpMyAdmin ist jedenfalls unverändert korrekt.

Zitat von b3317133

Mit anderen Installationen kann man die Hashes nicht vergleichen, da auch die _KEY und _SALT Werte eine Rolle spielen, die je Website unterschiedlich sind bzw. sein sollten.

Das erklärt, dass das gleiche PW bei unterschiedlichen Sites unterschiedliche Hashes hat.

Gibt es eigentlich in WP eine Automatik, dass nach dem 5. (?) fehlgeschlagenen Loginversuch dann alle nachfolgenden für eine bestimmte Zeit ebenfalls abgelehnt werden, obwohl der 6. vielleicht der richtige wäre?

Für heute reicht's mir, ich geh jetzt ins Bett.

Zitat von danielgoehr

Ganz generell:
Der Zweck eines Hashs ist, dass man daraus eben nicht das Passwort im Klartext wiederherstellen kann. Genau deshalb werden die Passwörter in der Datenbank gehasht.

Abgesehen davon, dass du gerne wüsstest, was für ein Passwort dort drin steht (was aus o.g. Grund schwer wird): Kannst du dich denn wieder einloggen, wenn du das Passwort, wie von @b3317133 beschrieben/verlinkt, zurücksetzt?

Ich habe es bisher nicht ausprobiert, das WP-PW einfach zu ändern, weder über phpMyAdmin noch über den "PW vergessen"-Link. Der Support des Hosters weiß auch nicht, warum das unberührte WP-PW nicht mehr funktioniert und empfahl dasselbe: Einfach ein neues PW anlegen und wenn's funktioniert, dann ist alles gut und es war halt ein unerklärlicher "Sommer-Käfer".
Diese Option bleibt mir ja immer, einfach PW ändern und vermutlich geht es dann mit dem neuen PW.

Ich will aber eine lokal etwas veränderte Version der Site per Duplicator-Klon wieder live einspielen und das alles nur wegen einer anderen Unerklärlichkeit auf dem Webserver, der etwas nicht zulässt, was ich daher lokal machen muss, nämlich bestimmte Tabellen befüllen.

Beim Einspielen des Klons live wird immerhin die gesamte Installation gelöscht und neu angelegt, was ich noch nie gemacht habe. Wenn dann beim Einspielen des neuen Klons auf der Live-Site wieder irgendetwas nicht plangemäß läuft, dann kennt sich kein Schwein mehr aus, woran das dann liegen könnte, weil dann habe ich
- ein ungelöstes Webserver-Problem (das ich mittels der gesamten Aktion per lokal/Mamp/Duplicator alternativ lösen will)
- eine zwar gelöste PW-Sache, die aber ungeklärt blieb
- seit kurzem eine seltsame Fehlermeldung in der lokalen DB in allen Tabellen, die auch noch ungeklärt ist

Also aus dem größeren Zweck heraus wäre es mir schon recht, nicht ein Fragezeichen auf das nächste zu schichten, selbst wenn es irgendwie "funktioniert". Wenn es nicht anders geht, o.k. dann würde ich notfalls halt ein neues PW anlegen und wenn's einloggen damit klappt, dann das PW-Rätsel ein Rätsel bleiben lassen.

Die betreffende Website habe ich vor mind. 2,5 Jahren als Wordpress-Site gestartet.

Zitat von b3317133

Notiere Dir den jetzt existierenden Hash, setze einen neuen MD5 Hash, loggge Dich ein, ändere das Passwort auf alle möglichen Variante, die es sein könnten, vergleiche jeweils den Hash der Datenbank mit dem notierten, das bringt ggf. Licht ins Dunkel...

Du meinst, ich solle einfach mal verschiedene, in Frage kommende PW neu anlegen per phpMyAdmin, schauen, was per MD5 dann für ein Hash erzeugt wird und wenn es der gleiche ist wie der Notierte, dann weiß ich das angelegte PW (in Klarschrift)?

Ich habe mal den dort sichtbaren Hash-Wert verglichen mit zwei anderen Sites/DBen, die das gleiche Wordpress-Passwort haben. Der ist jeweils verschieden, drei unterschiedliche Hash-Werte, obwohl das gleiche PW? Die eine Site ist etwas über drei Jahre alt, die andere nicht ganz drei Jahre.

Zitat von b3317133

Das DB-Passwort ist nirgends in der DB hinterlegt, nur in wp-config.php

Gut, dann ist das schon mal 100%ig ausgeschlossen.

Zitat von b3317133

Wurden ggf. die xxx_KEY oder xxx_SALT Werte in der wp-config.php geändert?

Ich habe manuell nur das Datenbank-PW geändert und da das Restore nur DB und themes betraf, nicht WP selbst (kann man mit UpdraftPlus meines Wissens auch gar nicht backupen und restoren), hat auch das Restore die wp-config nicht angerührt. Die langen Salt-Zeichenketten könnte ich evtl. prüfen, ich glaube, die bei der Erst-Installation speziell gesichert zu haben auf einem USB-Stick. Kanns mir aber nicht vorstellen.

Zitat von b3317133

Ein neues Passwort via phpMyAdmin kannst Du mit MD5 hashen und in beim Benutzer eintragen, in den Suchmaschinen gibt es dazu eine Vielzahl von Anleitungen. Bestehende Passwörter sichtbar machen kann man nicht, und das ist auch gut so.

Das heißt, auch als Admin kann man ein Mal eingetragenes/vorhandenes PW in phpMyAdmin nicht mehr in Klarschift sichtbar machen? Auch nicht außerhalb der DB, z.B. indem man den hash-wert in ein entsprechendes MD5-Tool eingibt und quasi den üblichen Vorgang umdreht? (Ich habe jetzt einfach mal meine Fantasie spielen lassen, sicherheitstechnisch wäre das natürlich nicht gut für WP-Webmaster).

Das wäre in meinem Fall jetzt blöd, ich würde brennend gerne wissen, was da für ein PW drin steht.

Keiner?

Wenn es am Datenbank-PW läge, sollte die Website überhaupt nicht aufrufbar sein, oder? Da sie das ist, kann es also wohl nicht am Datenbank-PW liegen. Wobei ich nicht weiß, ob das überhaupt irgendwo in der (neu eingespielten) DB hinterlegt wäre (ähnlich dem Wordpress-PW in der users-Tabelle).

Da ich das Wordpress-PW gar nicht geändert habe, verstehe ich zwar nicht, warum und wie mit einer eingespielten DB-Sicherung das Login nicht mehr klappen sollte, aber es sieht so aus. Jetzt wollte ich mal schauen in der phpMyAdmin, was für ein PW dort eingetragen ist. Leider sieht man es dort aber nur in einer "Hash"-Ansicht, einem langem Zahlen/Buchstaben-Wurm. Kann man das - nur zu Ansichtszwecken - nicht wenigstens kurzfristig mal in Klarschrift sichtbar machen, was da für ein PW tatsächlich in der wp-users als Wordpress-PW eingetragen ist?

Hallo Sepp55,
unsere postings haben sich gerade überschnitten. Danke für deinen Beitrag. Ich versuche es nochmal verständlicher.

1. Am 07.07. habe ich auf Aufforderung des Hosters das Kunden-PW für meinen Hosting-Account, meine Hoster-E-Mails und das Datenbank-PW geändert. Letzteres in der wp-config und in meinem Kundenaccount beim Unterpunkt "MySQl-Datenbanken - Edit - PW ändern/prüfen".

2. Das normale Wordpress-PW habe ich am 07.07. nicht geändert. Ebenso wenig das PW für den zusätzlichen Admin-htaccess-Login.

3. Diese neuen Passwörter sind alle noch aktiv und gültig. Ich logge mich damit in den Kundenaccount ein, schaue meine Mails an und das neue DB-PW steht unverändert in wp-config und im Kundenaccount bei der betreff. MySQL-DB. Bis gestern war "logintechnisch" alles in Ordnung.

4. Gestern abend habe ich die Sicherung vom 05.07. eingespielt, DB und Themes. Seitdem klappt der Wordpress-Login nicht mehr. Htaccess-Login ja, der anschließende WP-Login nicht.

5. In wp-config und im Kundenaccount/MySQL-DB ist nach wie vor das neue Datenbank-PW vom 07.07. drin.

Die Sicherung vom 05.07. sollte eigentlich kein Problem mit dem normalen Wordpress-PW haben, da ich dieses am 07.07. gar nicht geändert habe.

Was ich geändert habe, war das Datenbank-PW. Das steht da noch immer so in der wp-config und im Kundenaccount wie am 07.07. neu angelegt. Kann damit das Restore dennoch ein Problem haben?

Kann das geänderte Datenbank-PW ursächlich sein oder doch das normale WP-PW, das ich aber gar nicht geändert habe am 07.07.?

Zitat von Autor33

Hallo,

Die Sicherung war vom 5.7. und am 7.7. musste ich meine Passwörter ändern, einschl. des DB-Passwortes. Der Hoster hat ein Sicherheitsproblem entdeckt und eine Rundmail geschrieben. Ich dachte jetzt, das wäre die Ursache fürs misslingende Login, denn in meiner nicht vom Restore erfassten wp-config ist das neue PW und restored habe ich aber eine DB mit noch altem PW.

Wenn ich in meinem Kunden-Account bei der DB nachschaue, ist aber auch dort nach wie vor das neue PW drin. Also doch alles Paletti und es liegt an etwas ganz anderem? Oder übersehe ich etwas?

Um Missverständnisse zu vermeiden: Ich spreche hier immer nur vom Datenbank-PW. Das "normale" Wordpress-PW habe ich am 07.07. nicht geändert. Mit dem normalen Wordpress-PW sollte das Restore vom 05.07 also keine Probleme haben.

Hallo,
ich habe eine Sicherung von UpdraftPlus in mein WP eingespielt und zwar die DB und Themes. Seitdem kann ich mich nicht mehr einloggen.

Gleich nach dem erfolgreichen Restore mit UpdraftPlus meldete mir WP seltsamerweise eine abgelaufene Session, so dass ich mich neu anmelden musste. Es klappt aber nicht mehr. Der htaccess-Admin-Login klappt noch, aber der anschließende WP-Login nicht mehr. Hab's schon 10 mal probiert, Vertippen also ausgeschlossen. Mit anderem Browser klappt's auch nicht.

Die Sicherung war vom 5.7. und am 7.7. musste ich meine Passwörter ändern, einschl. des DB-Passwortes. Der Hoster hat ein Sicherheitsproblem entdeckt und eine Rundmail geschrieben. Ich dachte jetzt, das wäre die Ursache fürs misslingende Login, denn in meiner nicht vom Restore erfassten wp-config ist das neue PW und restored habe ich aber eine DB mit noch altem PW.

Wenn ich in meinem Kunden-Account bei der DB nachschaue, ist aber auch dort nach wie vor das neue PW drin. Also doch alles Paletti und es liegt an etwas ganz anderem? Oder übersehe ich etwas?

Danke für die Antworten.

Zitat von JABA-Hosting

Du hast bisher nicht geschrieben das du UpdraftPlus getestet hast?

Für Standard Webseiten ist UpdraftPlus ausreichend. In den Logs steht es meist ganz gut ob das Backup fehlerfrei lief.

Per SSH ist es natürlich besser, aber rsync ist nicht das Tool um Backups zu machen. Mit rsync synchronisiert man Daten und mysql kann man nicht einfach synchronisieren, per rsync.

Mit SSH musst du dir ein paar Scripte basteln um ein Backup zu erstellen, die du dann via Cron täglich laufen lässt. Mit rsync kannst du dann deine Backupdaten schieben wohin du willst.

Ich habe das mit rsync schon wieder verworfen.

Ich könnte mir noch eher vorstellen, ergänzend zu UpdraftPlus auch Duplicator zu verwenden, weil damit - anders als bei UpdraftPlus - ein kompletter Klon mit WP und htaccess, robots ect. gemacht wird. Außerdem braucht das Restore keinen Backend-Zugang, weil man alles immer per FTP und Browser macht.

Das zeitlich gesteuerte Backup hat funktioniert. Und der nächste wird wieder korrekt angekündigt. Schön.

Aber dass der eigene UpdraftPlus-Support explizit die falsche Auskunft gibt und behauptet, es beträfe alle PW-Einrichtungen per htaccess, auch den Admin-PW-Schutz...

Ein manuelles Backup heute morgen hat funktioniert.
Das erste zeitgesteuerte kommt erst morgen - wenn es funktioniert.

Seltsamerweise wird bei jeder Aktion in den Settings ohne mein willentliches Anstoßen eines Backups ein solches gemacht. Ich habe z.B. heute nachmittag von wöchentlich auf täglich umgestellt, damit ich nicht fast 1 Woche warten muss, um zu sehen, ob der PW-Schutz tatsächlich das zeitlich gesteuerte Backup aushebelt. Zack, hat er sofort ein Backup gemacht, laut "Existing backups" und auch auf dem Webserver, alle 5 Teile. Der Eifer ist ja schön, aber...

Laut den Plugin-Entwicklern geht es um keine Plugin-Besonderheit, sondern um den dadurch deaktivierten Wordpress scheduler, den das Plugin braucht. WP selbst empfiehlt den Admin Passwortschutz und nennt als fehlende Funktion im Anschluss nur eine Sache:
"This prevents normal site visitors from accessing /wp-admin/admin-ajax.php." Siehe https://codex.wordpress.org/Hardening_WordPress#WP-Admin
Von einem teilweise oder ganz deaktivierten scheduler hingegen steht da nichts.

Zitat von JABA-Hosting

Sollte ohne Probleme funktionieren.

Nach 5 Tagen hat sich der UpdraftPlus-Support doch noch gemeldet und sagt, dass auch ein Admin-PW-Schutz die zeitlich gesteuerten Backups stören soll. Ich solle daher einen geeigneten htaccess-Code verwenden, um das zu beheben.

Verstehe ich nicht, warum das den Wordpress Scheduler stören soll, wenn ich ein zusätzliches Admin-Passwort per htaccess eingerichtet habe, aber ich probiere es mal aus. Dachte, das mögliche Problem hat damit zu tun, dass Besucher Zugang haben müssen, weil durch solche Visits die Zeitsteuerung ausgelöst wird. Und das geht ja nach wie vor.