Beiträge von pufaxx

... ich weiß jetzt nicht, ob ich die Problematik richtig verstanden habe - Aber warum eigentlich so kompliziert? Man kann doch den Zeitstempel von Beiträgen bearbeiten ...?

... Möment - Ich hab's jetzt nicht ausprobiert, aber ich glaub, dass damit nicht nur Posts, sondern auch Pages gefunden werden ...?

Ich würd vorsichtshalber noch

AND post_type = 'post' AND post_status = 'publish' einfügen ...

So wie es aussieht, hast Du da jetzt grad eh wieder Einiges geändert oder bist grad am Basteln - also für meine Optik klebt grad nicht nur im Internet-Explorere alles Mögliche "irgendwo" ...

Allgemeiner Tipp: Nicht wild drauflos ändern. Du musst auch gucken, ob es nicht an anderer Stelle Anweisungen gibt, die Deine Änderungen wieder aufheben. Mit den dreieinhalb Zeilen Stylesheet, von denen Du meinst, dass sie "schuld" sind, wird man jedenfalls kaum ein Problem lösen können. Ein Stylesheet fängt vorne an und hört hinten auf. Da wirkt sicherlich noch sehr viel mehr auf dein Layout aus, als die paar IDs.

Außerdem sind in den dreieinhalb Zeilen schon etliche Anweisungen drin, die einfach nicht funktionieren können. Jedenfalls nicht gleichzeitig. Beispielsweise können inline-Elemente keine Breite haben (außer vielleicht im Internet-Explorer) ... Dann macht es wenig Sinn, einen automatischen Abstand nach links und rechts zu definieren, wenn das Element eh auf links umfließen steht und ein paar Zeilen später wieder einen Außenabstand nach links bekommt ...

Und (Aber ich schätze mal, dass ich mitten in eine liegengebliebene "Baustelle" geguckt habe) - Die komplette Sidebar mit allen Kategorien etc. taucht im Quelltext VOR dem HTML-Header und dem Body auf - Da geht dann natürlich gar nichts.

... eigentlich sollte das auch nicht passieren, dass ein und derselbe Inhalt über die gleiche Adresse erreichbar ist.

Was hast Du denn im Menü ..../wp-admin/options-general.php eingetragen?

Ahja, das PlugIn ... Ich weiß jetzt nicht, wie da der aktuelle Stand der Technik ist, aber ich hab das damals auch ausprobiert.

Was mich gestört hatte, war ...

... dass Umlaute nicht beachtet wurden
... dass Überschriften auch mit Zahlen beginnen können
... dass Titel, die beispielsweise mit Anführungszeichen beginnen, auch nicht korrekt einsortiert wurden

Außerdem wollte ich Beiträge UND Seiten auflisten. Letzteres ist seit WordPress 2.1 natürlich ein bisschen einfacher geworden, weil dort Pages und Postings in der selben Datenbanktabelle gespeichert werden. Das PlugIn für ältere Versionen müsste ich wieder "ausgraben", ich weiß gar nicht mehr, wo das rumschwirrt ...

Sortierung: Von den Beitragstiteln wird zunächst einmal alles "gelöscht", was weder Zahl noch Buchstabe ist. Umlaute werden ä in ae, ö in oe und so weiter gewandelt - und diese Ergebnisse werden dann alphabetisch sortiert.

Die eigene Funktion dazu hab ich wieder rausgenommen, weil's ein ziemlicher Aufstand gewesen wäre, alle möglichen Codierungen durchzuprüfen. Ich bin der Einfachheit halber davon ausgegangen, dass bei deutschsprachigen Installationen das PlugIn "Clean Umlauts" aktiv sein dürfte und somit die Funktion o42_cu_permalinks(); zur Verfügung steht.

Der Index wird einmal erzeugt und (via WordPress Object Cache) Datei mit einer Woche Gültigkeit gespeichert. Wird vor Ablauf ein Beitrag veröffentlicht, gelöscht oder umbenannt, wird der Cache geleert, damit kein veralteter Index gezeigt wird.

Ohne Caching wäre meine Lösung sonst ebenfalls recht "träge" - Denn die erzeugten Links sind allesamt "Permalinks" - und jedesmal "get_permalink(irgendeinenummer)" bedeutet (je nachdem, welche Permalink-Optionen man nutzt) eine Datenbank-Abfrage. Das kann unter Umständen ganz stattlich werden ...

Ich müsste noch irgendwie eine Einstellmöglichkeit bieten, in der man auswählen kann, ob die Links als Permalink oder in Form von https://wpde.org/www.beispiel.de/index.php?page_id=123 ausgegeben werden ...

Das mit den Clean Umlauts kann man aber (denke ich) so lassen, oder?

Da brauchst Du eigentlich auch nicht großartig etwas finden, das </p> in Zeile 152 ist ja schon die schließende Absatzmarke, die letztendlich weg muss.

Aber ich nehme an, dass Dein Theme nicht dran schuld ist, sondern viel mehr die Tatsache, dass dieser Beitrag leer ist ... Wenn Du da irgendeinen Inhalt reinschreibst, sollte innerhalb von <div class="entry"></div> wieder "valides" HTML stehen.

Sowas hier?

Inhalts-Übersicht (gunnART - Grafik, Layout, Konzeption)

Müsste ich noch mal ein bisschen "ordentlicher" schreiben, aber vom Prinzip her ist es als PlugIn schon fertig. Der Index kann auf zweierlei Weise angezeigt werden:

Entweder man schreibt in PHP

show_AlphaIndex('navi') - Für das verlinkte Alphabet
show_AlphaIndex('list') - Für die Auflistung der Beiträge

Oder man legt eine Page bzw. ein Posting an und schreibt (ganz normal im Beitrags-Text)

{AlphaIndexNavi} - Für das verlinkte Alphabet und
{AlphaIndexList} - Für die Auflistung der Beiträge bzw. Seiten

In der Auflistung tauchen aktuell NICHT auf:
- Seiten und Beiträge im Entwurfs-Stadium
- Seiten und Beiträge, die ein Passwort haben
- Seiten und Beiträge mit Status "privat"
- Seiten, die (via SideBar Page Switcher) aus der Navigation ausgeschlossen sdin
- Seiten, die extern weiterleiten (siehe PlugIn Page Links-To)

Ein bisschen dran rumbasteln möchte ich allerdings schon noch, bevor ich das "auf die Menschheit" loslasse ...

Guck mal hier:

hobbingen.de :: Software-Schmiede

Wenn Du den SideBar Page Switcher installierst und statt "wp_list_pages" eine andere Anweisung, nämlich "sps_list_pages" benutzst, sollte Dein Problem gelöst sein ... Du kannst dann für jede Page mit so einem Dropdown-Feld bestimmen, ob sie in der SideBar angezeigt werden soll oder nicht.

Jede nicht angezeigte Seite muss allerdings einzeln "ausgeschaltet" werden.

Eventuell brauchst Du das PlugIn auch gar nicht - Wenn z.B. alle Seiten, die Unterseite von blablabla sind, nicht angezeigt werden sollen, hast Du mit entsprechenden Einträgen bei "exclude" vielleicht weniger Arbeit. Oder du legst fest, dass ohnehin nur "Oberseiten" ausgegeben werden.

Was für Dich praktischer ist, hängt also in erster Linie davon ab, was Du in Zukunft so vorhast ...

Diese WYSIWYG-Editoren funktionieren mit JavaScript - Der größte Teil der "Reaktionen" und "Verhaltensweisen" (wie meinetwegen aus "info@beispiel.de" automatisch einen mailto-Link machen etc.) läuft auf dem eigenen Rechner und nicht etwa irgendwo online ab.

Es kann also gut sein, dass einige Dinge auf manchen Systemen (und manchen Browsern) problemlos laufen, während andere Systeme (oder andere Browser) einfach immer wieder "komische Sachen" veranstalten.

:-)

... aber irgendwie hab ich das Gefühl, dass da "Handlungsbedarf" besteht ... Im Grunde genommen wundert's mich fast, dass diese ganzen "bunten Mixturen" funktionieren. Ob das bei zukünftigen Upgrades weiterhin so bleiben wird ... Mal gucken.

Falls Du in der "wp-config.php" Einträge à la

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

stehen hast - Kommentier die doch mal aus:

//define('DB_CHARSET', 'utf8');
//define('DB_COLLATE', '');

Bei der Gelegenheit hab ich feststellen dürfen, dass mitnichten alle Datenbank-Tabellen in meiner Datenbank das selbe Charset haben. Woran das liegt - Keine Ahnung.

Aber ich schätze, dass besonders "ältere" Blogs, die evtl. noch die Version 1.52 mitgekriegt haben, mehrfach upgegradet worden sind, vielleicht auch zwischendrin mal von Webhoster A zu Webhoster B "umgezogen" wurden, mit einer fröhlich bunten Mixtur verschiedener Codierungen funktionieren.

Aber eben nicht mehr funktionieren, wenn man einmal zentral vorgibt, wie die vorliegenden Daten interpretiert werden sollen.

Den Ordner SOLLTE man sogar manchmal leeren, beispielsweise bei Upgrades oder wenn man an seinem Theme herumbastelt. Sichern braucht man da nichts.

Ein PlugIn ist ebenfalls nicht zwingend erforderlich. WordPress hat seit Version 2 "eigene" Caching-Funktionen, die (wie Missi richtig sagt) mit dem Eintrag

define('ENABLE_CACHE', true);

in der wp-config.php "angeschaltet" werden. Hat man das Pech, auf einem Server mit safe_mode = On zu sitzen, sollte man diesen Eintrag auf keinen Fall setzen - der bremst das System nur unnötig aus. Wer sich im Footer die Anzahl der Datenbank-Abfragen anzeigen lässt, kann die Wirkung vom Cache ganz gut nachvollziehen. Dann ist es keine Seltenheit, dass beim ersten Aufruf einer Seite unten locker mal 60 Abfragen angezeigt werden, beim zweiten Aufruf sind's dann nur noch 12 ... Wenn man auf einem safe_mode-Server sitzt, bleiben das immer aberwitzig viele Abfragen - und das muss nicht sein. Zumal die meisten Webhoster mit safe_mode ohnehin nicht für Geschwindigkeit berühmt sind.

Dann gibt es noch ein PlugIn namens WP-Cache - Das hat aber mit den WordPress eigenen Caching-Funktionen nichts zu tun. Dieses PlugIn speichert komplette Seiten als statische HTML-Files, nutzt dazu ebenfalls den Ordner "wp-content/cache" - daher wohl das Missverständnis.

Übrigens funktioniert DAS PlugIn auch bei safe_mode = On, der Cache-Ordner muss nur auf #777 gesetzt werden. WP-Cache hat aber so einige Macken, außerdem kann's bei einigen Langsam-Hostern gut und gerne 5 Sekunden dauern, bis eine "zum ersten Mal aufgerufene" Seite erzeugt und als statisches File abgelegt worden ist. Wäre zu verschmerzen, aber es werden für jeden Besucher, für den ein Cookie gesetzt ist (beispielsweise weil er als User registriert ist oder schon mal einen Kommentar geschrieben hat) neue HTML-Files angelegt.

Von dem Gedanken "PlugIn installieren, Cache-Lebenszeit auf einen Monat erhöhen - und dann hab ich irgendwann mal eine schnelle Seite" kann man sich leider verabschieden, denn die meisten Besucher bemerken erst beim "zweiten" Besuch einen Geschwindigkeitsvorteil. Wenn die überhaupt ein zweites mal kommen, denn 5 Sekunden wartet kaum jemand gerne auf ein paar Zeilen Text.

Dann gibt's noch eine dritte Lösung, die ich für problematische Webhoster empfehlen würde: PluginOutputCache | All Things Seen and Unseen - Ebenfalls eine Caching-Routine, die schreibt die gecacheten Werte aber in die Datenbank und braucht keinen Ordner auf dem Server. Das PlugIn kann also auch bei safe_mode = On problemlos genutzt werden.

Tipp: Auch wenn das Ding "PlugIn Output Cache" heißt, kann man damit auch alles Mögliche andere cachen. Auch WordPress-Funktionen ... Die meisten Template-Tags müssen ja nicht gleich als HTML ausgegeben werden, man kann sich die Werte "zurückgeben" lassen.

Auf die Weise kann man beispielsweise Seiten- und Kategorien-Auflistungen und vieles mehr in einem Array sammeln - und diesen dann abhängig von der aufgerufenen Seite Cachen oder den gespeicherten Wert wieder abrufen. Zugegeben - das kann ein ziemlicher Fummelkram werden, aber wenn man das "Glück" hat, einen WordPress-Auftritt einrichten zu dürfen, der auf einem Strato-Business-Paket liegt ... Es macht schon eine Menge aus, wenn man die Anzahl der Datenbank-Abfragen von um die 30 auf unter 7 pro Seite bringen kann.

Jo, das geht.

So etwas Ähnliches hab ich auch schon programmiert, aber für Seiten, die mit dem PlugIn Page Category Organiser verwaltet werden. *denkdenk* ... Ähm ... Und das war eh ein ziemlicher Spezial-Fall, dieser ganze Auftritt ... Neee, da müsste ich noch n gut dran rumschrauben, damit das "allgemein" verwendbar ist.

Normal läuft das mit den Galerie-Übersichten ja so:

1) Galerie Hochladen.
2) Eine Seite anlegen, dort [mygal=Galerie-von-Vorhin] eintragen
3) Abspeichern
4) Sich die Seiten ID merken
5) Wieder in die Galerie-Verwaltung rein
6) Dort bei der Galerie-von-Vorhin die ID der eben abgespeicherten Seite zuweisen, damit die Übersichts-Funktion "weiß", wo die Galerie-von-Vorhin angezeigt wird

--> Und eben diese Einträge werden als Grundlage für die Galerie-Auflistung benutzt. Seiten, die man dort "vergessen" hat, tauchen in dieser Auflistung gar nicht auf ...
--> Ist nicht sonderlich komfortabel - Und eine "automatisch mitwachsende" Galerien-Übersicht ist so natürlich nicht möglich. Allerdings ist das kein Fehler der mygallery, die ist halt so flexibel, dass sie einen nicht auf bestimmte "Strukturen" festnagelt ...

Aber wenn man für sich selbst weiß, dass man keine Galerie auf mehreren Seiten anzeigt, dass man meinetwegen nur "Pages" für Galerien benutzt, dass alle "Galerie-Seiten" eine gemeinsame "Mutterseite" haben etc. - Dann kann man auf den ganzen Zuordnungs-Krams im mygallery-Menü verzichten und sich seine eigene Anzeige "stricken"

... kann Dir jetzt nicht sagen, wann ich dazu komme, momentan bin ich ganz gut beschäftigt - Aber so eine "automatische" Auflistung ist auf jeden Fall möglich, die Beschränkung auf die drei neuesten ist dann auch kein Problem mehr ... Was ein bisschen Performance kosten wird, wäre "das jeweils erste Galerie-Bild" anzuzeigen - Aber wenn Du den WordPress-Cache aktiviert hast, müssen diese ganzen "Berechnungen" nicht dauernd neu ausgeführt werden.

Also ich guck mal, wann ich dazu komme - und meld mich dann noch mal.

Schiet ... Funktioniert das immer noch nicht?

Erst einmal in der "version.php" (Ordner wp-admin) gucken, was dort steht. Normal müsste dort

$wp_version = '2.2';
$wp_db_version = 5183;

zu lesen sein. Was steht da bei Dir?

Wenn dort noch irgendwas mit 2.13 steht - Dann sind wahrscheinlich nicht alle Dateien, die für das Upgrade nötig sind, hochgeladen worden - und WordPress sieht noch keinen Bedarf, die Datenbank zu aktualisieren.

.
.
.

Ansonsten ... wir wissen ja nun, dass der Fehler nicht an irgendwelchen "alten", zwischengespeicherten Daten liegt - WordPress "kennt" die Funktion "get_private_posts_cap_sql" augenscheinlich tatsächlich nicht.

Guck mal in der Datei "post.php" (ebenfalls im Ordner wp-admin) nach, ob es dort diese Funktion gibt. Sollte eigentlich in Zeile 1573 auftauchen.

Wenn nicht, dann ... naja, ich würd die neuen WordPress-Dateien einfach noch mal erneut hochladen. Und falls es beim letzten Versuch daran gescheitert sein sollte, dass eventuell einige Dateien schreibgeschützt waren oder aus anderen Gründen nicht "überschrieben" worden sind - Bist Du auf der sicheren Seite, wenn Du die beiden Ordner "wp-admin" und "wp-includes" umbenennst ... beispielsweise in "wp213-admin" und "wp213-includes" ...

Dann kannst Du die neuen "wp-admin" und "wp-includes"-Ordner ohne Rücksicht auf Verluste hochladen - und sicher davon ausgehen, dass auch WIRKLICH alles da ist.

Was willst Du denn genau finden?

Wenn ich Dich richtig verstanden habe brauchst Du

- Die "Unterseiten" einer bestimmten "Mutterseite"
- Von denen nur die, auf denen auch wirklich eine Galerie zu sehen ist
- Und zwar nicht alle, sondern nur die neuesten drei ...?

Das ist eigentlich nichts, womit die myGallery was zu tun hat, bei den Galerie-Übersichten rappelt die nur die Seiten runter, die Du in irgendeiner Galerie (unter dem Menüpunkt Galerie-Verwaltung) als Übersichtsseite einer bestimmten Galerie eingetragen hast.

Eine Funktion, die automatisch alle Seiten findet, auf der eine Galerie gezeigt wird - und zwar unabhängig davon, ob man so "fleißig war", jede Galerie-Seite nochmals in der Galerie-Verwaltung zu vermerken - gibt es leider nicht, die muss man selbst programmieren. Und die läuft darauf hinaus, die Inhalte von x verschiedenen Seiten komplett einzulesen und daraufhin zu untersuchen, ob [mygal=irgendwas] im Inhalt vorkommt ...

Der Blog-Beitrag von wegen "Cache-Problem gelöst" bezieht sich auf WordPress 2.1 - In den darauffolgenden Versionen hat der Cache keine Probleme mehr gemacht.

Das Thema SafeMode - Leg eine Datei namens "info.php" in Dein Hauptverzeichnis, Inhalt

<?php phpinfo(); ?>

Wenn Du dann http://www.deineseite.de/info.php aufrufst, sollte Dir eine ziemlich ausführliche Tabelle mit allen Einstellungen ausgegeben werden, die für Deinen Webspace gelten.

Ist vielleicht ein bisschen unübersichtlich, dort "mit gucken" nach safe_mode zu suchen - Einfach Strg-F drücken, und den Browser nach der Zeile mit "safe_mode" suchen lassen.

Oops, da hast Du schon gepostet, während ich noch geschrieben hab ...

- PlugIns brauchst Du keine für den WordPress-Cache
- Selbst anlegen muss man den nur, wenn der Ordner wp-content keine Schreibrechte hat (Bei mir ist wp-content "frei", schreibgeschützt sind allerdings die Ordner "plugins" und "themes")
- Mit aktiviertem WordPress-Cache sollte Dein Blog ein gutes Stück schneller werden ...
- Eine fette Leistungsbremse ist der WordPress-Cache allerdings, wenn man auf Servern mit safe_mode = On sitzt ... nutzt dann auch nichts, wenn man den cache-Ordner auf #777 setzt ...

Es gibt ein PlugIn namens WP-Cache, das ist aber ein anderes Paar Schuhe - Das speichert komplette Seiten als statische HTML-Files ab ...

Den WordPress "Object Cache" kann man mit einem Eintrag in der wp-config.php anschalten:

define('ENABLE_CACHE', true);

Und dann legt WordPress normalerweise automatisch einen Ordner namens "cache" in deinem "wp-content"-Ordner an.

Das war jetzt aber bloß eine "wilde Vermutung" - nur hab ich heute 5 WordPress-Installationen von 2.13 auf 2.2 upgedingst - Und jedes Mal gab's anfangs verschiedene Fehlermeldungen - die jedes Mal nach "einmal Cache ausleeren" weg gewesen sind.

Beziehungsweise musste man manchmal noch übergangsweise in der wp-config das ENABLE_CACHE auskommentieren, damit nicht dauernd irgendetwas Neues/Altes/Falsches in den cache-Ordner geschrieben wird.

... Mal den Ordner wp-content/cache leeren?

Statische Seiten haben schon ein Datum ... Wahrscheinlich ist für Dich die letzte Änderung interessant - Die findest Du unter post_modified ...

Du müsstest eine neue Datenbank-Abfrage mit $wpdb->get_results konstruieren und die Ergebnisse nach post_modified sortieren lassen.