Beiträge von Ammaletu

Ich bin nicht wirklich sicher, was Du erreichen willst. Den Code zur Anzeige der Artikel kannst Du Dir aus jeder Themedatei rausziehen. Wobei es da ja ggf. verschiedene Darstellungen gibt, z.B. Teaser auf Übersichtsseiten, vollständige Darstellung in der Single-Ansicht etc. So oder so müsstest Du jetzt Dein Design in die Themedateien einbauen. Wenn Du Navigationen etc. nicht brauchst, kannst Du die ja aus dem Theme entfernen.

Sorry, das ist etwas wirr geworden. Wie gesagt, beschreibe doch bitte mal, was Du machen möchtest, dann kann man da eher was Sinnvolles zu sagen.

weiße Seite = PHP-Fehler in aller Regel. Siehe FAQ. Oben mal auf "weiße Seite" klicken. Muss nicht unbedingt etwas mit dem more-Tag zu tun haben, der ist nur ein HTML-Kommentar und kann so etwas eher nicht auslösen!? Hast Du am Theme etwas geändert? Kann es dabei zu Fehlern gekommen sein? Mit einer konkreten Fehlermeldung aus dem Logfile können wir weitersehen.

Hm, sieht an sich richtig aus. Vielleicht so?

<?php $file = get_post_meta($post->ID, '_wp_attached_file', true);
if ($file != '') { ?>
<div style="....">der Loop zu dem Plugin</div>
<?php } else { ?>
irgendetwas 
<?php } ?>

Ähm, wenn Du "Einträge" sagst, was meinst Du dann damit? Postings? Die sollten eigentlich weder durch Plugins noch durch Themes verloren gehen können.

Um ein Theme zu aktualisieren kannst Du einfach den alten Theme-Ordner auf dem Server löschen (mach Dir ggf. eine Kopie, falls Du z.B. in der functions.php etwas geändert hattest) und den neuen Ordner dann raufkopieren. Ob ein Theme-Update mittlerweile auch schon direkt aus dem Backend geht, weiß ich im Moment nicht mal, aber wie beschrieben per FTP geht auf jeden Fall.

Flutter: Hatte ich mir mal kurz angeschaut, aber mich dann doch gegen einen Einsatz auf meiner Seite entschieden. Mach doch einfach mal einen neuen Thread zu Deinem Problem auf, im Plugin-Unterforum. Dann hast Du die besten Chancen, dass sich jemand findet, der das Plugin kennt.

Zitat

Jemand eine Idee woran das liegt?

So auf Anhieb nicht, aber was Du probieren könntest:

- Browser-Cache leeren
- mal anderen Browser testen
- im Browser nach JavaScript-Fehlern schauen
- auf dem Server im Errorlog nach PHP-Fehlern schauen
- kurz aufs Default-Theme umschalten und schauen ob es dann geht
- mal kurz den Plugin-Ordner umbenennen und dann schauen ob es geht (währenddessen nicht die Plugin-Seite aufrufen, sonst werden alle Plugins deaktiviert)

Nutzt Du das Turbo-Feature oben rechts? falls ja, auch mal testweise ausschalten.

Es kann natürlich sein, dass irgendwas in der Optionstabelle kaputt ist, dann würden die obigen Maßnahmen nicht helfen. Aber mit etwas Glück kannst Du es so schon mal etwas eingrenzen.

Dazu brauchst Du meines Wissens nach nicht wirklich ein Plugin, das kann WP seit neuestem von sich aus. Stichwort ist "custom taxonomy". Mal sehen... Wie wäre es mit diesem Artikel?
http://justintadlock.com/archives/2009/…in-wordpress-28

Geht es um WordPress MU? Dann sollte das eventuell in die entsprechende Kategorie verschoben werden. Sorry wenn ich zum eigentlichen Problem nichts sagen kann mangels MU-Kenntnissen. :-/

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.