Beiträge von F-rank

Hi Laura,

in jedem Fall solltest du, falls du noch immer zwischen Beiträgen und Seiten schwankst, eher Beiträge für die Rezepte verwenden. Diese lassen sich dynamisch (über verlinkte Kategorien wie "Backrezepte" oder "Suppen" bzw. über Tags wie "fleischlos", "vegan" etc.) auflisten, während Seiten eher dazu gedacht sind, fix im Menü aufzuscheinen und so grundsätzliche Inhalte wie Impressum- und Datenschutzangaben, "Über mich"-Infos und dgl. herzuzeigen.

Jüngst wurde erst ein neues Plugin veröffentlicht, das sich User Tags nennt und für deine Zwecke ganz gut passen könnte. Das würde ich an deiner Stelle mal ausprobieren und sehen, ob das zu deinen Absichten passt.

Schöne Grüße,
Frank

Kannst du versuchen, die Frage anders zu formulieren? Was genau willst du weghaben?

Grüße,
Frank

Hallo,

ja mir fällt noch ein, dass Browser-Cookies löschen oder mal einen anderen Browser zu testen auch noch eine Idee sein könnte.

Denn wenn ich als vermeintlicher Nicht-Admin was auf die Finger bekomme, weil ich als solcher ja gar nicht den Design-Menüpunkt angezeigt bekomme und also tatsächlich "schummeln" müsste, um ein anderes Theme zu aktivieren - dies aber gar nicht der Fall ist und ich wirklich der Admin bin - dann sind da wohl die Rechte verrutscht. Cookies könnten bei so etwas beteiligt sein.

Grüße,
Frank

Zitat von Robbi

1. Eine neue Datei editor-style.css angelegt
2. Darin den entsprechenden Code eingefügt:
textarea.wp-editor-area {
font-size: 13px !important;
font-family: Verdana !important;
}
3. Diese Datei ins aktuelle Theme-Verzeichnis hochgeladen.

Das alles leider ohne den gewünschten Erfolg. Weißt Du, wo der Fehler liegen könnte?

Alles anzeigen

Versuche doch einmal, zusätzlich folgendes in die functions.php des aktuellen Themes zu schreiben ...

function my_theme_add_editor_styles() {
  add_editor_style( 'editor-style.css' );
}
add_action( 'init', 'my_theme_add_editor_styles' );

Quelle: http://codex.wordpress.org/Function_Refer…dd_editor_style

Grüße,
Frank

Besten Dank für dein Like.

Zitat von mrniceguy-

Noch son geilen Tipp ? :p

Hm, die Kollegen hier sagen's ja schon richtig ... - das, was ich manchmal bei Problemhostern mache, ist, dass ich WordPress einfach auf englisch umstelle. Was du dadurch an RAM-Verschwendung vermeidest, kannst du anders kaum zustande bringen. Natürlich sollte WP auf englisch für dich bedienbar sein.

Nachteil dabei, und zwar, wenn das Frontend deutsch laufen soll: Teile des Frontends (Kommentarformular-Meldungen u.a.) werden dann leider auch englisch angezeigt. Ich löse das mit eigens erstellten po/mo-Dateien, die nur diese Meldungen enthalten und natürlich auch nur ein paar kB groß sind und ungleich weniger Load erzeugen. Aber das ist eigtl. wieder ein anderes Thema und braucht Handarbeit. - Vielleicht reicht dir das ja schon so als möglicher Wanderweg.

Zum oben verlinkten Umstell-Tipp: lösche die .mo-Dateien direkt im Ordner wp-content/languages/, wenn das Frontend-Theme deutsch angezeigt werden soll. Darf das Frontend auch englische Strings anzeigen, dann wäre die de_DE-Einstellung in der wp-config.php zu löschen, was wiederum den Vorteil bringt, dass auch die Plugins keine Lokalisierungsdateien laden, was wiederum viel RAM sparen kann.

Grüße,
Frank

Hallo!

Lustig, heute habe ich eine Antwort, die auf mehrere Probleme passt :D

Siehe daher bitte an dieser Stelle.

Ach ja - gib doch bitte Feedback, ob dir das hilft.

Schöne Grüße,
Frank

Tipp

Hallo,

ja ich habe einen Tipp für Dich. Installiere dir das Plugin "Pure PHP Localization" - das drückt dir den RAM-Verbrauch nach unten. Aber 64M memory_limit sollten ansonsten schon drinnen sein, bei einem halbwegs zeitgemäßen Provider. Und falls Strato PHP5.5 anbietet - ein Umstieg kann da auch einiges bringen.

Schöne Grüße, Frank

Hallo, nutzt du denn grundsätzlich diese Art von Funktionalität bzw. hast du ein Plugin im Einsatz, das mit Redirects herumspielt? Einmal deaktivieren, könnte eine Idee sein, falls ja ... Falls nicht, würde ich via FTP einmal einen Blick in die .htaccess riskieren, ob es da auffällige Veränderungen gibt. Login als Admin geht aber? Und dann lässt sich auch die Startseite aufrufen?! Grüße, Frank P.S.: Das Plugin Authenticator, dass du da einsetzt, wäre ein idealer Kandidat zum Deaktivieren ;-)

Zitat von zugvogel

Beim Start der Seite funktionierte das Backend einwandfrei- die eigentliche Seite erscheint jedoch komplett weiss. ... im ... Quelltext ist nichts sichtbar, lediglich eine graue "1".

Ich würde da spontan an eine fehlerhafte Theme-Datei denken. Wechsele doch einmal vorübergehend das Theme. Sollte dann das Frontend ohne Fehler erscheinen, könntest du nochmals (sofern es lokal funktioniert) das Theme per FTP übertragen - im Binär-Modus.

Desweiteren könnte die Ausgabe womöglich etwas hilfreicheres als nur diese "1" herzeigen, wenn du die DEBUG-Konstante in der wp-config.php kurzzeitig einmal auf TRUE setzt.

Schöne Grüße!

Hoppla - habe die letzten 3 Seiten übersehen :-) Also mein Tipp gilt nur, wenn es mal wieder bei intaktem Backend ein fehlerhaftes Frontend gibt ...

Hallo allerseits!

Wollte nur kurz vermelden, dass offenbar schon seit dem letzten Sommer (mit Release von v. 3.6), wie mir heute auffiel, die Datenschutz-Meldung für Akismet unauffällig untergegangen ist.

Ich habe vergeblich den Description-Text für Akismet auf translate.wordpress.org gesucht, um vorzuschlagen, dass der Datenschutzhinweis eigentlich vor der Aktivierung des Plugins in den Beschreibungstext der Plugin-Übersicht gehört - aber ausgerechnet diesen Text dort nicht gefunden. Der steht ja in der admin-de_DE.po drinnen, gehört also zum Core (wie ja Akismet auch), wie komme ich denn via translate.wordpress.org an den Text?

Grüße,
Frank

wp_reset_query()

Ich zitiere mal die Codex-Seite für query_posts:

Zitat

If you must use query_posts(), make sure you call wp_reset_query() after you're done.

Also nach der Loop solltest du wp_reset_query() aufrufen ...

In den Theme-Dateien suchst du besser nach comments_popup_link. Nur mit den Parametern dieser Funktion kannst du ( wie oben beschrieben ) einen Ersatztext für "Kommentare sind deaktiviert" bzw. ( wenn nicht lokalisiert: ) "Comments Off" setzen. Auch einen Hook gibt es dafür leider nicht. Kommt comments_popup_link in den Theme-Dateien ( so wie in Twentythirteen oder TwentyTwelve ) 5 bis 6 Mal vor, musst du die Vorkommen finden und bearbeiten.

In der Shell unter Linux findest du die Vorkommen der Funktion im Root-Ordner des Themes bequem mittels:

grep -R comments_popup_link[B] *[/B]

Du kannst in Zeile 344 der functions.php die dort vorhandene Zeile auch mit folgender ersetzen:

$tag_list = get_the_tag_list( '', ', ' );

Dann musst du nicht soviel Zeit mit der Übersetzung eines Kommas verschwenden :-)

Oder aber du nimmst das hier: twentytwelve-de_DE.mo.zip

Naja, auch möglich wäre, hier zu suchen:
https://www.google.com/search?q=wordpress+post+notify

Es gibt auch ein WP-Plugin, das die Benachrichtigung über Google abwickelt. Aber ich kenne den Namen des Plugins nicht. Ist vielleicht ohnehin in der Liste der Suchergebnisse.

Ein Newsletter hat ja eigtl. eine andere Funktion. Da musst du ja aktiv senden. Ich glaube, RaZiiLP will Benachrichtigungen eher automatisch bei jedem neuen Artikel gesendet haben, den sie oder er schreibt.

Grüße.

Hallo Birgit,

danke für die Antwort nach 9 Monaten. Nachdem nunmehr jüngst die 3. WP-Version mit dem "Beitrag" als Artikel veröffentlicht wurde, hast du es ja geschafft. Der "Beitrag" sitzt jetzt fest im Sattel - Glückwunsch.

Zitat von CoachBirgit

Die Entscheidung bezüglich Artikel vs. Beiträge ist uns nicht leicht gefallen, wie du ja auch in dem Topic zu 3.5 lesen kannst.

Irgend jemand hat vergessen, die Sperre zum verlinkten Topic aufzuheben.

Grüße,
Frank

Das ist kein WordPress-Output. Das macht eines deiner Plugins.

Du könntest den Passwortschutz für den Artikel in WP abschalten und den Artikel gleichfalls via .htaccess mit einer gesonderten Benutzer-Passwort-Kombination schützen.

Dazu müsstest du ja nur einen Benutzer in die .htpasswd aufnehmen und die Liste der geschützten Dateien in der .htaccess um eins erweitern.

Das kann allerdings unhandlich werden, falls du öfter Artikeö auf diese Weise schützen willst, denn du musst ja so jedesmal die .htaccess editieren.

Aber sicherer wär's, da WP die "Frontend"-Passwörter in der Datenbank im Klartext ablegt.

Das ist ein bisschen zu wenig. Welches Plugin nutzt du, welches Theme, wie sieht das Ergebnis aus (Link, Screenshot zur Not) - was willst du hingegen genau haben? Bei Styling-Fragen geht ohne Link zum konkreten lebendigen Problem meist gar nichts.

Aber wenn du so allgemein fragst, könnte man ebenso allgemein antworten. Indem du die Bilder mittels CSS links floaten lässt.

Grüße,
Frank

Ich würde alle PHP-Dateien herunterladen und dazu einen Datenbankdump machen. Dann würde ich mir mit einem

grep -R "Go away, lamer!" *

ansehen, wo genau der Ganove seinen Sitz hat. Wenn da nichts kommt, dann sind des Provider's Apache-Config-Files gehackt worden :-)

Domain tauschen

Zusätzlich zum richtigen, von Appendix genannten Schritt im Backend von WordPress die Pfade zu korrigieren sowie deiner richtigen Intuition, zuvor über das Kundenpanel als DOCUMENT_ROOT für die neue Domain den Pfad der alten Domain zu deklarieren, wäre zu bedenken, dass volle Bild- und sonstige Pfade innerhalb von Artikeln, Seiten, hochgeladenen Dateien usw. auch nicht mehr stimmen könnten.

Siehe dazu: http://forum.wpde.org/installation/1…-verwenden.html