Siehe Dokumentation zu date_i18n(), auch unter "User Contributed Notes" dort.https://developer.wordpress.org/reference/functions/date_i18n/
Beiträge von b3317133
-
-
Was genau ist denn bei "Einstellungen -> Allgemein -> Datumsformat" eingestellt?
"[FONT=Courier New]j. F Y[/FONT]"?
Und versuche mal, den Code im og. Beispiel von
auf das hier anzupassen:
-
Deaktiviere als erstes mal das Cache-Plugin. Solange das aktiv ist, kann man kaum sinnvolle Fehlersuche betreiben.
Dann schau nach, ob im Menü "Dashboard -> Aktualisierungen" ggf. ganz unten noch "Übersetzungen" fehlen.
Irgendwas stimmt auch mit dem Code der Archiv-Anzeige im Sidebar nicht, da ist ein [FONT=Courier New]<li> .. </li>[/FONT] um alle restlichen [FONT=Courier New]<li>[/FONT] herum zu viel, direkt nach [FONT=Courier New]<ul>[/FONT] und vor [FONT=Courier New]</ul>[/FONT].
-
Die Klasse [FONT=Courier New]C_Taxonomy_Controller[/FONT] kommt lt. kurzer Google-Recherche z.B. im NextGEN Gallery Plugin vor. Wird dieses Plugin verwendet?
Sind sicher alle Pluginordner und -dateien korrekt kopiert worden?
Benenne temporär mal den Ordner [FONT=Courier New]wp-content/plugins/nextgen-gallery/[/FONT] um, erscheint die Meldung dann weiterhin?
Wie genau wurde die URL in der Datenbank geändert? Mit einem Plugin?
-
Man könnte den Mechanismus, der das verursacht, einfach für zwei Wochen abschalten. Sind da irgendwelche "Sicherheit"-Plugins aktiv?
-
Ein meiner Meinung nach denkbar ungünstiger Ansatz, damit schlagen dann ggf. alle möglichen Schreibversuche auf dieses Feld fehl, mit eher unabsehbaren Folgen.
Die gesuchte Tabelle heisst standardmässig [FONT=Courier New]wp_comments[/FONT], siehe auch Database Description, das ggf. angepasste Prefix bekommt man über [FONT=Courier New]$wpdb->prefix[/FONT], siehe auch wpdb Class Reference.[FONT=Courier New][/FONT]
-
Im og. Beispiel wird die Formatierung aus dem Menü "Einstellungen -> Allgemein -> Datumsformat" verwendet.
-
Benutze mal das Formular dieses "ConvertPlug" Plugins, wo immer Du es auch einsetzt, einfach so wie ein normaler externer Benutzer. Wird dann auch ein Account erstellt?
-
Wann/wo genau erscheint der Fehler?
Gleiche PHP-Version vor/nach Umzug?
Wie genau wurde der Umzug gemacht? Mit einem Plugin? Mit welchem?
Was genau bedeutet "habe Datenbank angepasst"?
-
@wppraesenz: Habe Deine Postings in den wordpress.org Foren gesehen und den dort verlinkten Website angeschaut, könnten die Accounts auch aus einem Newsletter- bzw. diesem ConvertPlug Plugin o.ä. stammen?
Du setzt offenbar aktuell die Version 3.2.2 davon ein, und der neuste Eintrag im Changelog des Plugins behandelt genau so einen Fix für einen "Benutzer ohne Rolle".
ZitatVersion 3.2.2 April 11 2018.
- Improvement: Feature to alot WordPress user role to subscribed user. -
Lade mal noch den Inhalt von [FONT=Courier New]wp-content/languages/[/FONT] neu hoch.
Wenn Updates regelmässig derartig schiefgehen, sollte man der Sache auch auf den Grund gehen. Das kann unterschiedlichste Gründe haben, von gehackter Installation über veraltetes Theme bzw. Plugins die irgendwie dazwischenfunken o.ä., bis grundsätzlich untauglicher Hostingaccount.
-
@SirEctor: Wenn keine Rolle angegeben ist, deutet es darauf hin, dass entweder ein Account mit [FONT=Courier New]wp_create_user(..)[/FONT] angelegt wurde, aber noch [FONT=Courier New]..->set_role()[/FONT] fehlt, oder dass jemand den Account z.B. über eine SQL-Injection unvollständig direkt in die Datenbank geschrieben hat.
-
Sieht nach klassischem Hack aus. Ob das durch die neuen Plugins kam, kann man "von aussen" kaum sagen. Wurden die Plugins aus dem offiziellen Repository installiert oder aus irgendeiner anderen Quelle?
Als erstes mal ein Komplettbackup erstellen, alle Dateien im Webspace und die Datenbanken, für spätere Analysezwecke.
Hier eine Kurzbeschreibung wie es dann weitergeht.
Zum Thema "hoffentlich 'nur' ein Troll", sobald Dritte solche Accounts anlegen können, ist praktisch die komplette Installation als kompromitiert zu betrachten.
-
-
Mir ist jedoch aufgefallen, dass beim WordPress Login meine E-Mail Adresse nicht vorgeschlagen wird.
Dann stelle in Firefox ein, dass der Browser Login-Informationen speichern soll. Das hat mit WordPress nichts zu tun.
Außerdem bekomme ich ständig E-Mail von Wordfence, dass sich jemand (Ich) mit Admin Rechten eingeloggt hat.
Das liegt einfach daran, dass bei Dir in Wordfence bei "Alert me when someone with administrator access signs in" ein Haken gesetzt ist.
-
Wird denn "test" ausgegeben, wenn das Seiten-Template benutzt wird? Stimmt der Dateiname der Templatedatei exakt mit dem Parameter überein? Liegt die Datei ggf. in einem Unterverzeichnis, dann muss das Verzeichnis mit in den Parameter, siehe auch Beispiele im Codex. Evtl. hilfreich wäre ein Link zu einer Seite mit so einem Template oder die Angabe, was genau im body-Tag auf einer Template-Seite als class="xxx" ausgegeben wird?
-
Da gibt es viele Möglichkeiten je nach weiterem Context, würde wahrscheinlich sowas nehmen:
-
Schau Dir mal is_page_template() im Codex an.
-
Das über Plesk zu machen, halte ich für sehr ambitioniert. Viel Erfolg.
Alleine schon dieser eine Punkt ist bzgl. Plesk ein "no-go" bzw. nicht nachvollziehbar für mich, ob das wirklich so der Fall ist:
Außerdem macht es mir immernoch Kopfschmerzen, dass ich Wordpress erst im laufenden Betrieb deinstallieren muss, bevor ich die Domain umschalten kann.
Die von mir beschriebene Variante zielt darauf ab, dass man jederzeit einen Rollback zum Original machen kann, wenn beim nächtlichen aktuellen Klon, Integration der Änderungen und Launch was nicht klappt wie gedacht, ganz einfach weil das Original unangetastet bleibt.
Lediglich das Mapping der (Sub)Domains auf den jeweiligen Ordner wird dann via Plesk gemacht, keinerlei Eingriffe in die Daten.
-
Was ist wenn man im Impressum darauf hinweist, dass Google Fonts verwendet werden? Das selbe wäre ja noch mit Google Maps?
Das muss man in der Datenschutzerklärung aufführen, es gibt viele, viele Seiten dazu in Suchmaschinen, am besten aber für den Einzelfall einen passenden Anwalt befragen.