Beiträge von pufaxx

Vier Zentimeter? Holla.

Bei meiner Auflösung maximal die Hälfte. *g* Aber darum geht's ja nicht.

--> Die Ursachen können vielfältig sein. Guck mal in den Quelltext, was auf Deinen Unterseiten "nach" Deinem Text kommt und was auf Deiner Startseite "nach" Deinem Text kommt.
--> Ich würd zuerst im Stylesheet mal gucken, was bei #bottomcontentdouble steht. Vielleicht hat das Ding ja eine "Höhe", die Dir einfach zu hoch ist.
--> Dann gibt's da etliche DIVs, die einen Innenabstand von unten haben könnten (und wahrscheinlich auch haben) ... Also auch die mal angucken.
--> Ein paar mehr davon ineinandergeschachtelt - und schon hat die eine Seite mehr "Fleisch" unten, als die andere ...

Würde mich wundern, wenn die myGal auf Strato funktioniert. Immerhin "erzeugt" die sich ja je hochgeladenem Ordner ihre eigenen "tumbs"-Ordner. Sofern der Server das zulässt. Und da bei Strato eigentlich immer safe_mode=On ist, glaub ich kaum, dass man die myGal dort zum Laufen bringen kann. Da funktioniert ja (normalerweise) nicht einmal der WordPress-Cache ...

myGal-Thumbnails dürften vermutlich nur dann "klappen", wenn man zu jedem Ordner "per hand" einen selbstgemachten "tumbs"-Ordner mit hochlädt, den man dann via FTP auf #777 setzen muss. ...

Oder man hat Glück - und kann Strato austricksen - was aber leider nicht immer funktioklappt ...

Geht.

Innerhalb der Loop "weiß" $post alles vom gerade abgefragten Beitrag. Ích nehme an, Du bist nicht an get_the_excerpt(); oder so interessiert? Denn das spuckt (wenn es keinen extra eingetragenen Kurzdings gibt) nur einen auf soundsoviele Zeichen verkürzten Content aus ...?

if (!empty($post->post_excerpt)) {


... irgendwas machen ...


}

Descrription - Wenn Du damit "Meta-Tags" im Seiten-Header meinst, dann geht datt so jedoch nicht ... Das "Problem" am oben genanntem Code ist, dass er nur innerhalb der "Loop" (also in dem Bereich, in dem Inhalte ausgegeben werden, funktionieren kann.

Metatags o.ä. wirst Du damit also nicht bestücken können, denn das passiert in Dateien und Funktionen, die unabhängig von und vor allem VOR der "Loop" ablaufen.

$post->post_excerpt kommt übrigens "unformatiert" daher - vor der Ausgabe müsste man also noch die Umlaute zurechtwandeln und so ...

Ach ja - Hatte ich neulich, so n paar Fälle $post->post_excerpt ist nicht unbedingt immer leer ... Kann passieren, dass man in der täglichen Hektik mal ein Leerzeichen vergisst oder sowas. In dem Fall hätte dann Dein excerpt den Inhalt " " - wäre aber vorhanden. Ist also sinnvoll, vor der Abfrage eventuell überflüssige Leerzeichen zu löschen. normal müsste trim ausreichen.

Nö.

:-)

Beziehungsweise: Was meinst Du genau mit Absätzen? Im Quelltext sehe ich zumindest keine überflüssigen oder "leeren" ...

Anführungszeichen im Beitrags-Titel sind (jedenfalls für den Validator) kein Problem, wenn man vor der Ausgabe die üblichen WordPress-Filter drüberlaufen lässt. ...

Das mit den Feeds ist mir (muss ich zugeben) erst kürzlich aufgefallen, nachdem ich so etliche Titel mit Fragezeichen anstelle der Anführungszeichen gesehen hab ... Aber das muss man doch irgendwie ändern können ...?

Oder anders gefragt - Was für ein Zeichen sollte man stattdessen "weiterleiten"? Denn auf meine Gänsefüßchen mag ich nicht verzichten.

Hast Du schon probiert, Dein Theme direkt über die Datenbank auszuwählen?
Dazu in phpMyAdmin in der Tabelle wp_options nach dem Eintrag "template" suchen - und den Namen angeben (den Namen des Ordners, in dem das Template liegt)

Das sollte klappen, sofern dein Theme nicht irgendwie "kaputt" ist - "kaputt" kann's übrigens schon sein, wenn im Stylesheet die ersten paar Kommentar-Zeilen irgendwie "zerstört" sind.

Zur Not das "mitgelieferte" default-Theme wieder hochschubsen und übergangsweise DAS aktivieren. ...?

Desweiteren ist #777 eigentlich unnötig. So viele "Rechte" brauchen die Dateien sicherlich nicht. Seit WP2.2 klappt's aber (jedenfalls bei mir) nicht mehr, irgendwelche Theme-Dateien auf #444 zu setzen ... ist beinahe wurscht, welche ich "schützen" will - Prompt hab ich auch ne weiße Seite und das Template "schaltet sich selbsttätig aus" ... Warum auch immer ... Scheinbar ein neues Feature, dessen Sinn sich mir noch nicht so recht erschließen mag ...

Also auch noch mal nachkontrollieren, ob nicht eventuell doch noch irgendwo ne geschützte Datei rumschwirrt.

Annalena: Man kann statische Seiten übrigens auch kommentieren. Guck einfach mal in die single.php rein. Dort solltest Du normalerweise

comments_template();

finden ... Das nur an die entsprechende Stelle Deiner page.php (oder was auch immer) rüberkopieren.

:-)

... und einfach mal NUR

<?php the_content(); ?>

probieren?

Ansonsten könntest Du noch in deineseite.de/wp-admin/options-reading.php reingucken und bei "Zeige für jeden Beitrag ..." --> "den ganzen Text" auswählen ...

Und keiner von Euch hatte ne Meldung in der "JavaScript-Konsole" vom FireFox? Kein "gelbes Dreieck" unten links im InternetExplorer?

[size=8]auch keine ganz kleine Meldung?[/size]

Hm ...

Seit WP2.2 scheint das System zumindest bei den JS-PlugIns eine andere Anordnung von Sprachdateien zu "erwarten". Falls Ihr (zusätzlich zum TinyMcDings) noch irgendwelche anderen PlugIns mit JS-Funktionen aktiviert habt - die sich im Übrigen nicht einmal direkt auf das Texteingabefenster auswirken müssen - Eine Abhilfe könnte sein, bei denen in den "Hauptdateien" mal nach den Stellen zu forschen, in denen irgendwelche Language-Files importiert werden.

Diese Files waren aber in den meisten Fällen auch schon vorher "nicht da"...

Im Grunde genommen ist es ganz banal - WP/TinyMCE findet weiterhin Dateien nicht, die vorher auch nicht da waren. Und diese werden weiterhin in Ordnern nicht gefunden, die vorher ebenfalls nicht da waren. Nur wird jetzt augenscheinlich in anderen Ordnern, die nicht da sind, nichts gefunden als in denen, in denen vorher schon nichts gefunden wurde. Und die JS-Konsole zeigt einem eine Fehlermeldung in einer Datei, die es nicht gibt - und diese Fehlermeldung besagt, dass es die Datei nicht gibt, in der der Fehler gefunden wird.

Alles klar?

*g*

Jedenfalls hat's "deshalb" bei mir jetzt schon in zwei Fällen komplette "Editor-Knock-Outs" gegeben. Auch der Standard-Editor war in beiden Fällen weg ...

"Reparatur:" Auf die ohnehin nicht vorhandene Deutsche Übersetzung einiger PlugIns verzichten. Zumindest den Versuch, eventuell vorhandene Language-Files einzubasteln testhalber auskommentieren - dann BrowserCache und nen Kasten Bier leeren - und noch mal probieren.

:-)

Tipp (falls nicht schon geschehen) - Im Browser so ziemlich alles einschalten, was Java, Jalta, Malta, Debugging, Konsole, Protokollierung weißdergeier Klaus Dieter heißt. Sonst sagt einem der Browser nur ungern, was ihn stört ...

Ich weiß jetzt nicht genau, was Du brauchst - aber es ist kein Problem, den "Benutzerdefinierten Feldern" bestimmter Seiten (und oder Beiträge) so Einiges mit auf den Weg zu geben.

Was ich damit hingekriegt hab ist z.B. ein "Auswahlmenü-PlugIn" für jeden Beitrag und jede Seite, in dem man sich beim Schreiben "zusammenklicken" kann, was in der SideBar angezeigt wird ... Und ob das nun "Menüpunkte", "Link-Kategorien", die neusten Kommentare aus Kategorie "Borkenkäferparade" oder gleich ganze "Beiträge"/"Seiten" sind - eigentlich Banane. Hauptsache die single.php "weiß" ein paar Variablenwerte bzw. bekommt eine Möglichkeit, sich diese zu "holen" ...

Ausgehend von meinem angesprochenen "MiniPlugIn" (noch nicht serienreif) - Es sollte wirklich kein Problem sein, das dahingehend aufzubohren, dass man festlegen kann: "Du Beitrag Bla zeigen drunter Tabelle Dings und Bericht tralala" - Damit wäre der Beitrag Bla in der "Kalenderlogik" drin, über das Datum zugänglich aber gleichzeitig "fix" mit Tabelle Dings und Bericht tralala gekoppelt. Seiten und Beiträge gleichzeitig - auch kein Problem.

Und man ist ja beileibe nicht drauf festgenagelt, nur Beiträge anzuzeigen, bloß weil datt Ding single.php heißt.

:-)

Wenn man dann noch ein bisschen weiter herumtrickst, könnte man z.B. auch vorm Aufruf von get_header(); bei einer page.php eine 301er-Weiterleitung zum "Mutterbeitrag" rein-automatisieren, sobald die jeweilige Page unterhalb von ... einer Seite namens ... meinetwegen ... "invisible" oder sowas liegt. Wenn denn bestimmte Inhalte partout nicht "allein" erreichbar sein dürfen. Alles machbar. Auch (und gerade) mit Wordpress ...

Nicht ganz "untricky", aber wenn man sich einmal sorgfältig überlegt, wie man was anlegen oder weiterhin verwalten will, kriegt man das ziemlich sicher hin.

... und warum sollte man jetzt noch nach ner 2.12er-Sprachdatei suchen?

:-)

öhm ... was gibst Du denn in deinen Seitentext ein, damit diese ganze DIV-Geschichte inklusive Bild "aufgebaut" wird?

Nach der Funktion müsstest Du suchen ... Und (den Bereich von myGallery hab ich noch nie genutzt ...) - wenn dort irgendwo irgendwelche "Bildmaße" berechnet und als style eingefügt werden sollten ... wechdamit.

Das Bild hat schon eine Breite und eine Höhe, das sollte reichen. Die Maße vom Rest ergeben sich aus den Maßen des Bildes (plus Innenabstand und Randdicke) - Und diese Folge-Maße sind eben nur DANN in allen Browsern gleich, wenn Du nicht noch zusätzlich "für außendrum" irgendwelche Werte wiederholst ...

Upsa, gute Frage eigentlich.

Vielleicht einmal unter "Deiner Lieblings-Kategorie" veröffentlichen und danach die "NebenKategorien" dazuwählen? Müsste man mal näher ausprobieren, aber ich meine, wenn man "in mehreren Kategorien gleichzeitig" veröffentlicht, wird a) nach der "Hierarchie" und b) nach der ID der Kategorie vorgegangen.

Jedenfalls dürfte der Permalink für ein Single-Posting (sobald er erstmal erzeugt ist) nachträglich nicht mehr geändert werden, auch wenn man noch ein paar Kategorien "dazuklickt" ... Jedenfalls hat jeder Single-Beitrag nur einen "Permalink" - und dafür dass dieser (und wirklich nur dieser) erreichbar ist, gibt's PlugIns wie beispielsweise "PermalinkRedirect" ...

Äh, wie lang?

(siehe Anhang ...)

:-)

upsa ... Ich hab mir gar nicht den Quelltext angeguckt ...

<div class="myinlinepictureleft" style="width:243px">
<div class="myinlineborder"  style="width:243px"><a rel="#"><img class="myinlinepictureimg" src="#" alt="bla" title="bla" width="243" height="161"  /></a></div>
<div class="myinlinepicdescription"><span>Sonnenuntergang im Naturbad</span></div>
</div>

Demnach ... Nimm mal am besten wieder die Original-Styles ... (hätte nicht damit gerechnet, dass den umschließenden DIVs eine "Breite" mit auf den Weg gegeben wird) ...

Das ist einerseits ganz praktisch, denn damit steht schon mal etwas FEST. Andererseits doof für Ausreißer wie Internet-Explorer, der Padding und Randbreite von fixen Breiten abzieht, während andere Browser diese Werte hinzufügen ...

Aber wurscht. Jedenfalls kannst Du durch die "fixe Breite" von der Eigenschaft "overflow: hidden" Gebrauch machen. Damit bleibt alles so breit wie es festgelegt ist, auch wenn sich der Inhalt vergrößert. Überstehendes sollte "abgeschnitten" werden. Musst Du mal gucken, was wie wo wupp auf welchem Browser und so ... Kennt man ja, das Gezeter ...

:-)

Irgendwie ist der Quelltext für diese Zwecke auch ... naja ... ungeeignet, sagen wir mal so ... Man kann nicht an DREI Stellen eine fixe Breite vorgeben - und an DREI Stellen gleich auch noch Padding und Border. IE-Scheiße hin, IE-Scheiße her - Damit weicht der (immer noch am weitesten verbreitete Browser) beinahe zwangsläufig an DREI Stellen - und zwar multipliziert mit den aufaddierten Breiten vom Standard ab.

Auch wenn andere Browser auf Breiten-Angaben bei Inline-Elementen nicht reagieren, bei IE ist es nun mal möglich, einem Inline-Element zu sagen, wie breit es sein soll ...

... Fehlt nur noch so n draufstolzierter "To Cool for IE"-Button, und ich ziehe meinen Hut in absoluter Ehrfurcht ...

:-)

Ich hab datt Ding selbst ja auch nicht an. Nur ... auch WENN der aus ist, läuft halt immer noch ein Haufen Sachen mit Ajax, Omo, Viss und JavaScript. Bei mir haben nach dem Upgrade z.B. nicht mal mehr die "Standard-Editor"-Knöpfe funktioniert - bloß weil ich vergessen hatte, den "Update-Monitor" auszuschalten ...

Also bei einigen Dingern bin ich am Überlegen, ob ich sie nicht doch lieber wieder mit WP1.52 anlegen sollte. Da ist man auch ohne Object-Cache mit unter 10 Queries pro Seite ausgekommen ... Hach ja ... Als "easy-2use-CMS" für kleinere Auftritte mit einem "News"-Bereich find ich's irgendwie fast besser ...

By the way - Weiß noch nicht wirklich, woran das liegt - Aber hast Du mal versucht, mit WP2.2 deine Theme-Dateien auf #444 zu setzen? Warum geht dann eigentlich NICHTS mehr? Theme wird "abgewählt" - Weiße Seite und Ende Gelände? Das war doch nicht immer so?!

... ist mir noch nicht aufgefallen ...

Liegt aber wahrscheinlich daran, dass ich eh alles zwanzig Mal als "Entwurf" speichere, bevor ich auf "Veröffentlichen" klicke.

Aber kann gut sein, dass die Kiste seit 2.2 ein wenig anders reagiert. Bei absolut "frischen" Seiten (also beim ersten Klick auf "Schreiben / Seite") ist es bei einigen PlugIns (die mit benutzerdefinierten Feldern arbeiten) früher noch nicht möglich gewesen, irgendwelche Werte einzugeben. Das ging immer erst, sobald die Seite wenigstens als Entwurf gespeichert und somit eine ID vorhanden war.

Jetzt (hab ich zumindest den Eindruck) verhalten sich einige dieser PlugIns ein bisschen "gnädiger" als vorher. Aber eventuell haut das die Page_Links_To-Geschichte wiederum raus?

... also so "ins Blaue hinein vermutet" - Eine Vergleichsmöglichkeit hab ich grad nicht. Hab grad nur entweder WP 2.010 oder WP 2.2 am Laufen. 2.13 ist momentan nix am Start.
... Außerdem hab ich am PageLinksTo-Ding mal wieder irgendwas herumgefummelt. Also bei mir funktioniert's ...

Aber andere lustige Dinge durfte ich heute feststellen:

Einige "Erweiterungen" von der WYSIWYG-Katastrophe machen Terz und sorgen für JavaScript-Fehlermeldungen. Das Pikante dabei: Es werden Fehler in Dateien gefunden, die es gar nicht gibt. Und diese Fehlermeldungen besagen, dass in den Dateien, die es gar nicht gibt ein Fehler gefunden wurde. Nämlich der, dass es diese Dateien jeweils nicht gibt.

Hä? Jawoll. Ich auch. Hä!

WP2.2 erwartet scheinbar bei den TinyMCE-Erweiterungen eine etwas andere Ordner-Struktur in Sachen Language-Files. Bei einem Kunden hat beispielsweise der ImageManager so ziemlich alles, was JavaScript ist, "ausgeknocked".

Hab ich selbst gar nicht bemerkt, weil mein Rechner nicht gleich bei jedem JS-Fehler "kein Bock mehr" hat und aufgibt ... aber so ist nun mal nicht jeder Rechner eingestellt ... War also n büschn Aufstand, den Fehler zu finden - Wie so oft war die Lösung aber ganz einfach: Ich hab bei dem Teil letztlich bloß die Funktion auskommentiert, nach passenden "Language-Files" zu suchen. Die es vorher zwar auch nicht gab, aber egal.

Vielleicht funktioniert PageLinksDings ja wieder, wenn Ihr (sofern vorhanden) einfach mal die ein oder andere WYSIWTF-Erweiterung ausschaltet? Immerhin werden die "Benutzerdefinierten Felder" gleich nach dem Ausfüllen (auch wenn's über ein PlugIn geschieht) aktualisiert und angezeigt. Ich hab zwar nicht wirklich Ahnung von JavaScript, aber von 2.13 zu 2.2 scheint sich da n büschn was getan zu haben ...

--> Vielleicht funkt bei Euch auch irgendein PlugIn dazwischen?
--> Mal JS-Konsole einschalten und auf das schicke, gelbe Warndreieck (jaja, ich surf mit IE, ich geb's zu) unten links achten ...?

a img hat scheinbar kein Padding (Innenabstand) - und beim Hovern gibt's hingegen einen solchen. Deshalb wird das Element beim Mausüberfahren breiter, als es vorher war.

Abgesehen davon rechnen einige Browser "Padding" sowie "Randbreiten" zur Gesamtbreite Hinzu, andere ziehen sie ab. Dürfte in diesem Fall allerdings wurscht sein, weil a) keine Breite angegeben ist und b) das umschließende DIV "floatet" und dadurch (sofern nicht anders angegeben) immer so groß ist wie sein Inhalt.

Die ungewollte "Verbreiterung" könntest Du z.B. "vorwegnehmen" - Also nicht erst für a:hover img einen Innenabstand angeben, sondern gleich schon für a img. Die zusätzliche Farbe kann dann beim Hovern dazukommen. Weil Innenabstand und Border "zusammengezählt" werden, müsste das "normale" Bild also ein Padding von 3px bekommen.

Mein Vorschlag wäre

.myinlinepictureleft {
	padding: 2px;
	border: 1px solid #666;
	background: #fff;
	float: left;
	margin-right: 10px;
	margin-top: 23px;
}


.myinlinepictureleft a img {
	padding: 3px;
}
 
.myinlinepictureleft a:hover img {
	padding: 2px;
	border: 1px solid #666;	 
	background: #c00;
}

Vermutlich wird der InternetExplorer aber wieder aus der Reihe tanzen, wenn das der Fall ist ...

.myinlinepictureleft {
	padding: 2px;
	border: 1px solid #666;
	background: #fff;
	float: left;
	margin-right: 10px;
	margin-top: 23px;
}


.myinlinepictureleft a img {
	padding: 2px;
	border: 1px solid #???;
	/* Hintergrundfarbe wählen, transparent funktioniert für border nicht */
}
 
.myinlinepictureleft a:hover img {
	border: 1px solid #666;	 
	background: #c00;
}

Je nachdem, was sonst noch so für Anweisungen greifen, kann's gut sein, dass die "border"-Anweisung für a img "ausgehebelt" wird. Da die üblichen hässlich-blauen Link-Ränder um Bilder drumherum ziemlich sch..ße aussehen, gibt's viele, die deshalb "sehr starke" Anweisungen wie beispielsweise

* a img { border: none }

in ihr Stylesheet schreiben. Wenn das mit dem Border also gar nicht klappen mag, mal "weiter vorne" gucken, was noch Einfluss haben könnte.

... ich hab mir irgendwann mal Folgendes als "Entwurf" abgespeichert:

<object type="application/x-shockwave-flash" style="width:425px; height:350px" data="http://www.youtube.com/v/HierCodeEintragen">
<param name="movie" value="http://www.youtube.com/v/HierCodeEintragen"></param>
</object>

Das dann bei Bedarf zum Einfügen von Videos einsetzen - WordPress schraubt noch ein <p></p> um das "object" - aber es funktioniert - und es ist sogar XHTML strict.

... zumal man ohne Cookies (über die unterschiedliche Gestaltung von a:link sowie a:visited) nicht nur ebenfalls die bereits besuchten Seiten von den noch-nicht-besuchten Seiten unterscheiden könnte - Diese Unterscheidungsmethode funktioniert sogar für Besucher, die das Setzen von Cookies verboten haben.

Was hingegen einigermaßen SInn machen würde, wäre es, beim Verlassen der Seite das Datum irgendwie abzulegen. Dann könnten bei einem Wiederbesuch alle "ab dann-und-dann" neu hinzugekommenen Postings so ein "NEU!"-Sternchen kriegen ...

(Bin grad am Überlegen, wo man die entsprechende Systemfunktion findet, aber da schlag ich vor, auf Anregungen von Leuten zu warten, die schon ein bisschen mehr Erfahrung mit den WordPress-Cookies haben ...)