Beiträge von pufaxx

Wie soll sich der Text denn ändern?

Also soll der Linktext ein anderer werden? Oder soll unter "aktiven" Menüpunkten gleich ein ganzes neues Menü angezeigt werden? Also eine "aufklappende" Navigation?

Für letzteres kannst Du z.B. das PlugIn "SideBar Page Switcher" benutzen ...

1.: User begrüßen sollte kein Problem sein. Man kann ja anzeigen, mit welchem Namen man eingelogged ist. Wann man das letzte Mal online war - das ist sicherlich auch irgendwo hinterlegt, kann ich aber nicht mit Sicherheit sagen. Das mit den "Neuigkeiten" geht (vermutlich) nicht - Man kann in WordPress keine Notizen für Admins oder User hinterlegen. Aber vielleicht gibt's dafür ja ein PlugIn?

2.: Ja, Header abhängig von der Seite geht. Dazu kann man z.B. ein "Benutzerdefiniertes Feld" hernehmen und dort den Namen des Header-Bildes eintragen. Das macht allerdings nur bei einzelnen "Seiten" beziehungsweise in der Einzel-Ansicht von Beiträgen einen Sinn, wenn mehrere Beiträge aufgelistet werden (wie z.B. in der Kategorien-Ansicht) kann man nicht so gut Steuern, von welchem Beitrag denn nun das Benutzerdefinierte Feld ausgewertet wird ... Aber das was Du vorhast - also Headerbilder für die "Haupt-Seiten" - das ist kein Problem.

Hab ich bei mir auch so gemacht. Dazu kann man z.B. die Funktion get_post_meta benutzen.

Vielleicht hab ich Dich jetzt falsch verstanden - Aber "aktive" Seiten und/oder "Kategorien" markieren, kann WordPress ohne zusätzliche Bearbeitung.

- Ein Listenpunkt einer Seite (egal ob aktiv oder nicht aktiv) hat die Klasse "page_item"
- Ein Listenpunkt einer aktiven Seite hat zusätzlich die Klasse "current_page_item"

Neu ab WordPress 2.1:

- Nicht-aktive Seiten, die eine aktive unter-Seite haben, haben zusätzlich die Klasse "current_page_parent".

Knoppaz: Nö - Hier geht es um das ... naja "Verschieben" ist vielleicht das falsche Wort. "Zuordnen", "Seiten-Baum verändern" würde wohl besser passen: Du kannst ja Seiten anderen Seiten unterordnen. Also wenn Du zum Beispiel "Impressum" "AGBs" "Kontakt" als eigene Seite hast, dann werden die unter

irgendwas.de/impressum/
irgendwas.de/agbs/
irgendwas.de/kontakt/

gefunden.

Wenn Du jetzt aber meinetwegen eine Seite "Infos" anlegst und die quasi als "Oberseite" für den ganzen Rechtskrams haben möchtest, dann kannst Du Impressum, AGBs und Kontakt der Seite Infos unterordnen. Dann ändern sich die Permalinks, nämlich so:

irgendwas.de/infos/impressum/
irgendwas.de/infos/agbs/
irgendwas.de/infos/kontakt/

Der Ärger daran ist, dass alle "internen" Links in bereits geschriebenen Beitrags- oder Seiten-Texten noch "die alte Verlinkung" kennen - und sich NICHT mit aktualisieren. Da ist dann entweder Handarbeit angesagt, was unter Umständen ziemlich viel werden kann - Oder man versucht andere Tricks, die "veralteten" Links auf die richtigen Adressen umzuleiten.

Dank Dir für den Tipp!

Interne Verlinkungen sind übrigens auch hier ein Thema: http://forum.wordpress-deutschland.org/allgemeines/19….html#post97253

Vielleicht kann man die Lösungen ja irgendwie kombinieren? Problematisch ist so etwas ja immer, wenn sich Adressen mal ändern ...

Hey, dankeschön.

:-)

Und noch n Nachtrag - hat auch mit internen Verlinkungen zu tun: http://forum.wordpress-deutschland.org/plugins-und-wi…-verlinken.html

Muss ich mal mit herumprobieren.

arno: Stimmt natürlich - das mit dem "ID-Raussuchen" ist schon blöd. Aber dazu gibt's ja das "Page-Linker"-PlugIn ... Das allerdings (und das ist auch blöd) nur mit dem WYSIWYG-Editor funktioniert.

Aber vielleicht ist das ja auch hinzukriegen, man kann ja eigene "Buttons" basteln.

Ansonsten: Wenn ich auf eine eigene Page oder ein eigenes Posting verlinken möchte, hab ich die Seite ja sowieso offen. Denn die komplette Link-Adresse kann man meistens auch nicht "mal eben so" auswendig dahertippen.

Da sieht man zwar nicht die jeweilige ID - aber da man als Admin eingelogged ist, hat man ja unter seinem Beitrag den "Bearbeiten"-Link. Und ob man sich nun die URL aus der Adresszeile oben herauskopiert - oder mit der rechten Maustaste auf den "Bearbeiten"-Link klickt und sich dort die ID merkt - also für mich macht das vom Aufwand her keinen Unterschied.

Olaf: Wenn Du schon zig Seiten mit lauter Verlinkungen angelegt hast, bist Du natürlich ziemlich gekniffen. Aber es gibt doch sicherlich Möglichkeiten, sowas in der Datenbank über Suchen-Ersetzen zu regeln? Ich glaub, es gibt auch ein PlugIn, mit dem man alle Beiträge "Suchen-Ersetzen"-mäßig bearbeiten kann.

Was sind das für Bilder? Sind die vielleicht zu groß? Wenn Du direkt Bilder aus der 5 Megapixel-Digicam hochlädst, klappt das mit der Verkleinerung einfach nicht.

"wp_list_categories" ist die aktuelle Anweisung.

:-)

Wozu die "guid" da ist - verstehe ich ehrlich gesagt auch nicht. Wäre eigentlich echt schön, wenn die immer den aktuellen "Permalink" speichern würde.

Dann würde man sich beim Programmieren einiger Zusatzfunktionen die Nutzung von get_permalink() sparen können - das erzeugt nämlich jedes mal ne Datenbank-Abfrage.

Der tiefere Sinn erschließt sich für mich jedenfalls nicht. Es gibt sogar PlugIns, die (statt nach dem Permalink) nach der guid fragen - und dadurch dauernd fehlerhafte Verlinkungen produzieren (Ich weiß gar nicht mehr was das damals war, ich glaub irgendso ein alphabetischer Index ...? Egal. Hab ich jetzt eh anders gelöst ...)

Wie dem auch sei: Ich bin dazu übergegangen, "blog-intern" mit www.seite.de/?p=123 bzw. www.seite.de/?page_id=456 zu verlinken. Denn die ID eines Beitrags oder einer Seite ändert sich ja nicht, egal wo man sie hinschiebt. Damit danach in Deinen Inhalten trotzdem nur Permalinks ausgegeben werden, kannst Du einen "Filter" bauen - Das hab ich neulich mal für eine (wie ich finde verbesserte) Version des PlugIns "Page Linker" gemacht. Guckst Du hier: "Page Linker" (...) "Automatische Permalinks"

Mein Filter durchsucht alle ausgegebenen Inhalte auf interne Links, die nach entsprechendem Muster konstruiert sind - und macht vor der Ausgabe wieder einen "Permalink" draus. Unter der Überschrift "Automatische Permalinks" steht, wie's grundsätzlich geht - und weiter ("Nachtrag und Version 2") eine verbesserte Version.

Wenn Du bloß den Filter brauchst, kannst Du den Code natürlich auch in ein "einzelnes PlugIn" schreiben ... und nicht vergessen, den Filter dort auch auf "the_content" und "the_excerpt" anzuwenden.

Ich hab den EventCalendar (3.1.1._rc1) auf einer Test-Domain installiert (Wordpress 2.1.3) - und keine Probleme. Allerdings hab ich auch andere Einstellungen:

Der EventCalender steht bei mir in Sachen Zeitzone auf "Wordpress" - und die "Systemzeit" stell ich bei mir mit dem PlugIn "Time Zone" (Version 2.1) ein.

Link: Time Zone (WP Plugin) - Kimmo Suominen

Vielleicht klappt das bei Dir ja auch?

Moinsen ...

Entpacken musst du gzip-SQL-Dateien nicht - Wenn Du die Datenbank wieder herstellen möchtest (also in phpMyAdmin importieren) wird sie entpackt. Und im Regelfall wird auch automatisch erkannt, wie komprimiert worden ist.

Das mit der "sehr großen" Tabelle kann durchaus hinkommen - die meisten Statistik- und Zähl-PlugIns speichern über die Zeit eine ziemliche Menge Daten. Wenn Dein PlugIn keine Funktion bietet, die bereits gesammelten Daten mit einfachem Knopfdruck zu löschen, kann man das natürlich auch "hintenrum" über phpMyAdmin regeln.

wp2_Counterize ist keine Tabelle, die zum WordPress-System gehört. Wenn Du die löschst (bzw. leerst) sollte nichts "kaputt" gehen. Bloß die Statistik fängt dann natürlich wieder bei Null an.

... das selbe Problem ...

Auf der Homepage vom Programmierer steht, wie's geht. Das Problem dabei: Es geht so nicht.

Es sollte so funktionieren, dass man die "dynamischen Bereiche" (also eigentlich nur die betreffenden Funktionen, ganze "Bereiche" kann man augenscheinlich nicht dynamisch lassen) in spezielle HTML-Kommentar-Marken setzt - und diese Bereiche werden dann vorm Cachen nicht ausgeführt, die PHP-Anweisung bleibt damit "erhalten". Soviel zur Theorie.

Praxis: Das erste Problem bei mir war, dass mein Quelltext immer mit

<?xml version="1.0" encoding="UTF-8"?>

anfängt - und in den gecacheten Dateien wird öffnende Dreiecksklammer plus Fragezeichen bei Seiten mit "dynamischen Teilen" zwangsläufig als "Hier beginnt PHP" interpretiert ... was natürlich zu Fehlermeldungen führt.

Hat man das "repariert", gibt's leider weiterhin Fehlermeldungen: Die Funktion (Gefummel mit regulären Ausdrücken), die nach den PHP-Anweisungen sucht, die dynamisch bleiben sollen, arbeitet nicht ganz sauber. Es wird auf jeden Fall nicht der Befehl in die Cache-Datei gespeichert, der eigentlich gefunden werden sollte. Meistens bleibt da irgendein Klappt-Nicht-Grund (kein Semikolon, irgendwo Leerzeichen zu wenig) übrig.

Ich hab wirklich lange herumprobiert - und sogar eine eigene "Such-Find"-Funktion gebaut - Aber auch wenn ich die einsetze - Es kommt einfach nicht das heraus, was heraus kommen müsste. Ich finde die Stelle einfach nicht, an der WP-Cache irgendwelche Leerzeichen, Semikolons etc. löscht oder hindichtet.

Wenn ich die bereits gecacheten Seiten ansehe und die entsprechenden Stellen korrigiere, ist alles wieder in Ordnung. Bloß bringt es herzlich wenig, alle naslang seinen Cache-Ordner auf fehlerhafte Seiten hin zu durchforsten ...?

:-)

Wenn Du ne Lösung gefunden hast - ich bin interessiert ...

Da gibt es zwei Möglichkeiten: Einmal ein PlugIn namens "Fold Page List" (oder so ähnlich) und den "Sidebar Page Switcher" ... wobei letzteres PlugIn noch den Vorteil hat, dass man beim Schreiben einer Seite ein Auswahlfeld angezeigt bekommt, in dem man einstellen kann, ob die jeweilige Seite im Menü angezeigt oder nicht angezeigt werden soll.

So etwas passiert entweder, wenn man CMYK-Bilder erwischt, oder wenn die Bilder schlichtweg zu groß sind.

Und Letzteres dürfte bei Deinen Bildern der Fall sein ... denn die Originalbilder sind ja da - http://www.thomas-hoelscher.de/bilder/Einsliv…%201999/113.jpg - Mit solchen Maßen ist die Gallery anscheinend leicht überfordert.

Also vorher schon kleiner machen. Am schnellsten geht das meiner Meinung nach mit "IrfanView".

Das ist ein Freeware-Bildverwaltungsprogramm - mit eingebauter "Stapelverarbeitung": Damit kannst Du Deine gesamten Bilder vorm Hochladen zum Beispiel auf 800 x 600 Pixel runterrechnen - und wenn Du Lust hast, sogar noch auf jedes ein "(c) 2007 by Tom" als Wasserzeichen draufrechnen lassen, alle Dateien nach einem bestimmten Muster umbenennen und so weiter ... Sehr taugliches Ding, das Programm.

Spart viel Zeit und liefert saubere Ergebnisse.

Bei den ersten Versuchen damit würd ich mir allerdings vorsichtshalber Sicherheitskopien der Originale anlegen. IrfanView hat zwar die Option, existierende Dateien nicht zu überschreiben, aber wenn man noch nicht allzuviel damit gemacht hat ... Man weiß ja nie.

... ist wahrscheinlich schon längst gelöst ...

... aber ich hatte das Problem vorhin auch - Mit der Version 1.03 des SideBar Page Switchers klappt alles wieder.

... seit heute online:

http://www.ostton.info

:-)

... das kann ich jetzt gar nicht so genau sagen. Das Problem besteht vermutlich länger, als dass ich es bemerkt habe.

Meistens speicher ich jeden Beitrag und jede Seite sowieso mehrmals ab, bevor ich mir ihn/sie "von vorne" angucke - nach Druck auf den Knopf fällt mir nämlich eigentlich immer noch irgendetwas ein.

:-)

Ansonsten - große Änderungen - naja - Die üblichen Anpassungen bis "rundum-Erneuerungen" diverser PlugIns. Allerdings bleibt das Phänomen auch bestehen, wenn ich sämtliche PlugIns deaktiviere.

Wenn's nicht vorher schon so gewesen wäre, würde ich auf den PageOrganiser tippen (ein PlugIn, mit dem man Pages in Kategorien sortieren kann. Sehr praktisch übrigens, wenn man "Menügruppen" erstellen möchte, ohne dazu lauter Pages einzeln umzuordnen zu müssen)

Nonono! Die Versionen ab 2.x machen bei mir nur Terz. Am kuriosesten ist dabei für mich das Phänomen, dass die Anzahl der Datenbank-Abfragen proportional zur Seiten-ID steigt - und die ganze Geschichte auf die Weise nach und nach immer langsamer wird.

Ich würd ja inzwischen auch ganz gerne mal umsteigen, vor allem wegen einiger PlugIns, die wirklich praktisch sind. Aber irgendwas ist mit den neuen Versionen noch im Argen. Abgesehen davon hat die 2.05er-Version (wie auch 2.0 und 2.3) im auch in anderen Bereichen im direkten x-mal-auf-F5-hau-A-B-Vergleich gegen die 1.52 geschwindigkeitsmäßig deutlich verloren (Natürlich jeweils völlig frische Installationen, also keine upgegradete Version oder sowas)

Najut, zurück zum Thema: Irgendwie krieg ich den Hänger schon wieder weg. Als letzten Ausweg würde ich ein frisches System hochspielen und in diese Datenbank dann die Pages und Postings der alten Datenbank importieren ... oder ... Ja, Vielleicht hab ich auch irgendwo eine Code-Zeile ungewollt dupliziert. Beispielsweise so etwas:

original_code();

... und daraus soll werden

//original_code();
veraenderter_code();

... nur wenn man im Eifer des Gefechts die Kommentar-Marken vergisst, passieren komische Sachen. Alledings merkt man DAS dann meistens sehr viel eher ... Da werd ich wohl noch mal gründlichst nachgucken müssen. Aber hätte ja sein können, dass das Problem bekannt ist.

Auf einer Wordpress-Seite von mir (WP 1.52) gibt's einen kleinen "Hänger":

Wenn ich eine neue Page erstelle, scheint's zunächst so, als hätte alles funktioniert. Keine Fehlermeldung, die Seite taucht auch als Menüpunkt auf - aber wenn man sie angucken möchte - wird sie nicht gefunden. 404er.

Wenn man dann im Admin-Bereich in die Seitenverwaltung geht und sich die Seite noch mal "vornimmt" - ist auch alles normal, da fehlt nichts.

Die Seite ist aber erst "von vorne" aus erreichbar, wenn man sie ein zweites Mal abspeichert. Als ob sie zunächst "als Entwurf" abgelegt werden würde - was bei Pages ja eigentlich gar nicht geht.

Woran kann das liegen?