Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenEigentlich reicht es, die Registrierung abzuschalten. Dann wird der Admin-Link aber noch angezeigt, wenn man angemeldet ist. Das ist ja auch sinnvoll, weil man sicher auch mal in den Admin-Bereich muss.
Ansonsten die Datei "blocks/k2-header.php" öffnen und dort die Zeile
wp_register('<li class="admintab">','</li>');
auskommentieren oder entfernen.
Wer eine ältere Version von K2 nutzt, sucht eben nach der o.g. Zeile.
dann ist doch die sidebar.php datei ziemlich groß,
Ja, das wird sie.
trafficlastig?!
Das weniger, weil durch die Bedingungen nur der Teil an den Zielrechner "ausgeliefert" wird, für den die Bedingungen zutreffen.
aber der hintergedanke ist, ob es auch eine benutzerfreundliche oberfläche für diese schritte gibt?
Man könnte die "Excerpts" quasi missbrauchen. Oder man nutzt die benutzerdefinierten Felder. So landen die zusätzlichen Informationen in der Datenbank und sind beim jeweiligen Artikel gespeichert. Abgerufen werden könnten sie dann mit Hilfe eines Plugins (oder mit Hilfe einer Funktion in der "functions.php"), das die Felder bzw. den Auszug (Excerpt) auswertet und anzeigt.
Das ist nur eine Theorie, aber es wäre der Weg, den ich gehen würde.
Hab ich gemacht, aber die Meldung geht nicht weg.
Du kannst die Updateprüfung in einer Datei auskommentieren. Siehst du die Meldung dann trotzdem noch, enthält die "wp_options"-Tabelle in deiner Datenbank einen Eintrag. Ich glaube, update_core müsste der heißen. Wenn du den löscht (nur den!), und wenn du die Updatefunktion mit oder ohne extra Plugin abschaltest, hast du Ruhe.
Ich persönlich bevorzuge ein Abschalten der Funktionen direkt in der jeweiligen Datei (schöne Sache in WP 2.7, denn hier ist nur eine Datei verantwortlich), denn ein extra Plugin kostet auch wieder Ressourcen. Zwar nur wenige, aber dennoch. Gar nicht erst laden, schont mehr Ressourcen. ;)
meine Testversion sieht fast jeden Tag anders aus ;)
Inzwischen halten sich diese Änderungen doch in Grenzen. Es geht jetzt mehr um den Feinschliff. Hier ein paar neue Bildchen, dort ein neuer Menüstil, da wieder andere Farben. Alles in allem sehr elegant.
Die Codebasis ist jedoch als "feature-freeze" deklariert, d.h. die Leute, die sich jetzt Gedanken über Plugins usw. machen wollen, können das auch tun. Größere Änderungen im Code wird es nicht geben, es sei denn, es wäre in irgendeiner Form (sicherheits)relevant.
"wp-includes/post.php"
Oh bitte. Ich frage lediglich nach ein paar Meinungen von Leuten, die (wie ich) WordPress 2.7 bereits testen, und die mir entweder zustimmen, oder die meine Idee verbessern. Wo sonst sollte ich die finden, wenn nicht hier? im WordPress-Forum.
Und mehr Augen sehen bekanntlich auch mehr. Sollte ich Recht haben, kann ich immer noch ein Ticket dafür eröffnen.
(Alle Codeauszüge sind in der Datei "wp-admin/includes/dashboard.php" in der Funktion "_wp_dashboard_recent_comments_row" zu finden.)
Mal eine Frage an diejenigen, die bereits die SVN 2.7 zum Testen oder gar live verwenden. Das neue Dashboard zeigt die aktuellen Kommentare doch sortiert nach Datum, bzw. mit den Worten "Heute" und "Gestern". Bei mir spinnt die Anzeige jedoch. Diese Zeile
$yesterday = gmdate( get_option( 'date_format' ), strtotime( 'yesterday' ) + get_option( 'gmt_offset' ) );ermittelt in meinem Fall den 13. Oktober als gestriges Datum, womit sich der lustige Effekt ergibt, dass mein Dashboard die Angaben 14. Oktober, Gestern und 12. Oktober enthält. Und Nein, mein Rechner ist schon richtig eingestellt. Auch bei mir ist heute der 15. Oktober. 'ne Uhr kann ich noch lesen. :lol:
Zudem sind die Datumsangaben nicht übersetzt. Ich habe mich mal rangesetzt und die Variablen $today, $yesterday und $comment_date anders befüllt
$today = mysql2date( get_option('date_format'), date( "Y-m-d" ) );
$yesterday = mysql2date( get_option('date_format'), date( "Y-m-d", strtotime( '-1 day' ) ) );
$comment_date = mysql2date( get_option( 'date_format' ), $comment->comment_date );Damit sind die Daten übersetzt, und Gestern und Heute werden auch richtig ermittelt. Vorschläge? Verbesserungen?
Genau das eben nicht! Der Spitzname (Nickname) liegt in der Usermeta-Tabelle (meta_key: nickname), und ist eben nicht der user_nicename (gerade getestet, WP 2.6.2 ;-))
Du hast Recht. Sorry, mein Fehler.
Ich ging von mir aus. Ich hatte ursprünglich in meinem Blog einen Benutzer angelegt, dessen Login- und Anzeigename mein echter Name war. Der Spitzname ist auch weiterhin mein Vorname, und in meinem privaten Blog steht der auch als Linktext auf der Seite.
Ich habe dann später via Datenbank (phpMyAdmin) das Feld "user_login" verändert. Ausschließlich dieses Feld, sonst nichts! Und seitdem zeigt mir der Blog zwar weiterhin meinen Namen an, aber anmelden muss ich mich ganz anders.
Bei Sandra ist das Problem ähnlich. Sie muss in der Datenbank das Feld "user_nicename" ändern (und nur das!), damit ihre URL für das Autorenarchiv den erlaubten Namen anzeigt.
Dass du auf die mögliche Gefahr hinweist, finde ich gut und richtig, aber ich möchte anmerken, dass ich beschrieben habe, worauf ich hinauswill, und wie es funktioniert. Mit den normalen Mitteln von WP kannst du den Schutz vor Doubletten nicht aushebeln. Das hast du selbst gemerkt! Und das direkte Ändern in der Datenbank unterscheidet sich nicht vom direkten Ändern von Konfig- o.ä. Dateien anderer Software. Auch hier muss man wissen, was man tut. Und wer wider besseren Wissens irgendwelche Angaben ändert, obwohl er genau weiß, dass sich das mit bereits vorhandenen Daten überschneidet, der handelt grob fahrlässig.
Noch einmal: auf irgendeine Kleinigkeit zu verzichten, nur weil ein Risiko besteht, halte ich für falsch. Wenn es sich umsetzen lässt, und wenn man jeden auf mögliche Gefahren hinweist, dann reicht das meiner Ansicht nach aus. Und wenn sich Sandra strikt an unsere beiden Vorgaben hält, passiert überhaupt nichts.
Das Anliegen von ihr verstehe ich sehr gut, denn ich hatte die gleiche Idee. Auch mir hat es nicht gefallen, dass jemand meinen Benutzernamen sieht und damit nur noch das Passwort erraten muss. Darum habe ich die von mir beschriebene Änderung vorgenommen. Und dank Frank (und einem Artikel in seinem Blog) habe ich auch noch die Anzeige der Fehlermeldung deaktiviert. Ein potentieller Angreifer sieht bei mir nicht, was er falsch gemacht hat. Bei einer Fehlanmeldung erscheint nur noch ein leerer roter Kasten. Die Meldung, ob Benutzername und/oder Kennwort falsch waren, fehlt völlig.
Du kannst den "user_nicename" auch im Profil ändern (= Spitzname). In der Auswahlliste darunter (Im Blog anzeigen als) legst du nur fest, was der Leser lesen soll; oder in HTML-Code ausgedrückt:
<a href="spitzname">Im Blog anzeigen als</a>;)
Zu deinem letzten Einwand: Ich bin mir mehr als sicher, dass WordPress meckern wird, wenn du versuchst, Namen einzustellen, die bereits in Benutzung sind. (Werde ich gleich mal testen!) Dieses Feature kann man nur aushebeln, wenn man die Datenbank direkt verändert. Und hier bitte ich noch einmal darum, meinen ersten Beitrag zu beachten! Ich rede davon, dass Sandra in ihrem Profil alles einstellt, was die Leser ihres Blogs ohnehin erfahren dürfen. Und dort (im Profil!) ist das Feld "Benutzername" ausgegraut und nicht änderbar. Darum sollte sie dann ein Tool wie phpMyAdmin verwenden und dort in der genannten Tabelle ausschließlich das erwähnte Feld ändern. Nichts anderes!
Mmh, ich glaube nicht. Also nochmal langsam, wenn ich irgendwo nen Denkfehler hab sag bescheid. ;-)
Ich glaube, dass du einen Denkfehler hast.
Mein Blog läuft nämlich nach der von mir beschriebenen Funktion. Die URL für das Autorenarchiv wird bei WP aus dem "user_nicename" gebildet. Ich sehe es in zwei Blogs, in denen ich aktiv bin. In einem steht mein Vorname als Link zum Autorenarchiv, im anderen meine Initialen. In beiden Blogs logge ich mich jedoch mit ganz anderen Benutzernamen ein.
Die erscheinen dann zwar in der Liste der Benutzer (d.h. wenn ich den Blog nicht selbst betreue, kann der Admin den echten Benutzernamen sehen), aber diese "Lücke" ist idR zu vernachlässigen (PS: Weil der Admin ja sowieso kompletten Zugang zum Blog hat.)
Du kannst mir schon vertrauen. In diesem speziellen Fall weiß ich, wovon ich rede.
Du kannst mir auch vertrauen, Sandra.
Edit: Ich reiche sogar noch den Nachweis nach (für die technisch Interessierten):
function get_author_posts_url($author_id, $author_nicename = '') {
global $wp_rewrite;
$auth_ID = (int) $author_id;
$link = $wp_rewrite->get_author_permastruct();
if ( empty($link) ) {
$file = get_option('home') . '/';
$link = $file . '?author=' . $auth_ID;
} else {
if ( '' == $author_nicename ) {
$user = get_userdata($author_id);
if ( !empty($user->user_nicename) )
$author_nicename = $user->user_nicename;
}
$link = str_replace('%author%', $author_nicename, $link);
$link = get_option('home') . trailingslashit($link);
}
$link = apply_filters('author_link', $link, $author_id, $author_nicename);
return $link;
}(wp-includes/author-template.php)
Mit anderen Worten: ich habe Recht, oder wie? :mrgreen:
Gib mal ein Beispiel für die Behauptung.
Stell in deinem Profil bitte wieder das ein, was die Leute sehen dürfen und sollen. Also bspw. deinen echten Namen, deinen Spitznamen, oder was auch immer. Dann nimm ein Tool wie phpMyAdmin, öffne die WP-Datenbank und gehe in die wp_users-Tabelle. Dort änderst du das Feld "user_login" auf den Anmeldenamen, der den Leuten eben nicht bekannt sein soll.
So habe ich das gemacht, weil ich die gleiche Idee hatte. Die meisten potentiellen Angreifer versuchen ja den "admin" oder den Namen, den sie im Blog sehen, und genau deswegen habe ich das auch gemacht. Funktioniert exakt so, wie du es wünscht.
Eigentlich gibt es dafür nur dieses Forum, denn das deutsche Kubrik-Thema wird in Eigenregie erstellt. Das Original im "default"-Ordner ist nicht übersetzbar. An sich totaler Unfug, der sich mit einem Patch beheben lässt. Gestaltet man die Texte entsprechend, tauchen sie in der Sprachdatei auf und müssen nur noch übersetzt werden.
Das deutsche Team spart sich jede Menge Arbeit, weil es mit jeder neuen Version eigentlich nur noch die Sprachdatei kontrollieren muss. Und der Anwender, der Kubrik nutzt, kann schneller auf neue Updates wechseln und muss ggf. ein bisschen auf eine evtl. angepasste Sprachdatei warten.
btw, das Original hat den von dir angesprochenen Fehler nicht!
Robert, ein paar kleine Anmerkungen: wenn der Blog und die Sprachdatei sowieso UTF8 nutzen, dann lass die HTML-Kodierungen der Umlaute usw. weg. Damit erledigen sich auch evtl. Fehlanzeigen in den Dialogboxen im Backend.
Such mal nach der Phrase
Du hast leider nicht die nötigen Rechte [...]
Mal setzt du das Komma nach Rechte, dann wieder nicht. Und lass das leider weg. Es gibt keinen Grund, sich dafür zu entschuldigen. ;-) Du könntest im Deutschen übrigens auch you do not have the right und you do not have the permission mit Du hast nicht die nötigen Rechte übersetzen. Die Korinthenk*cker werden zwar anmerken, dass right und permission nicht das selbe sind, aber im Deutschen triffst du mit Rechte die gleiche Aussage, und der Sprachstil wird einheitlicher.
Ein
Invalid post type.
ist im Deutschen immer noch ein ungültiger Artikeltyp (Zeile 517).
Brich dir nicht mit solchen Kontruktionen einen ab
Während die Meta-Daten des Artikels abgerufen wurden ist ein Fehler aufgetreten.
*grins* Eigentlich fehlt da ein Komma. Aber schreib es doch so, wie du es vermutlich auch sprechen würdest: Während des Aufrufs der Meta-Daten des Artikels trat ein Fehler auf und du sparst auch das Komma. In meiner Datei heißt es Beim Zugriff auf die Daten des Artikels trat ein Fehler auf. Was interessiert es den Anwender, ob es Metadaten sind...
Zeile 210, der Unterstrich:
Diese E-Mail_Adresse
Komma- und (mit Verlaub) Stilfehler stecken noch einige drin. Man sollte bei Gelegenheit die Datei mal kontrollieren, und dann daraus die Sie-Kopie generieren.
Kontrolliere noch mal die Sprachdatei, ob du wirklich die aktuelle Version hochgeladen hast, ob du tatsächlich aus der PO- eine MO-Datei erzeugt hast, usw. Hat noch jemand Zugang zum Blog (in legaler Hinsicht, als Admin, meine ich), der evtl. seine Version der Sprachdatei hochgeladen hat?
... sollte oder muss man offensichtlich alle Plugin-Sprachdateien umbenennen um jeweils die "_Sie"-Erweiterung.
Ja. Das liegt eigentlich auf der Hand. Du definierst in deiner Konfig-Datei den Sprachstring "de_DE_Sie". Den benutzt WordPress intern für sämtliche Zugriffe auf Sprachdateien. Daraus werden also die Dateinamen für Plugins gebildet. Logischerweise darf eine Datei dann eben nicht mehr "plugin_de.mo" oder "plugin_de_DE.mo" heißen, sondern sie muss "plugin_de_DE_Sie.mo" heißen.
Du gehst einfach in die Beitragsbearbeitung, guckst etwas weiter unten bei "Kommentare & Pings" und nimmst den Haken bei "Kommentare erlauben" raus. Voilà. Die bis dahin geschriebenen Kommentare bleiben erhalten. Neue sind nicht mehr möglich.
Ich dachte bisher immer, WordPress-Anwender gucken einfach mal, was so möglich ist. :mrgreen:
Ich finde diese Variante ziemlich gut, und ich kämpfe gerade dafür (na ja, "kämpfen" ist nicht das richtige Wort), so etwas auch in eine andere Blogsoftware zu bekommen.
Der Vorteil bei WP ist, dass man eigentlich 3 Namen hat: den im Blog angezeigten, den slug (quasi die URL für die Beiträge des Autoren) und den eigentlichen Benutzernamen. In meinem Fall ist der Benutzername etwas ganz anderes als der Name, der zur Bildung der URL (Zeige alle Beiträge von XY) benutzt wird. Und das macht Angriffe bzw. Loginversuche doch etwas schwerer.
