Beiträge von Ammaletu

Ok, probieren wir das mal. Du musst allerdings etwas mithelfen, da ich das jetzt nicht noch mal lokal testen werde.

Ich nehme einfach mal an, dass es Dir um die Admin-Seite geht, die das Plugin unter "Manage" im Menü ergänzt?! Um diese Seite auf ein anderes Recht umzustellen, bitte folgendes machen. Zeile 154 so ersetzen:

add_management_page("External Relevant Panel", "External Relevant Panel", "edit_others_posts", "edit.php", "Ext_panel_page");

Und dann in Zeile 160 auf das gewählte Recht auch testen:

// check the current user's rights
    if (!current_user_can('edit_others_posts')) {
      return;
    }

Ich habe hier erstmal ein existierendes Recht verwendet, nämlich "edit_others_posts" (Bearbeiten fremder Posts). Vielleicht findest Du hier ja auch noch was passenderes: http://codex.wordpress.org/Roles_and_Capabilities

So oder so kannst Du damit die Seite mittels Role Manager auch anderen Nutzern zugänglich machen, bzw. sie sollte automatisch allen Nutzern mit der Rolle "Editor" zugänglich sein. Wenn Du es lieber wirklich speziell für diese Seite regeln willst, muss ich noch ergoogeln wie man ein eigenes Recht definiert, welches man dann per Role Manager Rollen zuweisen könnte.

Ja, also das sollte mit "ALTER" z.B. eigentlich klappen. Was passiert denn, wenn Du Dir alle Userfelder ausgeben lässt mit obigem Code?

Naja, ich kann's Dir nicht 100% garantieren, aber so habe ich das verstanden und alles andere wäre ja auch unbrauchbar in der Praxis. Alle neueren WP-Versionen sollten auf jeden Fall den für die Permalinks benötigten Slug immer mit abspeichern. Wenn Du dann später die Permalinks einschaltest, sollte das alles normal funktionieren.

Sorry, bin ein paar Tage nicht dazu gekommen, hier zu antworten. Viel fiel mir aber auch nicht ein, als ich Dein letztes Posting gelesen habe, ehrlich gesagt.

Zitat

Deine Frage: - Hast Du mal in Dein Fehler-Log geschaut auf dem Server? Nein. Wo finde ich diese?

Das weiß ich nicht, es ist Dein Server. ;-) Manche Provider legen das auf der obersten Ebene ab, manche stellen die Logs dem Kunden auch gar nicht zur Verfügung. Wenn Du lokal mit XAMPP arbeitest, kannst Du das selber in der php.ini im Apache-Verzeichnis konfigurieren.

Wie gesagt, viel kann ich Dir nicht weiterhelfen, fürchte ich. Wenn Du das mit der DB probieren möchtest, müsstest Du im Prinzip alle Tabellen außer der wp_options-Tabelle übernehmen. Eventuell kannst Du ja auch mal probieren, ein Backup zu machen und dann diese Tabelle zu leeren. Dann natürlich alle Optionen neu speichern. Manchmal stehen da falsche Optionen drin, die dann WP behindern. Aber so richtig glaube ich nicht, dass es daran liegt.

Ansonsten würde ich sagen, richte Dir auf jeden Fall mit XAMPP einen lokalen Testblog ein (siehe FAQ) und probier da dann mal, was passiert wenn Du WP mit dem Standard-Theme und nur dem Formularplugin betreibst. Klappt das dann? Oder tauchen dann Fehlermeldungen im Log auf? Ich hatte hier bei mir z.B. gerade den Fall, dass ein bestimmtes Plugin irgendwie das Logging beeinflusst, so dass mein Log trotz vieler Fehler immer leer war. Sowas kann man ausschließen, wenn man erstmal testweise alles andere deaktiviert.

Ok, ich hab das mal schnell geschrieben und getestet. Sieht gut aus soweit. Den Präfix "sd_" an den Variablennamen kannst Du durch etwas ersetzen, was für Deine Seite Sinn macht. Das soll nur vermeiden, dass man damit aus Versehen andere Variablen überschreibt. Alle drei Code-Schnipsel müssen natürlich in einem PHP-Bereich stehen, also innerhalb von <?php ... ?>.

Also, ganz oben in die Datei kommt das hier (über while .. have_posts):

// create a global array for all categories
$sd_categories = array();

Dann irgendwo innerhalb des Loops:

// add the categories of the current posting to the array
  $sd_post_categories = get_the_category();
  foreach ($sd_post_categories as $sd_category) {
    $sd_categories[$sd_category->name] = $sd_category;
  }

Damit werden die Kategorien aller Posts in das Arrays einsortiert. Und dann nach dem Ende des Loops (endwhile):

// sort the array alphabetically by name
  ksort($sd_categories);
  // output a list of all categories
  if (count($sd_categories) > 0) {
    echo '<ul>';
    foreach ($sd_categories as $category) {
      echo '<li class="' . $category->term_id . '">' . $category->name . '</li>';
    }
    echo '</ul>';
  }

Ab dem zweiten Comment wäre das Code zur Ausgabe als HTML-Liste. Du kannst mit dem Array aber ansonsten auch alles mögliche anstellen, z.B. Dir ein Widget schreiben, was prüft, ob dieses globale Array vorhanden ist und es ggf. ausgibt. So könnte das dann in die Sidebar kommen (falls diese in Deinem Theme nach dem Contentbereich ausgegeben wird).

Ich wollte mir das Plugin gerade mal anschauen, kann es unter "ext-relevant" aber nicht finden per Google. Hast Du einen Link zur Plugin-Seite?!

Also ich habe mir das Plugin mal in meinem Testblog installiert, und da klappt es einwandfrei. Was ich mir als Fehlerursache vorstellen könnte, wäre aber folgendes: Du kannst bei einem neuen Feld ja den Feldnamen (intern) und das auf der Seite angezeigte Label eingeben. Die Ausgabe klappt natürlich nur mit dem internen Feldnamen, nicht mit dem Label. Könnte es also sein, dass es vielleicht so heißen müsste?

get_cimyFieldValue($curauth->ID, 'birthday')

Dafür muss der Feldname nicht case-sensitive sein, bei klappte die Ausgabe sowohl mit "Test" als auch mit "TEST".

Was Du ansonsten mal probieren könntest, ist diesen Code-Schnipsel einzubauen. Das sollte alle vorhandenen Felder ausgeben für den Nutzer:

$allFields = get_cimyFields();
if (count($allFields) > 0) {
	foreach ($allFields as $field) {
		echo "ID: ".$field['ID']." <br />\n";
		echo "F_ORDER: ".$field['F_ORDER']." <br />\n";
		echo "NAME: ".$field['NAME']." <br />\n";
		echo "TYPE: ".$field['TYPE']." <br />\n";
		echo "VALUE: ".$field['VALUE']." <br />\n";
		echo "LABEL: ".$field['LABEL']." <br />\n";
		echo "DESCRIPTION: ".$field['DESCRIPTION']." <br />\n";
		echo "<br /><br />\n\n";
	}
}

Wow, der Validator zeigt 129 Fehler an. Schwer zu sagen, was davon den Anzeigefehler verursacht, aber neben vielen falsch codierten URLs (nicht maskierte Ampersands) sind auch eine ganze Reihe an falsch geschachtelten / nicht geschlossenen Tags dabei. Ich würde, so wie die Seite aussieht, zuerst mal darauf tippen, dass es daran liegt:
http://validator.w3.org/check?verbose=…2Ftv-showbiz%2F

Nimm Dir mal die category.php vor, oder welche Theme-Datei sonst die Kategorien anzeigt (archive oder index), und versuche diese Fehler zu beseitigen. Ist auf der Startseite im übrigen auch nicht besser, das scheint sich so halbwegs durchzuziehen durch das Theme...

Zitat

Ammaletu wo bitte siehst du das?

Steht in der zweiten Zeile des geposteten Codes, wenn man weit genug nach rechts scrollt. ;-)

Ich kann's nicht mit Sicherheit sagen, aber wenn sich bei den Versionsprüngen was geändert hat an den Texten, sollte die da eigentlich mit dabei sein. Wenn nicht, dann ist sie ja auf dem Server auch schon richtig.

Wenn Du Permalinks aktiviert hast, sind die Artikel immer auch über die Adresse ohne Permalinks erreichbar. Es wird dann auf die Permalink-Ansicht weitergeleitet. Das sollte also kein Problem sein. Alle von WP dynamisch generierten Links zeigen nach dem Import automatisch auf die Permalink-Adresse.

Hm, klingt für mich so, als wäre das Plugin schon genau richtig für Deinen Zweck. Hast Du geschaut, dass Dein Webspace die nötigen Voraussetzungen erfüllt (PHP, MySQL und WP)? Falls ja, solltest Du mal ins Fehlerlog auf Deinem Server schauen, was genau schiefgeht, denn auf der Pluginseite steht ja: "In ALL cases if an error is occured or there are no matching results from the call then NULL is returned." Bist Du außerdem sicher, dass die Feldnamen, die Du probiert hast, so stimmen? Könnte sein, dass das case-sensitive gehandhabt wird.

Also generell würde ich sagen kannst Du das als Seitentemplate umsetzen, was Du dann der Download-Seite zuweist. Dann muss es auch nicht in ein iFrame.

Gleichzeitig klingt das halbwegs gefährlich. Stell auf jeden Fall sicher, dass das Script wirklich nur darauf zugreift, worauf es zugreifen soll, und nicht z.B. den Ordnernamen per Request-Parameter übergeben kriegt, den man beliebig anpassen kann.

Wenn das klappen soll, muss das Plugin ein Recht definieren und dann auch darauf testen. Wenn der Pluginautor nichts dergleichen eingebaut hat oder einfach immer fest auf Adminrechte testet, kann auch RoleManager nicht helfen. Du kannst beim Pluginautor natürlich nachfragen, ob er das vielleicht einbauen könnte.

Also wenn Du nicht komplett eine eigene Query dazu schreiben willst, würde ich mir folgendes Vorgehen vorstellen: Normalen Loop auf der Seite durchlaufen und darin jeweils mit get_the_category die Kategorien des aktuellen Artikel ausgeben lassen. Die einem vorher definierten globalen Array hinzufügen, als Key den Titel nehmen, so dass Duplikate überschrieben werden. Dann am Ende vielleicht das Array noch alphabetisch sortieren bei Bedarf. Die Liste der Kategorien steht Dir dann natürlich erst zur Verfügung, wenn Du durch den Content-Bereich durch bist. Könnte also ganz unten auf der Seite ausgegeben werden oder je nach Theme auch in der Sidebar. Wenn Du es auf jeden Fall ganz oben brauchst, müsstest Du das gleiche machen, ohne die Artikel in dem Loop auszugeben.

Geht vielleicht auch noch einfacher, aber das wäre jetzt mal mein erster Ansatz dazu. ;-)

Ok, das wichtigste zuerst:

Zitat

Ich habe sehr lange gesessen um insgesamt 500 Seiten zu erstellen. Es wäre eine Riesenkatastrophe wenn ich die Datenbank aus Unwisseneit zerstören würde.

Das ist hoffentlich genau der Grund, warum Du vor allen Basteleien ein Datenbank-Backup gezogen hast. Wenn nicht, wäre jetzt ein guter Zeitpunkt. ;-) Es gibt Bonuspunkte, wenn Du auch noch nachschaust, dass das Backup etwas enthält und sich z.B. in einer lokalen Version importieren lässt.

Zitat

Habe auf unserer Vereins Seite ein Formular-Plugin eingebunden das nach einem Soft Update nicht mehr zu editieren ist. Ein Versuch das gleiche neu bzw. andere Formular-Plugins einzubinden sind kläglich gescheitert. Keines lässt sich editieren um neue Formulare einzubinden.

Wie äußert sich das denn? Fehlermeldung? Und um welches Plugin geht es überhaupt?

Zitat

Würde es eventuell reichen diese Tabellen zu löschen???

Damit das ursprüngliche Plugin wieder funktioniert? Ist theoretisch nicht ausgeschlossen, aber die Wahrscheinlichkeit liegt so ziemlich bei 0, denke ich.

Zitat

Oder zerstöre ich damit die gesamte Datenbank?

Wenn Du Tabellen von Plugins löschst, die nicht mehr installiert sind, macht das nichts. Wenn Du allerdings aus Versehen eine noch benötigte Tabelle erwischst, kann das natürlich Schaden anrichten. Wenn Du ein Backup hast, kannst Du die nicht mehr benötigten Tabellen aber ruhig wegräumen.

Zitat

Ist es Sinnvoll eine neue Datenbank anzulegen, und wenn ja, welche Tabellen sind wirklich wichtig für einen Import aus der alten Datenbank???

Ich dachte irgendwie, das Problem wäre ein nicht funktionierendes Plugin. Da sehe ich noch nicht den Zusammenhang zur Datenbank. Was lässt Dich glauben, dass das gleiche Problem bei einer neuen Datenbank nicht auch auftritt? ;-)

Ich würde jetzt eher drauf tippen, dass das ein Rechteproblem ist oder das Plugin vielleicht mit Deiner WP-Version nicht mehr zusammenpasst. Ist natürlich nur ein Schuss ins Blaue, so ganz ohne Infos dazu. Kann auch sein, dass z.B. Dein Hoster die PHP-Version auf einen Stand aktualisiert hat, mit dem das Plugin nicht klarkommt oder so.

Deshalb:
- Hast Du mal auf der Seite des Plugin-Autors bzw. auf der Plugin-Seite im Repository nach Infos geschaut?
- Hast Du geschaut, ob es neuere Versionen des Plugins gibt bzw. ob das Plugin wie es ist mit Deiner WP- und PHP-Version kompatibel ist?
- Hast Du mal in Dein Fehler-Log geschaut auf dem Server?

Also generell hätte ich gedacht, dass ein Feed entweder valide ist oder nicht. Das Datumsformat ist da ja recht strikt festgelegt. Valide ist der Feed jedenfalls:
http://beta.feedvalidator.org/check.cgi?url=…comments%2Ffeed
Er enthält aber zumindest an einer Stelle ein Datum, dass in der Zukunft liegt, was nicht viel Sinn macht.

... Hm, habe mal in den Feed selbst geschaut. Da steht tatsächlich bei allen Kommentaren der 6. August. Irgendwie sieht das so aus, als wäre das eigentliche Datum mit dem aktuellen Datum überschrieben worden, die Uhrzeit jedoch nicht, was dann teilweise zu Kommentaren aus der Zukunft führt. Da es fest so im XML steht, müsste das Problem allerdings bei Dir im Blog liegen und nicht bei den Readern. Und es sollte sich eigentlich in allen Readern zeigen, die nicht eventuell ältere Daten gecacht haben.

Hast Du Plugins, die den Feed modifizieren?! Oder sonst irgendwas dran geschraubt? Wenn ich die Plugin-Liste so anschaue, solltest Du vielleicht mal testweise das SEO-Plugin und Polyglott deaktivieren und schauen, ob das Problem daher kam. Ansonsten hilft wohl nur, alle Plugin und das Theme durchzuprobieren, ggf. besser an einer lokalen Version (z.B. mit XAMPP, siehe FAQ) als online an der eigentlichen Seite.

Ich hab das Feature im Firefox noch nie genutzt, aber ich würde vermuten, dass da die Adresse Deiner Webseite eingetragen werden muss, nicht die Adresse spezieller Unterseiten. Also http://mein-blog.de und nicht http://mein-blog.de/wp-admin/login.php oder so. Ansonsten wird das Cookie beim Login gesetzt und kann dann bei der Rückkehr zur Startseite nicht mehr ausgelesen werden. Und es muss ja auf allen Seiten da sein, wenn der Login klappen soll.

Hm, steht doch eigentlich deutlich da: Die Tabelle interlinker_settings existiert nicht, was den Fehler verursacht, wenn darauf eine Abfrage gemacht wird. Weißt Du, zu welchem Plugin die gehört? Eventuell musst Du die Einstellungen dieses Plugins speichern, um es korrekt zu installieren?!

Die Funktion sollte in der Datei "/wp-includes/post-template.php" stehen. Allerdings steht sie da erst ab Version 2.7, wie man in diesem Thread lesen kann: http://forum.wordpress-deutschland.org/konfiguration/…atal-error.html