Beiträge von Marcus[IS]

Doch man könnte theoretisch auch heute noch die Sprachdatei manuell installieren. Sollte gehen wenn du die .po und .mo Srachdatei herunterlädst und in den Ordner languages deiner WP Installation hochlädst. An für sich sollte WordPress das dann erkennen und dir die Datei in der Auswahl anzeigen.
https://translate.wordpress.org/projects/wp/dev/de/formal

Doch ich befürchte das würde dein Problem nur bis zum nächsten größeren Update verschieben, da ja auch Sprachdateien einem Update unterzogen werden.
Du könntest ja mal im Backend das Entwicklertool deines Browser aktivieren und schauen ob es eine Fehlermeldung gibt, wenn du die entsprechende Sprachoption einstellen willst.
Oder mal mittels wp-config.php den Debugmodus aktivieren. Manchmal gibt das auch schon brauchbare Meldungen heraus, mit denen man die Ursache erforschen kann.

Hi,

wie hast du denn genau versucht das Forum einzubinden?

Normalerweise sollte eigentlich funktionieren, wenn man im Editor den Textmodus Tab Drückt und den Code für den iFrame dann eingibt.

Link zur betroffenen Seite wäre auch hilfreich. ;)

Hi,

habe mir die Datei mal genauer angesehen.

Dort ist dieses ab Zeile 765 enthalten;

.widget a:active {
    background-color: #000000 !important;
    color: #ffffff !important!;
}




.widget a:hover,
.widget a:focus {
    background-color: #000000;
    color: #ffffff;
}

Hast du das mit dem active eingefügt?
Falls ja tausche mal die Blöcke aus, vielleicht läuft es dann.
Auf der von mir verlinkten Seite steht ja wörtlich;

Zitat

When setting the style for several link states, there are some order rules:

a:hover MUST come after a:link and a:visited
a:active MUST come after a:hover

Die Reihenfolge scheint da maßgeblich zu sein. Also der Block mit der active Anweisung muss unter dem Block der hover Anweisung stehen.

Oder versuche es so;

.widget a:hover,
.widget a:focus,
.widget a:active {
    background-color: #000000;
    color: #ffffff;
}

Die Reihenfolge der Pseudo-Selektoren im CSS muss wie hier :link, :visited, :hover, :focus, :active sein. Ansonsten überschreibt z.B. :hover den Selektor :active.

Hast du denn die Klasse des Widget berücksichtigt?

In Widgets werden die CSS Klassen manchmal ein wenig erweitert.
So könnte eventuell angegeben sein class="widget widget_links", so würde die CSS Anweisung also .widget widget_links lauten.
Ist jetzt nur ein Beispiel aus einem meiner WP Installationen.

Es ist in dem Fall wichtig die genaue Bezeichnung in die CSS einzutragen.
Falls dein Theme das unterstützt, kannst du auch unter Design/Customizer die Änderung unter Zusätzliches CSS Eintragen, dann musst du nicht in der CSS des Themes herumbasteln. ;)

Manchmal muss man auch die Brechstange ansetzen, wenn eine CSS Änderung akzeptiert werden soll.
So zum Beispiel;
color: #000 [COLOR=#ff0000]!important[/COLOR];
Ist zwar nicht die genialste Lösung, aber manche Themes können ziemlich zickig sein, wenn man an der CSS etwas ändern will.

Mojn,

Könntest probieren das über style.css mittels Ansprechen der entsprechenden CSS Klasse umzusetzen.
https://www.w3schools.com/css/css_link.asp

Hi,

normalerweise sollte unter Einstellungen/Allgemein Bei der Sprache ein großes Menü auftauchen.
Im oberen Teil werden die bereits Installierten Sprachdateien angezeigt und Darunter dann ein Punkt Verfügbare Sprachen, in denen dann auch die Formale Deutsche Sprachdatei (Sie) aufgelistet ist.

Hast du mal die Plugins deaktiviert, oder (falls nicht verwendet) eines der WordPress Standard Themes ausprobiert?
Es kann schon mal vorkommen, das Plugin- oder Theme Funktionen sich mit Funktionen im Adminbereich in die Haare bekommen.

Du müsstest noch ein wenig daran arbeiten.

Wenn man immer die Cookie Akzeptieren Meldung auf der Hauptseite angezeigt bekommt, ist das etwas nervig.
Eventuell mal schauen, ob ein anderes Plugin da besser wäre.

Ansonsten ist es ganz okay. Auch wenn die Rechtschreibung bemängelt wird.

Man schreibt halt "frei Schnauze". ;)

Hi,

ja das mit dem Child-Theme ist korrekt, wenn man Theme Dateien ändern will.
Du musst das Child-Theme halt nur gemäß Codex erstellen.
https://codex.wordpress.org/Child_Themes

Zitat

[COLOR=#333333]Da ich nicht mehr alle durchgeführten Änderungen kenne, stellt sich für mich die Frage, was ich tun kann, dass das Child Theme auf dem Stand ist, wie derzeit das Parent Theme aussieht. [/COLOR]

Ist ein wenig aufwändig, aber durchaus machbar, wenn man die Dateien zum Beispiel mit dem Programm WinMerge vergleicht. So bekommst du heraus welche Dateien du geändert hattest.
Du musst nur das jetzige verwendete Theme per FTP Programm auf deine Festplatte laden und daneben noch das Original Theme. Dann gehst du mit WinMerge hin und lässt die Dateien vergleichen. Das Programm gibt dir dann aus, wo Unterschiede in den Quelltexten bestehen.
Du kannst dann hingehen und nur die geänderten Theme Dateien im Child-Theme verwenden.
Für die functions.php des Child-Theme solltest du aber nur die Änderungen in eine extra im Child-Theme Ordner angelegte functions.php verwenden, da du sonst Fehlermeldungen bezüglich doppeltem Funktionsaufruf angezeigt bekommst.

Bezüglich der Einstellungen des Theme und dem Zusammenhang mit etwaigen Datenbankeinträgen kann ich jetzt nicht so weiter helfen, aber ich denke mal das du diese dann nochmals durchführen müsstest, da du ja ein Child-Theme einsetzt und da würdest du ja dann quasi ein neues Theme aktivieren.

Muss du nach Preloader Plugins suchen.
https://de.wordpress.org/plugins/search/preloader/

Gibt so diverse, bei denen man auch eigene Logos verwenden kann.
Schätze mal ein Fade in/out Effekt dürfte mit Sicherheit auch bei dem einen, oder anderen Plugin dabei sein.

Mojn,

da es ein so genanntes Premium Theme ist, können wir da eigentlich gar nicht helfen. Da wäre der Themeauthor in der Pflicht.
Man kann daher jetzt nur ganz pauschal versuchen Licht in die Sache zu bringen.

Es gibt bei WordPress eine so genannte Seiten Hierarchie, wo bestimmt ist welche Datei für was zuständig ist.
Ist sehr hilfreich, wenn man eigene Child-Themes basteln will.
https://developer.wordpress.org/themes/basics/template-hierarchy/

Du schreibst, dass du nur die header.php bearbeiten kannst.
Sind sonst keine anderen Dateien im Child-Theme Ordner vorhanden?
Also außer style.css und functions.php?
Falls nicht, wurde für das Child-Theme lediglich die header.php umgebastelt und gemäß Hierarchie Abfrage innerhalb WordPress werden alle anderen benötigten Dateien aus dem Parent-Theme (Supreme) geladen.

Und genau da würde jetzt der Hase im Pfeffer liegen.
Änderungen an den Original Theme Dateien, also in deinem Fall dem Hotelbooking und dem Supreme, würden bei einem Update der Themes wieder verschwinden.

Mojn,

versuche mal einen anderen Browser wie zum Beispiel Chrome.

Ein Kunde von mir hatte mit seiner Seite genau das selbe Problem.
Da hatte sich dann herausgestellt, das die Kaspersky Suite die er installiert hatte für das Login Problem mit Firefox verantwortlich war.
Scheinbar setzte sich der Schutzmechanismus so stark im System fest, dass Firefox trotz gemachter Freigaben nicht dazu zu bewegen war die Logindaten korrekt zu verarbeiten.
Hatte ein paar Tage gedauert, bis wir dahinter kamen. Wer verdächtigt schon eine Software, die ein System an für sich schützen soll? ;)

Als er sich dann Chrome installierte und es damit dann versuchte, kam er wieder ohne Probleme auf seine Seite und das Login Problem ist bis heute nicht mehr aufgetaucht.

War 'ne nette Zeit. Vielleicht liest man sich ja wieder irgendwann hier.

Ähm, der Screenshoot ist ja von deiner ersten Feststellung mit der Begrenzung der Uploadgröße.
In deinem Fall also 32MB Dateigrößen Begrenzung und wenn das File größer ist, wird der Upload Serverseitig abgebrochen, was auch korrekt ist.

Aber bezog sich deine Frage denn nicht danach auf den Umstand den Film per FTP Programm in das WP Verzeichnis hochzuladen und dann einen Link zu diesem File zu setzen?
Oder habe ich da was falsch verstanden?

Hi,

selbst wenn du den Film per FTP in das WP Verzeichnis hochgeladen hast und dann in deinem Artikel, oder auf der Seite einen Link dazu setzt, sollte an für sich keine Passwort Abfrage erfolgen.
Zumindest hatte ich bisher nie so etwas bei meinen WP Installationen feststellen müssen.

Hast du mal einen Link zum Problem?

Hi,

du könntest ja mal schauen, ob das Plugin eventuell Einträge in die .htaccess Datei in deiner WP Installation geschrieben hat und das eventuell noch vorhanden ist und deshalb den Fehler verursacht.
Im Abschnitt Basic WP kannst du nachlesen, was auf jedenfall in der .htaccess vorhanden sein sollte.
https://codex.wordpress.org/htaccess

Additional in that case;
https://codex.wordpress.org/Installing_WordPress
There's also an forum for english, so you can ask there, if you have any futher questions.

Zitat von b3317133

Hört sich auf den ersten Blick nach Trojaner im Nutzer-PC oder als Add-On in Firefox an, Firefox mal im Safe-Mode testen.

Ich werde ihm mal eine Systemprüfung nahelegen. Aber bei dem Stichwort Browser Add-On ist mir eingefallen, das Sicherheitssuiten gerne mal eigene Add-Ons in die Browser Packen. Es könnte ja sein, dass auch eines von Kaspersky drin ist und er deshalb diese Probleme hat.

https://wordpress.org/plugins/automatically-paginate-posts/

Sollte deinen Zweck erfüllen. Zeigt aber so wie ich auf den Bildern sehe nur unten dann die Pagination.

Der Defender lief nicht nebenher, der war deaktiviert. Kapsersky Deaktivieren hatte ich zwar angemerkt aber irgendwie wollte er das nicht so wirklich machen. Wollte ihn jetzt auch nicht dazu nötigen. ;)

Hi @ all,

ich habe auf einer von mir mit betreuten WordPress Seite ein paar äußerst Merkwürdige Begebenheiten festgestellt wenn der Firefox zum Einsatz kommt, die ich mir irgendwie nicht erklären kann.

Nutzer (Websiteadmin) will sich Einloggen und bekommt immer die Meldung, dass das Passwort nicht korrekt sei.
Passwort daraufhin von mir (ebenfalls Admin) geändert und Nutzer konnte sich einloggen.
Am nächsten Tag darauf das selbe Problem.
Also abermals Passwort ändern und alles gut.

Heute das Problem wieder und da kam mir dann der Verdacht auf, dass es wohl am Browser liegt.
Bin ich mal zu Ihm hin und habe das Problem versucht vor Ort zu lokalisieren und da fiel mir dann folgendes auf.

Obwohl im Browser (neueste Firefoxversion) die Cookies und Skripte zugelassen waren und sogar eine Extra Einstellung für die Cookies von der Domain immer erlauben gemacht wurde, zickte das Login herum als ob es kein Morgen gäbe.
Mal waren die Cookies angeblich gesperrt, mal das Passwort falsch.
Wir haben auch immer wieder den Verlauf und die Cookies geleert um auszuschließen, dass alte Daten dazwischen hauen.

Und ich habe vorher ein Plugin installiert, welches Anzeigt welcher User sich wann angemeldet hat und laut dem Protokoll des Plugin wurde der Login als erfolgreich gewertet, obwohl am anderen Rechner nach wie vor der Login als gescheitert angezeigt war.

Wir haben daraufhin auch mal zum Test Chrome installiert und siehe da, der Login war ohne zicken möglich.

Mich würde allerdings mal interessieren, wieso der Firefox da so dermaßen rumzickt, obwohl in den Einstellungen Skripte und Cookies erlaubt sind.

Die betroffene Website liegt zwar bei 1&1, doch die PHP Version ist 7.1.13, PHP Memory Limit ist 256M und WordPress habe ich auch heute Morgen einem Update unterzogen, da eines angezeigt war.

Mir kam auch der Verdacht auf, das die Sicherheitssuite von Kaspersky und Firefox sich da eventuell irgendwo in die Haare bekommen könnten.
Was mir noch in den Sinn kommen könnte ist, dass Firefox sich daran stört das die Seite (noch) kein Sicherheits Zertifikat besitzt, aber daran kann es doch nicht liegen oder?