Beiträge von Putzlowitsch

Die Tabelle ist 'wp_postmeta'.
Hier gibt es je Attachment, sofern es sich um ein Bild handelt, zwei relevante Einträge.
Zum einen einfach der absolute Dateiname (z.B.):

meta_key = '_wp_attached_file'
meta_value = '/www/htdocs/w007a243/putzlowitsch/wp-content/uploads/2006/11/putzl_1und1_blog.png'

Das kann man einfach per SQL behandeln.
Der andere Eintrag ist aber ein serialisiertes Array, was ungefähr so aussieht:

meta_key = '_wp_attachment_metadata'
meta_value = 'a:5:{s:5:"width";i:810;s:6:"height";i:832;s:14:"hwstring_small";s:22:"height='96' width='93'";s:4:"file";s:81:"/www/htdocs/w007a243/putzlowitsch/wp-content/uploads/2006/11/putzl_1und1_blog.png";s:5:"thumb";s:30:"putzl_1und1_blog.thumbnail.png";}'

Der eigentlich Knackpunkt ist die Längenangabe vor dem String. Die muß stimmen. Falls sich die Länge von altem und neuem Dateipfad nicht unterscheidet, ist man fein raus. Dann kan man auch einfach per SQL Suchen und Ersetzen. wenn doch, müßte man ein kleines PHP-Skript schreiben, was die Metadaten ändert.

Gruß
Ingo

EDIT: Da war ich wohl ein bissl langsam Naja, ich habe zumindest noch eine ausführliche Erklärung mitgeliefert.

Noch ein ergänzender Hinweis zu den Attachments, die mit der WP-internen Uploadverwaltung hinzugefügt wurden.
Wenn das unter der neuen URL auch für die bereits vorhandenen Uploads richtig funktionieren soll, muß zusätzlich zu

UPDATE wp_posts SET post_content =
replace(post_content, 'www.domain.de', 'domain.com');

auch das Feld 'guid' entsprechend behandelt werden:

UPDATE wp_posts SET guid =
replace(post_content, 'www.domain.de', 'domain.com');

Außerdem wird diese guid auch in RSS-Feeds verwendet, und würde dann dort auch nicht stimen.

Falls zusätzlich das ganze auf neuem Webspace liegt, müssen auch noch die Einträge in den Metadaten korrigiert werden. Hier ist jeweils der absolute Pfad der Datei auf dem Server hinterlegt. Falls dieser nicht stimmt, werden die Thumbnails für Bilder von der Uploadverwaltung nicht gefunden.
Das ist aber leider nicht so einfach mit einem SQL-Befehl zu erschlagen.

Gruß
Ingo

Zitat von mastermind

Achso, und Google et al. beherrschen sehr wohl (einfaches) JavaScript, gerade weil es viele Seiten zur Navigation verwenden (traurig, aber wahr). Das habe ich bis vor Tagen auch nicht geglaubt und musste mich eines besseren belehren lassen.

Hmmm, ich habe vor etwa einem Jahr mal ein diesbezügliches Experiment gestartet, weil ich auch wissen wollte, ob Google und andere Suchmaschinen Javascript verarbeiten.
Zumindest wenn man den Code in eine externe js-Datei auslagert, scheint dies nicht der Fall zu sein. Ich hatte einfach drei externe Links zu Seiten auf einer Testseite eingefügt, zwei davon per externer js-Datei und einen normal. Der normale Link wurde nach ein paar Tagen von Google, und auch anderen Suchmaschinen besucht (und wird dies auch regelmäßig weiterhin), die beiden Javascript-Links werden aber von allen Sumas hartnäckig ignoriert.

Gruß
Ingo

Wenn es wirklich .us ist, wäre es schon ungewöhnlich. Google z.B. würde eher unter .com in der Statistik erscheinen.

Hier mal exemplarisch meine Daten von 2006:

1    com   - 44.873    48.37%
2    de   -     35.389    38.15%
3    net   - 8.869    9.56%
4    ch   - 847    0.91%
5    jp   - 632    0.68%
6    at   - 573    0.62%
7    nl   - 206    0.22%
8    hu   - 198    0.21%
9    fr   - 110    0.12%
10    be   - 90    0.10%
11    bg   - 90    0.10%
12    do   - 63    0.07%
13    it   - 63    0.07%
14    dk   - 52    0.06%
15    pl   - 52    0.06%
16    br   - 51    0.05%
17    no   - 48    0.05%
18    cz   - 42    0.05%
19    fi   - 36    0.04%
...
41    us   - 9    0.01%

Gruß
Ingo

Ist komisch, bei mir klappt das ohne Probleme, bei gwen58 wohl auch. Könnte noch irgendwie am konkreten Hostingpaket liegen. Ich habe ein relativ neues "pw* A" (November 2006). Gut möglich, das die Server bei älteren oder anderen Paketen abweichend konfiguriert sind.

Als Trick für Premium-Pakete wäre noch eine Umstellung auf PHP 4.1.2 denkbar, da hier, so die Angaben stimmen, das Memorylimit bei 20M liegt. Nur könnte das wiederum andere nicht vorhersehbare Auswirkungen haben. Ist also eigentlich nicht wirklich empfehlenswert.
Wenn ich das richtig gelesen habe, erfordert z.B. das neue WP 2.1 mindestens PHP 4.2.

Gruß
Ingo

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

Mach doch mal testweise für #rap (das ist der Container für die gesamte Seite) die Breite auf 975 Pixel:

#rap {
  width: 975px;


...

Zitat von Ratlosermann

Ich habe mir mal angeschaut, was du mit der linken Sidebar meinst...jedoch sehe ich kein verschieben der linken Sidebar...oder ich bin noch blind am frühen morgen...:-D

Ähmm, ja. Ich meine auch nicht die linke Sidebar, sondern die rechte, also 'side'. Aber der Sachverhalt ist derselbe, es gibt einen negativen, linken Außenabstand, was den IE möglicherweise verwirrt. Zur Illustration habe ich mal einen Bildschirmabzug dessen gemacht, was der FF-DOM-Inspector anzeigt:
side_rahmen.gif
Der rote Rahmen markiert das 'side'-div, die Listenelemente ragen links darüber hinaus.

Gruß
Ingo

Das verkleinern der des div nutzt nichts, wenn z.B. enthaltene Bilder immer noch die alte Bereite haben.
Etwas ungewöhnlich finde ich auch den negativen, linken Außenabstand der Liste in der Sidebar side2:

#side2 ul {
    list-style-type: none;
    margin: 0px 0px 0px -10px;
    padding: 0px;
    }

Damit ragt die Liste links aus dem Container heraus und bringt vielleicht damit den IE außer Tritt.

Nur mal so, als ein paar Ansatzpunkte.

Gruß
Ingo

Es dürfte daran liegen, das der IE, ja nach eingestellter Sicherheitstufe keine Cookies akzeptiert. Wenn man Cookies für die Seite erlaubt, funzt es.

Gruß
Ingo

Ich muß hier mal noch einen kleinen Nachtrag zu meiner "Holzhammermethode" loswerden.

Die Verwendung der von mir oben gezeigten php.ini führt dazu, das eventuell von Strato in einer zentralen php.ini gemachte Einstellungen, welche von den PHP-Defaultwerten abweichen, unwirksam werden.

Wenn man auf Nummer Sicher gehen will, sollte man sich diese Strato-PHP-Ini zunächst beschaffen, darin die gewünschten Änderungen vornehmen, und diese dann als lokale php.ini verwenden. Aber bitte nur an den Stellen ändern, wo man weiß, was man tut

Es dürfte weniger was mit dem Monitor, sondern eher mit dem Browser zu tun haben.
Bei mir sieht es im Firefox zerhackt aus, im IE6 ist alles gut (in beiden Fällen 19" TFT).

Vermutlich ist irgendwo was im HTML-Quelltext nicht in Ordnung. Merkwürdig finde ich beispielsweise, das als erste Zeile, noch vor dem DOCTYPE der Title-Tag kommt.

Ist wohl so gewesen, wie \0 schreibt:
http://www.heise.de/newsticker/meldung/84074

Vielleicht mal etwas "Lesestoff" zum Thema PHP-Konfiguration bei Strato:
Mit welchen Grundeinstellungen steht PHP bei STRATO zur Verfügung?
So einfach bestimmen und wechseln Sie die PHP-Version

Die php.ini könnte in etwa so aussehen:
[code]

memory_limit = 16M

Das widerspricht zwar etwas diesem hier:
500 Internal Server Error (ganz unten)

Funktioniert aber trotzdem

Gruß
Ingo

Naja, vielleicht nicht gleich ins Kunden-Hauptverzeichnis. Am besten ein Unterverzeichnis anlegen, das z.B. den Name der Domain hat.
Falls noch nicht erfolgt, eine Datenbank einrichten und die Daten in der wp-config.php eintragen. Dann die WP-Datein per FTP in das erstellte Unterverzeichnis kopieren.
Nun das 1und1-Blog löschen, weil sonst die Verwendung der Domain nicht geändert werden kann.
Zu guter Letzt die Domain auf das Unterverzeichnis zeigen lassen (siehe Bild):

1und1config.jpg

Gruß
Ingo

Das ist hier zwar nicht die "Blogshow", wo man ja sofort wegen nicht validem Code angezählt wird ;-), aber dennoch eine kleiner technischer Hinweis auf Grund folgender Warnungen:

Zitat

Zeile 243 Zeichen 1 - Warnung: Element <a> hat proprietäres Attribut "alt"
Zeile 243 Zeichen 87 - Warnung: Bei <img> fehlt das Attribut "alt"

Das ganze wiederholt sich dann noch ein paar mal.
Es ist also so, das bei einem Bild das alt-Attribut gefordert wird, um auch bei ausgeschalteter Grafikanzeige oder puren Textbrowsern etwas sinnvolles anzeigen zu können. Bei Verweisen <a ...> hingegen gibt es das alt-Attribut nicht, hier könnte man stattdessen das title-Attribut verwenden.

Gruß
Ingo

Zitat von SuMu

siehe hier, aktuelles Beispiel:
http://www.finger.zeig.net/2007/01/10/nun-hats-mich-erwischt/

Ist schon krass und hat dazu geführt, das Fingerzeig erst mal dicht ist.
Wen es sonst interessiert, worum es geht, dem seien diese Quellen empfohlen:
http://www.ra-blog.de/2007/01/13/ein-brotchen-fur-6000-euro
http://www.maingold.com/2007/01/15/abm…rions-kochbuch/

Also nur eigene Bilder oder solche aus verläßlicher Quelle verwenden, wo man sicher sein kann, das sie wirklich frei verwendbar sind. Das dürfte aber gerade bei Flickr eher nicht der Fall sein.

Gruß
Ingo

Auch mir hat Helmut mit seiner wirklich verständlichen Erklärung schon geholfen.
Dennoch habe ich noch eine Frage. Kann man den Text, der im Trackback aus meinem Artikel zitiert wird, irgendwie beeinflussen? Oder werden grundsätzlich z.B. die ersten 36 Wörter ab Anfang genommen?

Gruß
Ingo

Gibt es für die deutsche Version wohl doch:
http://blog.wordpress-deutschland.org/2007/01/16/wor…gradepaket.html
fix-205-to-207.zip

Gruß
Ingo

Zitat von mastermind

Letztendlich denke ich aber, dass dieses Plugin nur selten und wenig gebraucht wird. In den wenigen Fällen, denke ich, kann man auch mit dem etwas grobschlächtigeren Interface arbeiten...

Naja, stimmt schon.
Aber das ist ja auch das schöne an quelloffener Software, man kann sich das ganze gegebenfalls selbst (so man kann) nach eigenem Gusto anpassen.
Ich habe mir einfach die SQL-Abfrage bei den Posts um

WHERE post_status IN ('publish', 'static')

erweitert, und schon sehe ich Attachments, Objekte und was es sonst noch so an uninteressanten Posts gibt, nicht mehr.

Gruß
Ingo

Zitat von the0bone

Und dann mal eine kleine BWL Formel

Gesamtkapitalrentabilität = Gewinn * (Fremdkapitalzins) * 100 / (Eigenkapital + Fremdkapital)

Zudem besteht die Gefahr, bei Schulden, also negativem Eigenkapital, in gleicher Höhe wie das Fremdkapital den gefürchteten "Division durch Null"-Fehler zu bekommen. Aber von BWL hab ich nicht wirklich Ahnung

Gruß
Ingo