Beiträge von Ammaletu

So, das musste ich jetzt doch noch mal testen. Das Einbinden der Scripte auf diesem Weg klappt einwandfrei, allerdings hatte ich weiter oben leider einen Fehler eingebaut: Es muss "jquery-ui-tab[COLOR=Red]s[/COLOR]" heißen. Sorry! :-/

Davon abgesehen muss das Theme die Aufrufe für wp_head und wp_footer enthalten. Die jQuery-Hauptdatei wird im Header eingebunden, die jQuery-Plugins im Footer. Das ganze klappt bei mir, wenn der Code in der functions.php steht, nicht jedoch wenn er in der header.php steht (auch nicht ganz oben). So, hier also nochmal zum Kopieren der richtige PHP-Code.

function my_init_method() {
  wp_enqueue_script('jquery');
  wp_enqueue_script('jquery-ui-core');
  wp_enqueue_script('jquery-ui-tabs');
}
add_action('init', 'my_init_method');

P.S.: Wieder mal zu viele Sachen gleichzeitig gemacht, die beiden vorherigen Antworten hatte ich noch nicht gesehen als ich das getestet und das hier geschrieben habe.

Am Stylesheet kann man relativ leicht sehen, was da schiefläuft. Du hast rechts eine Sidebar, die gefloatet ist und mindestens 800px hoch sein soll laut CSS. Die Galerie-Klasse hat aber "clear: both" definiert, damit sie nicht neben irgendwelche vorherigen Floats rutscht, Absatzbilder etwa. Damit wird der Browser angewiesen, die Galerie unterhalb aller Floats darzustellen, also auch unterhalb der Sidebar.

Abhilfe würde es schaffen, wenn ein Parent-Container der Galerie ebenfalls gefloatet wäre, z.B. ".entry". Soweit ich das mit Firebug sagen kann, müsste folgendes im Stylesheet Dein Problem lösen:

.entry {
  float: left;
}

Damit gilt das clear nur noch innerhalb des entry-Container, und alles stimmt wieder. Schau aber ggf. alle Ansichten mal durch, ob das irgendwo Nebenwirkungen produziert.

Probier das mal in die functions.php zu setzen, da gehört es eher hin (oder in der header.php möglichst weit nach oben). Es kann sein, dass Du es in der header.php zu spät eingebunden hast, wenn der entsprechende Hook schon aufgerufen worden ist, oder es fehlt im Theme was. Hast Du den wp_head-Aufruf in der header.php stehen?

Bilde ich mir das ein oder ist das ein wunderschönes Negativbeispiel wie man eine SQL-Abfrage nicht bauen sollte? Nämlich in dem man alles, was der Nutzer einem gibt, im DB-Server ausführt?! Belies Dich bitte zuallererstmal über SQL Injection und passe das Script entsprechend an!

Um die Selectbox loszuwerden... Naja, Du kannst sie durch was äquivalentes ersetzen, Checkboxen zum Beispiel. Oder Du bietest dem User drei Eingabefelder an. Die PLZ könntest Du von den anderen beiden Feldern ja auch so unterscheiden, falls es nur um deutsche oder österreichische PLZ geht (oder andere rein nummerische PLZ), aber Stichwort von Firmenname kriegst Du eher nicht unterschieden. Du kannst natürlich auch einfach mit dem Suchwort in beiden DB-Spalten suchen. Wenn ein Firmenname als Keyword vorkommt, wird der Datensatz eben auch gefunden.

So gesehen könntest Du in der Suchmethode einfach prüfen, ob das Suchwort nur Zahlen sind, dann baust Du eine PLZ-Abfrage. Andernfalls baust Du eine Query, die in beiden Feldern nach dem Suchwort sucht. Und Variablen werden nur mit der nötigen Vorsicht übernommen (SQL-Sonderzeichen maskieren, Feldnamen nicht aus Variablen übernehmen, nicht irgendeine Variable nehmen sondern explizit aus $_POST-Array abfragen).

Ich kenne das Plugin nicht, aber mal allgemein: Wenn der Shop ohne PW-Abfrage aufrufbar ist, macht das Abfragen vor der Weiterleitung für mich nicht viel Sinn. Im Prinzip müsste es also ok sein, dass vor der Weiterleitung keine PW-Abfrage kommt, und es wäre dann der Job der Shop-Seite, ggf. ein PW abzufragen.

So, ich habe jetzt noch mal genauer geschaut und auf Deiner Seite auch ein Beispiel gefunden. Klickt man mal auf die Webseite des Theme-Autoren, wird das Problem dort auch schon im allerersten Kommentar angesprochen.

Die Sache sieht so aus: Das Theme setzt eine Technik ein, welche den Titel nimmt und mit einer (vermutlich einstellbaren) Schriftart daraus ein Bild generiert. Damit kann man dann beliebige Schriftarten einsetzen für die Überschriften, was ja sonst eher schwierig ist.

Wenn Du mich fragst, ich das ziemlicher Unfug. Manche Firmen müssen vielleicht ganz doll dringlich ihre Firmenschriftart einsetzen, aber für ein privates Blog ist das unnötig. Wenn es geht, solltest Du das in den Theme-Optionen im Backend abstellen. Das Stichwort dafür lautet "cufón". Schau mal im Backend was man da einstellen kann. Du solltest das entweder ausstellen oder auf eine Schriftart umstellen, welche die deutschen Umlaute enthält.

Wie es ohne aussieht (mit Umlauten) kannst Du Dir im übrigen anschauen, wenn Du JavaScript deaktivierst, da die Textüberschrift per JavaScript durch die Bildvariante ersetzt wird.

Dann poste doch bitte mal die ganze Methode "mw_recent_comments". Da muss das ja drin stehen, wie der richtige Aufruf lautet.

Ich würde dafür nicht das Plugin ändern. Wenn Du es eh nur anfügen willst, gib doch Deinen Code einfach nach dem Aufruf der Plugin-Methode aus, oder hängt das von der Logik her wirklich irgendwie zusammen?!

Hm, hilft Dir dieses Plugin weiter?
http://wordpress.org/extend/plugins…last-logged-in/

Update: Ich sehe gerade dass sich das auf einen externen Service bezieht Aber vielleicht kannst Du Dir da ja die Grundlagen abschauen.

Also eine Vereinfachung, die sich anbietet, wäre das ganze mehr ins Theme zu integrieren. An den Beiträgen würdest Du die Kunden-ID als benutzerdefiniertes Feld setzen. Im Theme (z.B. single.php) prüfst Du, ob der Beitrag eine Kunden-ID hat und wenn ja, wird die SQL-Abfrage eingebunden. Damit musst Du dann schon mal nicht PHPim Beitragstext haben (so ist es aktuell umgesetzt, oder?).

Wozu ich jetzt eher keine Lösung wüsste ist die automatische Synchronisierung der beiden DB. Kann man sich sicher programmieren, aber bist Du sicher, dass das Sinn macht? Wird die externe DB noch von anderen Programmen benutzt? Ansonsten fände ich es sinnvoller, die Kunden z.B. als statische Seiten zu pflegen und die Daten in den benutzerdefinierten Feldern zu lagern, wenn eh nur WP drauf zugreifen soll.

Weil die Domainumleitung gar keine Umleitung ist sondern einfach nur die Zeilseite in einem Frame einbindet. Was die Zielseite dabei als Seitentitel setzt, kann die äußere Strato-Seite natürlich nicht wissen.

Sorry, aber Deinem letzten Posting kann ich leider nicht wirklich folgen. Was ich oben sagen wollte: Gib den Gedanken auf, dass eine Webseite immer gleich aussehen muss, insbesondere dass die Eingabe im Editor genau gleich der Ausgabe im Blog sein muss. Das ist sie nicht und wird sie auch nicht sein, und es würde auch keinen Sinn machen.

Wenn Du mit dem Stylen der Bilder-Positionierung noch ein anderes Problem hast, beschreibe das bitte noch mal genauer.

Du müsstest den type-Parameter ändern, aber die gültigen Werte standen nicht im Kommentar. Schau einfach mal in die Methode, was da als type-Parameter geht oder probiere auf gut Glück mal 'comment' oder 'comments' statt 'all' zu übergeben.

Wird die Überschrift durch irgendwas noch behandelt? Filtert das Theme die um irgendwas zu ergänzen oder zu ändern? Oder ein Plugin? Wenn man mit UTF-8 nicht aufpasst, kann man die Zeichen sehr leicht unabsichtlich kaputt machen, was englisch-sprachige Plugin- und Themautoren oft nicht selber merken.

Per "Role Manager"-Plugin müsstest Du ihm die Rechte so eingrenzen können, dass er nur Widgets ändern darf. Was schwieriger wird, ist ihn daran zu hindern, andere Widgets zu ändern oder neue einzustellen. Da bin ich nicht sicher, ob das auch geht.

Du könntest die benutzerdefinierten Felder dafür nutzen, wenn Dir das nicht zu unkomfortabel ist. Du könntest auch problemlos spezielle Eingabefelder dafür unterhalb des Editorfensters einblenden, deren Daten dann intern in den benutzerdefinierten Feldern gespeichert werden. Als Vorlage dazu kannst Du z.B. ins Hybrid Theme-Framework schauen, das macht das so.

Google hilft weiter: http://remarkablogger.com/free-wordpress…theme-sapphire/

Ich weiß aber auch nicht, ob das die Seite vom Autor ist. Sieht auf den ersten Blick so aus, aber sicher bin ich da nicht.

Zitat

Frage #1: Was genau ist " 4, false, 35, 15, 35, 'all', ' " ?

Das sind die Argumente der mw_recent_comments-Funktion. Ich nehme an, die ist ein Teil des Themes als Fallback, falls es die get_recent_comments-Methode nicht gibt (deswegen die if-else-Prüfung davor -- aber woher kommt get_recent-comments? Plugin? Sieht nicht so aus als wäre das eine WP-Funktion.). Was die Argumente bedeuten, ist hoffentlich an der Methode dokumentiert, die sich vermutlich in der functions.php des Themes befindet.

Zitat

Frage #2: Ich möchte Trackbacks/Pingbacks erlauben, allerdings nicht in meinen Recent Comments sichtbar haben ... was ist zutun?

Wie gesagt,kommt drauf an, über welche Methode Du die Recent Comments ausliest.

Tja, willkommen in der wunderbaren Welt von HTML. Gewöhn Dich schon mal dran, dass Gestalten fürs Web nicht zu vergleichen ist mit dem pixelgenauen Print-Design. Selbst wenn die Editoransicht und die Ansicht in der Webseite genau gleich wären, würde es in einem anderen Browser vielleicht schon wieder anders aussehen. Oder mit einer anderen Monitorauflösung. Es sieht auch anders aus für Nutzer mit anderen Schriftarten oder einer anderen Basisschriftgröße im System etc.

Der spezielle Unterschied zwischen Editor und Blog-Ansicht kommt daher, dass nur auf die Blog-Ansicht die Stylesheets Deines Themes angewendet werden. Die Editoransicht ist eher normales Standard-HTML. Wie Du siehst, ist die Schrift in Deinem Blog-Theme kleiner, weswegen dann neben dem Bild eben mehr Platz bleibt. Das könntest Du bei Bedarf natürlich ändern, aber nur um den Editor an die Blogansicht anzugleichen lohnt das den Aufwand eigentl9ich nicht, denke ich.

Zitat

Ich sehe den Sinn darin nicht, das ist doch eigentlich dann sinnloser Speicherverbrauch, oder?

Ja, ist es. :-/

Zitat

Wieso erstellt Wordpress dann aber auch für die anderen Größen Thumbnails die wohl größtenteils nie benutzt werden? Kann man das irgendwie korrigieren?

Würde mich auch interessieren. Es gab früher mal das sehr schöne "Flexible Upload"-Plugin, welches den Upload anders gehandhabt hat und ein Thumbnail nur bei Bedarf angelegt hat. Es wurde leider an die vielen Änderungen in WordPress irgendwann nicht mehr angepasst. Funktionieren müsste es noch, aber es sieht wirklich nicht schön aus, so jedenfalls meine letzte Erinnerung an den Einsatz mit 2.6 oder 2.7.

Ich vermute mal, dass der Programmierer, der das aktuelle Verhalten programmiert hat, sich dachte, Webspace ist spottbillig heutzutage, und auf der anderen Seite wird WP ja sowieso immer an den technisch unbegabtesten Nutzer angepasst, der das alles möglichst einfach haben will. Auszuwählen ob ein Thumbnail erstellt werden soll und in welcher Größe, ist da scheinbar schon zu viel verlangt. Aber vielleicht tut sich ja mit 2.9 was, da sollen ja auch viele Änderungen an den Multimedia-Fähigkeiten kommen. Vielleicht legt WP dann aber auch vier Thumbnails pro Bild an, wer weiß.