Beiträge von Putzlowitsch

Naja, mit Löschen geht es natürlich auch. Ich meinte eher, daß Du da auf das kleine Symbol klickst, welches wie ein Stift aussieht. Dann wird der Datensatz angezeigt und man kann den Inhalt des Feldes option_value einfach löschen. Dann das Ganze mit OK speichern und schon sind die Permalinks leer.

Gruß
Ingo

Klick mal oben auf SQL und gib das von mir beschriebene SQL in das dort erscheinende Eingabefeld ein. Dann mit [OK] bestätigen.
Als Ergebnis kommt dann eine Liste mit den gefundenen Datensätzen. Vorn mit dem Stift-Symbol geht man auf Bearbeiten und kann dann den Inhalt im Feld option_value löschen. Dann mit [OK] übernehmen.

Gruß
Ingo

Ich meine, wir haben ja eine Datenbank, da kann man auch prima drin suchen, ohne nun die ganze Liste duchzublättern. Das Zauberwort heißt SQL:

SELECT * FROM `wp_options` WHERE `option_name` LIKE 'permalink%'

Gruß
Ingo

Es ist so, daß Du die Domain selber bei einem Provider Deiner Wahl bestellen mußt. Dieser muß auf jeden Fall die Konfiguration der DNS-Server zulassen, denn du mußt dann die Server von Wordpress (ns1.wordpress.com usw.) für Deine Domein bei dem Provider dort eintragen .
Außerdem ist diese Domaingeschichte bei wordpress.com nicht umsonst. Du benötigst 10 Credits, die Du mit PayPal kaufen kannst.

Gruß
Ingo

Das kann ich mir nicht vorstellen. Permalinks gehen doch bei Strato sowieso nicht. Und selbst wenn, sobald eine Datei oder ein Verzeichnis real existieren, interessiert sich WP im Sinne eines Permalinks nicht dafür. Kannst ja mal spaßeshalber bei normalen Permalinkeinstellungen eine statische Seite mit dem Titel WP-Admin anlegen und gucken, was passiert

Gruß
Ingo

Ich bin dann mal weg...
Tschüssi
*duck* und *weg*

Ja, sorry, mein Fehler. Es muß natürlich, im Unterschied zu the_date(), das echo davor stehen, also so:

<?php echo date_i18n( "j. F Y", time() ); ?>

Gruß
Ingo

Gut, vergessen wir das mit dem attomatischen Scannen nach Stichwörtern. Stattdessen müssen alle Threaderöffnungs-Beiträge von einem Moderator freigeschaltet werden, nachdem er geprüft hat, ob es nicht doch schon Lösungen für das Problem gibt. So besser?

Gruß
Ingo

Probier mal:
date_i18n( "j. F Y", time() )

Das ist die von WP in the_date() verwendete Funktion, dann sollte es auch mit den deutschen Monatsnamen klappen.

Gruß
Ingo

Man könnte es auch technisch mit einer vorgeschalteten Suche nach bestimmten Stichwörtern vor dem Absenden eines Beitrages erschlagen. Wenn was gefunden wird, kommt erst eine Liste mit schon vorhandene Artikeln oder den FAQ und dann muß der Nutzer nochmal bestätigen, daß da keine Lösung dabei ist.

Gruß
Ingo

So sah die Liste übrigens vor etwa einem Jahr aus:
http://web.archive.org/web/2007011201…og-toplist.com/

Gruß
Ingo

1. Ist der Ursprungsbeitrag bereits über 19 Monate alt
2. War es damals vielleicht tatsächlich eine Blog-Topliste
3. Scheint es jetzt nur noch eine weitere Adresse für http://file-upload.to/ zu sein

Gruß
Ingo

Doch, das ist zwar nicht ganz intuitiv, aber es geht über "Downgrade":
Schnurpsel » Update durch Downgrade

Gruß
Ingo

Eigentlich haben die pw*-Pakete PHP dabei, außer dem alten XE, das es nicht mehr gibt. Falls es ein solches ist, könnte man aber zum PowerWeb Basic updaten, dann hat man auch gleich eine Datenbank dabei

Gruß
Ingo

[COLOR="Red"]* Moderatorenhinweis: Markenname auf Wunsch der Firma PHADE Software - PowerWeb unkenntlich gemacht.[/COLOR]

Ja fast, Du mußt dann nur noch die Adressen anpassen:
WordPress Deutschland FAQ » Wie kann ich die Adresse meines Blogs ändern?

Gruß
Ingo

Nicht auch, sonderen wenn überhaupt dann nur, wenn beide Pakete bei Strato liegen. Ein Zugriff von außerhalb auf die Datenbank ist bei Strato nicht möglich:
Strato FAQ Frontend

Gruß
Ingo

Das Problem ist nur, die Version 5.0.52 gibt es nich als freie Version, da wird man wohl auf die 5.0.53 oder höher warten müssen.
Bis dahin kann mein Plugin ja zumindest die Symptome lindern

Gruß
Ingo

Zitat von Saffti

...laut Strato habe ich aber die MySQL-Version 5.0.21, ...

Ist es das, was in der Datenbankverwaltung angezeigt wird? Da steht nur die Version zu dem Zeitpunkt, als die Datenbank erstellt wurde. Ich habe da auch 5.0.21 und 5.0.45 zu stehen. Wenn Du dann [Verwaltung...] klickst öffnet sich phpMyAdmind und dort wird dann oben die Version angezeigt, die tatsächlich läuft. Bei mir halt 5.0.51.

Gruß
Ingo

Danke für die Infos, ich hatte da auch in der Zwischenzeit mitgelesen.
Was letzendlich aber immer noch unklar bleibt, warum überhaupt dieses eigentlich unsinniges "GROUP BY id" eingefügt wird. Hier ein Codebeispiel aus WP 2.3.2, Datei query.php, Zeile 930:

if ( !empty($q['category__in']) || !empty($q['category__not_in']) || !empty($q['category__and']) ) {
 $groupby = "{$wpdb->posts}.ID";
}

Denn ohne diesen Unsinn wäre der Fehler auch nie aufgetreten, egal ob nun MySQL das was falsch gemacht hat, oder nicht.

Zumindest habe ich auch was daraus gelernt, nämlich das ein GROUP BY mitnichten eine Sortierung implizieren muß. Das Ergebnis kann zwar nach den
gruppierten Feldern sortiert sein, muß es aber nicht.

Gruß
Ingo

Zitat von Doc

...
Führt Dein plugin eigentlich zu Performanceeinbußen? Ich bilde mir immer ein, dass jeder zusätzliche Filter Datenbankzugriffe ausbremst.

Nein, oder zumindest dürfte das bei der sowieso eher bescheidenen Strato-Datenbank-Performance nicht auffallen. Falls Du die neue Version 0.11 meines Plugins verwendest, wird das "GROUP BY" für WP ab Version 2.1 sogar ganz entfernt, so daß sich der SQL-Interpreter darum nicht mehr kümmern muß. Geht damit vielleicht sogar einen Tick schneller

Gruß
Ingo