Beiträge von Ammaletu

Du hast leider Recht, WordPress hängt das wirklich alles an die URL dran anstatt einen POST-Request zu machen. Vielleicht verstehe ich da was nicht, aber das kommt mir nicht clever vor.

Anyway, für Dein Problem gibt es wohl auch aus solchen Gründen dieses Plugin, welches ich gerade zufällig ergoogelt habe:
http://wordpress.org/extend/plugins/bulk-delete/

Mit Vorsicht einsetzen und erst ein DB-Backup erstellen! Ich habe es noch nie benutzt, keine Ahnung also ob es fehlerfrei arbeitet.

Ich schaue gerade mal in der Sprachdatei. Laut der Datei sollte diese Meldung an zwei Stellen vorkommen, und zwar plugin-install.php und themes-install.php. Das kommt dann vermutlich, wenn man ein Plugin oder Theme direkt von wordpress.org aus installieren will und da die Verbindung nicht klappt, vermute ich. Keine Ahnung, wieso Du das beim Veröffentlichen eines Beitrages kriegen solltest.

... Obwohl, wenn ich mir das so anschaue: Kann es sein, dass WP da intern gerade den Check auf Updates gemacht hat, und der hat nicht geklappt? Das wird ja nicht wirklich zeitgesteuert ausgeführt, soweit ich weiß, sondern hängt sich immer an andere Aktionen dran, Seitenaufrufe oder eben das Posten eines Beitrages. In der plugin-install.php steckt ein allgemeiner API-Aufruf, sicher auch zum Abfragen der Update-Infos geeignet.

Was man da jetzt machen kann, weiß ich aber auch nicht. Mal schauen ob spezielle Fehler geloggt werden?!

Du könntest vermutlich für diese Kategorien die category.php (bzw. archive.php) anpassen und dort oben prüfe, ob die aktuelle Kategorie Unterkategorien hat. Falls ja, änderst Du die Query zu was einfachem und zeigst keine Beiträge an. Andernfalls kommt der normale Loop.

Mit Query ändern meine ich sowas hier, um unnötige DB-Abfragen zu vermeiden:

// change the loop query so that it stays intact but returns as few results as possible
$posts = query_posts($query_string . '&showposts=1');

Ich bin nicht sicher, ob man das so ganz allgemein sagen kann. Das hängt doch auch immer davon ab, wie PHP auf dem Server eingerichtet ist, unter welchem Benutzer der Apache läuft etc. Soweit ich weiß jedenfalls. Im Prinzip brauchst Du Schreibrechte nur auf der .htaccess, denke ich, und auf alles im wp-content-Ordner. Wenn Du die Themedateien und Plugins nicht aus WP heraus bearbeiten willst, brauchen die Ordner keine Schreibrechte. Wie das mit den automatischen Updates ist, müsstest Du mal testen.

Das klärt sich eigentlich von selbst, wenn Du überlegst, wie Du Daten zur Besucherzahl oder zur Bewertung erheben willst. Für beides gibt es eigentlich eine große Anzahl Plugins. Was sinnvoll ist, hängt von Deiner Seite ab. Beiträge bewerten zu lassen, macht IMHO z.B. nicht für jede Seite Sinn. Besucherzahlen können sicher gute Aussagen treffen, was beliebt ist und was nicht. Für Bewertungen fällt mir auf Anhieb "wp_postratings" ein und für Statistiken entweder sowas wie Google Analytics oder das wp.com-Stats-Plugibn, oder aber selbstgehostet mit Semmelstatz. das wären mal so ein paar Namen, die mir ohne direkte persönliche Erfahrungswerte bekannt sind.

Das geht nur, denke ich, wenn das Plugin ein eigenes Recht definiert und Du das per "Role Manager"-Plugin einer Rolle zuweist und diese dann dem Nutzer. Das machen aber nicht sehr viele Plugins, glaube ich.

Davon abgesehen prüfen manche Plugins die vordefinierten Rechte und gewähren ggf. nur bestimmten Rollen (Admin, Editor) Zugriff auf die Optionen. Aber auch das machen nicht so übermäßig viele Plugins.

Also Du kannst schon mal nicht in PHP etwas definieren, was von der aktuellen Mausposition des Nutzers abhängt. PHP wird auf dem Server ausgeführt, dann wird der HTML-Output an den Nutzer geschickt, und der fährt danach mit der Maus aufs Menü oder nicht. Die Regeln müssen also dann schon komplett fertig vorliegen.

Zitat

Sollte es nicht gehen: Kann ich dann alternativ in der CSS bei z.B.

#subnav3 li a:hover span {background: #FFFFFF url(xyz.gif);}

in diesem hover-Absatz {..} die z.B. #subnav2 li a span ansteuern? Also nach der Art wenn subnav3 hover dann dort Hintergrundbild x und gleichzeitig in subnav2 Hintergrundbild y?

Du kannst in oben erwähnter CSS-Deklaration auf alles zugreifen, was innerhalb des "gehoverten" Bereiches liegt. Wenn #subnav2 ein Kind von #subnav3 ist, geht es.

#subnav3 li a:hover span {
  background: #FFFFFF [URL="http://forum.wordpress-deutschland.org/lexikon/?do=showentry&item=url"]url[/URL](xyz.gif);
}


#subnav3 li a:hover #subnav2 li a span {
  background: #FFFFFF [URL="http://forum.wordpress-deutschland.org/lexikon/?do=showentry&item=url"]url[/URL](xyz.gif); // hier Farbe zurücksetzen
}

Wenn #subnav2 und #subnav3 getrennte Bereiche sind oder #subnav3 ein Kind von #subnav2 ist (was die ID wohl andeutet), wird das schwieriger. Du kannst per CSS leider nicht ein Element basierend auf einem Kind des Elementes markieren. Das würde dann z.B. per jQuery relativ simpel gehen. Um Dir da ein sinniges Beispiel sagen zu können, solltest Du aber vielleicht mal einen Ausschnitt des HTMLs des Menüs posten.

Die Zeilenangabe bezieht sich auf den HTML-Output, nicht auf die PHP-Dateien. Die kennt der Validator ja auch gar nicht. ;-)

Kann es ansonsten sein, dass im Theme ein div zu viel ist an der Stelle? meistens ist das ja als if .. else gemacht. Schau in der category.php oder archives.php mal in den else-Zweig, der ausgeführt wird, wenn keine Artikel vorhanden sind. Soweit ich das auf einer nicht akputten Seite sehe, sollte #page sowohl #content als auch #sidebar enthalten. Auf der kaputten Seite enthält #page aber nur #content, dann wird das page-div geschlossen und #sidebar kommt dahinter.

Schau mal hier:
http://blog.wordpress-deutschland.org/2009/07/13/wordpress-smileys.html

Das wird sich in WP 2.9 wohl etwas ändern. Eventuell lohnt es also, so lange abzuwarten. Danach kann man die Smilie-Location wohl einfach per Filter definieren, wenn ich das richtig verstanden habe. Das wären dann zwei, drei Zeilen in der functions.php des Themes.

Ich denke, am besten packst Du das alles in eine Seite, und zwar genauer gesagt in ein Seiten-Template. Erstelle ein Template für Deine Kontaktseite. Im Template prüfst Du, ob das Formular an die Seite abgeschickt wurde. Wenn ja, zeigst Du die Bestätigung an, wenn nein das Formular. Dann ist alles an einem Platz und Du musst Dich nicht mit "unsichtbaren" Seiten abmühen.

Ich bin nicht sicher, aber wäre hier eventuell ein Shop-Plugin das richtige? Auch wenn Dein Produkt ggf. nichts Physisches ist. Wenn es um Geldzahlungen geht würde ich persönlich auf jeden Fall eine fertige, stabile Lösung einem Eigenbau vorziehen. Dabei weiß ich natürlich jetzt nicht, wie komplex das werden soll und was es noch an Bedingungen gibt.

Vielleicht ein Fehler beim Pingen? Ich nehme mal an, mit API ist kein Bestandteil des normalen WordPress-Veröffentlichungsprozesses gemeint, sondern etwas Externes. Um das genauer zu sagen, müsste man die Meldung aber mal im Sprachfile suchen und den Key davon dann im WP-Quelltext.

Ich würde das nicht in der DB machen, da das in mindestens drei Tabellen steckt, ggf. noch mehr (posts, postmeta, comments...).

Du kannst im Backend doch die Anzeige der Beiträge nach Kategorie einschränken über die DropDown-Box oben in der Mitte über den Beiträgen. Dann siehst Du schon mal nur Beiträge, die dieser Kategorie (und ggf. noch anderen) zugeordnet sind. Wenn die Kategorie jetzt sehr viele Beiträge enthält, kannst Du oben rechts auf "Optionen einblenden" gehen und einstellen, dass mehr als die voreingestellten 20 Beiträge pro Seite angezeigt werden. Sagen wir, Du stellst das auf 50. Dann brauchst Du nur noch auf die Checkbox oben im Tabellenheader neben "Post" zu klicken und alle 50 Beiträge sind markiert. Zur Sichehreit noch mal drüberscrollen, ob Du die wirklich löschen willst, und dann in der "Aktion wählen"-DropDown-Box "Löschen" auswählen und auf "Übernehmen" klicken.

Auf diese Weise sollten sich auch größere Mengen an Beiträgen sicher und ohne zu viel Zeitaufwand entfernen lassen.

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.

Hallo!

Das Theme ist auf den ersten Blick sehr gelungen, von Anordnung und Farbgebung her. Gefällt mir wirklich gut. Erst auf den zweiten Blick offenbaren sich ein paar Kleinigkeiten, die man noch überarbeiten könnte:

- Ganz oben über dem Header sieht man für ein paar Pixel noch den Strich, der weiter unten Inhalt und Sidebar trennt. Das soll sicher nicht sein.

- Es gibt in der Sidebar vier verschiedene Arten, den Header der Rubriken zu stylen. Da gibt es eigentlich keinen guten Grund, mehr als einen Style zu verwenden, denke ich. Mir persönlich gefällt die dunkelblaue Box mit der weißen Schrift ganz gut. Alternativ würde ich den ganz untersten Header nehmen und eventuell die Schrift etwas größer machen.

- Kontaktseite: Wieso ist das E-Mail-Eingabefeld anders gestylt als der Rest der Felder? Das irritiert.

Was ansonsten gar nicht geht, ist der Untertitel des Blogs. "the NEW Photo- und Media Blog". Sorry, aber das ist so falsch, in jeder Sprache, das es wirklich gar nicht geht. Durchgehen lassen würde ich sowas höchstens einem Blog, das sich satirisch mit Sprache beschäftigt. Und dabei wollte ich gerade Pluspunkte fürs Richtig-Schreiben von "Galerie" verteilen, was ja heutzutage leider auch eine selten beherrschte Kunst ist. ;-)

Alles in allem trotzdem ein sehr schönes Theme. Jetzt musst Du es nur mit entsprechendem Inhalt füllen. Viel Glück mit dem Blog auf jeden Fall noch!

Viele Grüße,
Johannes

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.