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 erstellenNutzt Du denn Permalinks? Falls nein, dann musst Du im register_taxonomy-Aufruf den rewrite-Parameter auf false stellen, denke ich. Das geht sicher nur, wenn Du eine Permalinkstruktur eingestellt hast.
Außerdem könnte es eventuell helfen, in den Permalinkoptionen eine Tag-Basis anzugeben. Das ist jetzt aber nur geraten, ich habe selber bisher noch keine eigenen Taxonomien benutzt.
Im Stylesheet. ;-) Einfach mal nach "color:" suchen.
Du könntest im Errorlog mal nachschauen, welchen Fehler dieses Plugin denn ausgelöst hat. Vielleicht kann man den ja beheben / umgehen.
Alternativ: Hast Du einen Link zum Plugin? Und welche Version des Plugins sowie welche PHP-Version verwendest Du? Dann könnte ich mir das vielleicht lokal mal anschauen. Meldungen dieser Art kommen ja nun doch leider öfter in letzter Zeit...
Kann sein, dass ich das gerade falsch verstehe, aber Dein Code für die Sub-Navigation gibt wenn Du auf der dritten Ebene bist auch nur die Seiten der dritten Ebene aus. Um es immer getrennt zu haben brauchst Du eher so etwas hier:
<?php
global $wp_query;
// get parent post object
$parent_post = null;
if (!empty($wp_query->post->post_parent)) {
$parent_post = get_post($wp_query->post->post_parent);
}
// show second level navigation
if (empty($wp_query->post->post_parent)) {
// current page is on first level
$parent = $wp_query->post->ID;
} else if ($parent_post->post_parent == 0) {
// current page is on second level
$parent = $wp_query->post->post_parent;
} else if ($parent_post->post_parent > 0) {
// current page is on third level
$parent = $parent_post->post_parent;
}
wp_list_pages("title_li=&child_of=$parent&depth=1");
// show third level navigation
if (empty($wp_query->post->post_parent)) {
// current page is on first level, nothing to show
$parent = -1;
} else if ($parent_post->post_parent == 0) {
// current page is on second level
$parent = $wp_query->post->ID;
} else if ($parent_post->post_parent > 0) {
// current page is on third level
$parent = $wp_query->post->post_parent;
}
if ($parent > -1) {
wp_list_pages("title_li=&child_of=$parent&depth=1");
}
?>So, ist ungetestet, also stimmen bestimmt viele Details bestimmt noch nicht. Gibt Dir aber vielleicht zumindest eine gute Arbeitsgrundlage. ;-)
Beantworte doch vielleicht mal meine Fragen aus meinem vorherigen Beitrag noch. Wenn es z.B. mit dem Default-Theme auch nicht geht, könnte ich das lokal mal testen. Wenn es mit dem Default-Theme dagegen geht und Du aber ein anderes Theme verwendest, wird das schon schwieriger. Im übrigen als neue Frage: Werden im Browser JavaScript-Fehler angezeigt beim Versuch, einen Kommentar zu editieren?
Ok, um dann mal zum eigentlichen Thread zurückzukommen: Soweit ich das gerade gelesen habe, sollten Timestamps zwischen 1901 und 2038 kein Problem sein, auf Windows-Maschinen geht aber wohl nur ab 1970 (bis PHP 5.1.0). Das Problem ist hier denke ich die WordPress-Funktion (Ja, habe gerade mal nachgeschaut -- alle negativen Timestamps, also alles vor 1970, wird fest auf das aktuelle Datum gesetzt), die man dann eventuell durch eine andere Funktion ersetzen müsste.
Hm, strftime würde gehen, aber dann müsste die Locale des PHP-Prozesses komplett verstellt werden, was vermutlich nicht gehen wird. Was Du machen kannst, ist entweder die date_i18n-Funktion in die functions.php zu kopieren und dort anzupassen (aus wp-includes/funcstions.php kopieren, in der functions.php mit anderem Namen einfügen und den if-Block am Anfang entfernen, bei mir Zeile 90-98). Oder Du lässt Dir in der SQL-Query das Datum sinnvoll formatiert ausgeben und ersetzt den Monat dort mit einer Helperfunktion durch den Monatsnamen in Deutsch.
Ok, mal der Reihe nach: Weißt Du, dass die Probleme daran liegen, dass das Plugin alte Optionen aus der DB liest, oder vermutest Du das nur? Und hast Du probiert, die Optionen des Plugins neu zu speichern? Das Plugin wird wohl kaum alte Optionen auslesen, die es auf seiner Optionsseite nicht auch speichert, denke ich.
Davon abgesehen stehen die Optionen in der wp_options-Tabelle. Ich würde da aber nicht auf gut Glück etwas dran ändern, das halte ich nicht für sinnvoll.
Kann es sein, dass eine htaccess Konfiguration diese vom plugIn bereitgestellte Routine verunmöglicht?! Gibts sowas?
Möglich wäre es, dass der Autor das nicht mit aktivierten Permalinks getestet hat. Keine Ahnung, ob es so ist, ich kenne das Plugin nicht.
ODER: Da es mir einfach nur darum geht, dass ein reg. Benutzer seinen eigenen Kommentar korrigieren kann (z.B. innerhalb von 30 Min.):
Habe mal kurz geschaut auf wordpress.org, aber das Plugin sieht da eigentlich am geeignetsten aus. Da es noch aktuell entwickelt wird, sollte man es doch zum Laufen kriegen. Andererseits gibt es eine ganze Reihe an aktuellen Bug-Reports im Forum. Kann sein, dass der Autor da etwas Zeit braucht, die alle zu bearbeiten. Spiegelt einer davon denn Dein Problem wieder, z.B. der hier?
http://ajaydsouza.org/index.php/topic,95.0.html
Und welches Theme benutzt Du eigentlich? Geht es mit dem Default-Theme?
Verrätst Du noch, welches Plugin es war (Name + Version), für alle anderen, die den Thread mit einem ähnlichen Problem finden? :-)
Ich weiß nicht, wie es bei WPMU ist, aber im normalen WP ist diese Funktion in wp-includes/pluggable.php enthalten. Wenn sie bei Dir nicht da ist, sind vielleicht einige Dateien unvollständig hochgeladen worden? Prüfe das ggf., indem Du Dir WPMU neu herunterlädst und mal nach der Funktion suchst. FTP-Übertragungsfehler kommen scheinbar öfter vor als man meinen sollte, ggf. mal ein anderes FTP-Programm testen.
Wenn ich das richtig sehe, ist die Anzahl in der Datenbank gespeichert, Du musst also nicht alle Beiträge abfragen, um an die Zahl zu kommen. Scheint in wp_term_taxonomy.count zu stehen. Ich würde annehmen, dass das am Kategorieobjekt verfügbar ist, wenn Du Dir dieses geben lässt. Die Details müsstest Du aber mal selber austüfteln, da fehlt mir aktuell die Zeit zu.
Nutze am besten die ID statt des Namens, hol Dir die Kategorie und probier einfach mal $category->count aus. Und dann der normale Loop, wie vorher auch.
[COLOR=Black]Hm, interessantes Problem. Auf Anhieb sehe ich da leider auch keinen Fehler. Was spuckt denn [/COLOR][COLOR=Black]strtotime($row->nbdate) aus?! Vielleicht ist das ja schon falsch? Ich würde vermuten, dass [/COLOR][COLOR=Black]date_i18n das aktuelle Datum nimmt, falls es keinen verwertbaren Input bekommt. Und könntest Du nicht gleich mit $row->bdate arbeiten, das ist doch ein Timestamp, oder?
[/COLOR]
Das Plugin bietet scheinbar nur einen Shortcode, mit dem Du die Unterseiten im Text einer Seite ausgeben kannst. Die Installationsanleitung, die Du sicher gelesen hast, ist da eigentlich recht übersichtlich und eindeutig:
1. Upload subpage-view.php to the /wp-content/plugins/ directory
2. Activate the plugin through the 'Plugins' menu in WordPress
3. Place [subpage-view] (or any valid shortcode) in your MCE editor (see Description).
Es gibt ansonsten sicher auch Plugins/Widgets, welche Dir die aktuellen Unterseiten automatisch in der Sidebar ausgeben, falls es das ist, was Du machen möchtest.
weiße Seite => PHP-Fehler => Wir brauchen die genaue Fehlermeldung um dazu was Sinnvolles sagen zu können => Ins PHP-Errorlog auf Deinem Server schauen :-)
P.S.: Wenn das nichts bringt, kannst Du natürlich auch mal testweise alle Plugins deaktivieren, vielleicht liegt es ja an einem von ihnen. Einfach mal den Plugin-Ordner umbenennen und schauen, ob der Login dann geht.
leider greift diese neue Version auf die Einstellungen des Vorgängers zurück - obwohl ich das Plug selbst ja gelöscht hatte
Die Einstellungen werden in der Datenbank gespeichert und bleiben beim Deaktivieren und/oder Löschen des Plugins gewöhnlich erhalten. Manche Plugins bieten eine Deinstallation an, aber nicht viele. Die Lösung Deines Problems sollte dann eigentlich sein, die Optionen des Plugins neu abzuspeichern und damit die alten Werte in der DB zu überschreiben. Wenn das nichts hilft, liegt Dein Problem vielleicht noch an was anderem (Unverträglichkeit mit Deiner WP-Version oder Deiner PHP-Version? Bug im Plugin?). Hast Du mal auf der Seite des Pluginautoren danach gesucht?
Freut mich, dass es geht. Ich war oben davon ausgegangen, dass Du nur fest die zehn neuesten Beiträge ausgeben willst. Wenn man durch alle Beiträge blättern können soll, muss das mit in die Query, siehe Codex-Seite für die Syntax.
Ach so, klar. Wenn Du nichts weiter angibst, wird ja die aktuelle URL ausgewertet, vielleicht interpretiert er die dann als Beitragstitel oder so. Mach einfach eine eigene Query auf, würde ich sagen. Mal sehen, so ungefähr:
<?php
/* Short and sweet */
define('WP_USE_THEMES', false);
require('blog/wp-blog-header.php');
include_once('blog/wp-config.php');
include_once('blog/wp-includes/wp-db.php');
$posts = query_posts('orderby=date&order=desc&posts_per_page=10&post_status=publish');
?>
<div id="headline">
<div class="ueberbig">
News Blog
</div>
</div>
<div style="min-height: 800px;">
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<div class="post" id="post-<?php the_ID(); ?>">
<div class="ueber"><?php the_title(); ?></div>
<div class="meta">
<?php the_time('F j, Y'); ?> at <?php the_time('g:i a'); ?>
</div>
<div class="normaltext">
<?php the_content(__('(weiterlesen...)')); ?>
<br/>
<br/>
<br/>
</div>
</div>
<?php comments_template(); ?>
<?php endwhile; else: ?>
<p><div class="normaltext"><?php _e('Sorry, nichts gefunden.'); ?></p></div>
<?php endif; ?>
<div class="normaltext"><?php posts_nav_link(); ?></div>
</div>Also erklären kann ich Dir das jedenfalls schon mal. Bitte Code-.Kennzeichnung benutzen übrigens!
<?php
global $wp_query;
if( empty($wp_query->post->post_parent) ) {
$parent = $wp_query->post->ID;wp_query ist das Query-Objekt, welches sich um die DB-Abfrage kümmert. Im if-Zweig wird die ID des Posts selber in die parent-Variable gesetzt, falls der aktuelle Beitrag keinen Parent hat.
} else {
$parent = $wp_query->post->post_parent;
}Wenn der Beitrag doch einen Parent hat, wird dessen ID in die parent-Variable gesetzt.
wp_list_pages("title_li=&child_of=$parent&depth=1" );
?>wp_list_pages ist die Funktion, welche alle Seiten auflistet. Mehr dazu im Codex: http://codex.wordpress.org/wp_list_pages
mit dem child_of-Argument wird gesagt, dass nur Seiten ausgegeben werden sollen, die Kind der Seite mit der gegebenen ID sind. depth=1 gibt an, dass nur eine Ebene an Seiten ausgegeben wird.
Bist Du also auf Seite A, dann werden alle direkten Unterseiten von A ausgegeben. Bist Du auf Seite A1, dann werden alle Unterseiten von A1 ausgegeben. Das funktioniert soweit mit beliebig vielen Ebenen: Du siehst immer die Kinder der aktuellen Seite.
Was Du anpassen müsstest, ist die eventuelle Ausgabe des Parent-Levels und der Links zu den Parent-Seiten.
Wird dann im Loop nichts mehr ausgegeben oder funktionieren nur die Links nicht mehr (weiterlesen)? Ersteres könnte ich mir so auf Anhieb eher nicht erklären. Wenn es dagegen die Links sind, kriegt man das sicher hin. Dann müsstest Du uns mal sagen, was da denn für Links generiert werden.
Geladen werden müsste die Datei im Theme, denke ich, also sollte Deine Datei auch in den Themeordner. Aber schu Dir mal an, ob Du in einer der Themedateien "load_textdomain" findest. Da muss der Pfad korrekt sein. Es im Theme abzulegen würde mehr Sinn machen, denke ich, Du müsstest die Datei aber beim automatischen Updaten des Themes ggf. sichern. Du kannst sie natürlich als Kopie auch einfach extra noch in den languages-Ordner legen.
Brauchst Du denn spezielle Features von WPMU für die User? Sollen die ihr eigenes Blog führen können zum Beispiel? Wenn nicht, würde ich den Umstieg eher nicht machen, zumal WP und WPMU demnächst doch eh zusammengelegt werden sollen.
Registrieren können sich Nutzer ja an WordPress genauso, und man kann ihnen da dann auch recht detailliert Rechte zuordnen. Ich kann es Dir nicht genau sagen, aber ich denke, es gibt auch Plugins, die den Nutzer aus dem Backend fernhalten. Je nachdem halt, was er machen können soll. Zumindest Login im Frontend habe ich schon gelesen, denke ich.