Beiträge von pufaxx

vielen dank! funktioniert astrein - keine fehler mehr beim xhtml-validator.

ich habe ein problem mit statischen seiten:

gibt es eine möglichkeit, sich ausgeben zu lassen, welcher "eltern-seite" die gerade aktuelle seite zugeordnet ist?

da es bei statischen seiten keine möglichkeit gibt, einzelne seiten einer kategorie zuzuordnen, bin ich folgendermaßen vorgegangen: statt einer kategorie habe ich einfach leere, entsprechend benannte seiten angelegt, und denen dann andere (gefüllte) seiten untergeordnet.

jetzt möchte ich in der horizontalen navigation den gerade aktiven "bereich" hervorheben - und in der sidebar soll ein davon abhängiges menü auftauchen.

für blogseiten gibt's das ja:

<?php if (in_category('xy')) { .... } ?>

aber für statische seiten?
mir fehlt etwas wie

<?php if (is_subpage_of('xy')) { ..... } ?>

bisher sehe ich keine andere möglichkeit, als eine ellenlange if-abfrage ins template zu schreiben, in der ich jede seite aufliste, für die das-und-das gelten soll. geht's nicht doch ein bisschen einfacher? vielleicht über ein plug-in?

tja - kurz nach dem posten wanderte mein blick nach oben: "http://forum.wordpress-deutschland.org/undsoweiterundsofort"

vielleicht sollte man abfragen, ob "$tag->url" mit der zeichenkette "http://" beginnt - und falls nicht, das hinzufügen?

ich glaub, ich koch mir am besten noch mal nen kaffee und greif mir mein schlaues buch - und dann probier noch n büschn rum.

ich meld mich.

hi kingu,

da bin ich in zukunft sicherlich zu faul zu, immer manuell die datenbank durchzufummeln

im endeffekt wäre es zwar eigentlich besser, alle bis jetzt eingegangenen einträge zu korrigieren und für weitere gästebucheinträge eine überprüfung der eingabe vorzuschalten - aber ich hab's dann doch einfacher hingekriegt:

man muss sich die "wall.php" im wordpress hauptverzeichnis vornehmen. vor ausgabe des links (also $tag->url) schneidet man eben von dieser $tag->url alles vorm ersten auftauchen eines "." ab - und setzt "http://www" davor.
so ist es egal, ob die leute, die sich im gästebuch verewigen, "http://" mit eintragen oder es weglassen.

in der "wall.php" (original) steht zur ausgabe des homepage-links folgendes:

<?php if (strlen($tag->url) > 0) : ?>
	[url="<?php print $tag->url; ?>"]<?php print $tag->author; ?>[/url]

ich hab's folgendermaßen verändert:

<?php if (strlen($tag->url) > 0) :
	$tag->url = "http://www".strstr($tag->url, ".");
?>
	[url="<?php print $tag->url; ?>"]<?php print $tag->author; ?>[/url]

... klappt!

ich weiß nur nicht, ob das wirklich so die optimale lösung ist, weil ja nicht alle seiten mit "http://www" beginnen. aber ich denke, es werden nicht so viele gäste auf beispielsweise einen ihrer ebay-artikel verlinken wollen...

wenn man ins rumwall-gästebuch einen link auf eine homepage eingibt, funktioniert dieser nur korrekt, wenn man "http://" vorher eingibt.

hat jemand ne idee, was man machen kann, wenn man schon etliche einträge hat - aber ungefähr 50% der gäste ihre links mit "http://" vornedran eingegeben haben und 50% ohne?

eine idee von mir wäre, irgendwie vor der ausgabe des gästbuch-inhaltes bei den links immer abzufragen, ob die jeweils angegebene internet-adresse ein "http://" vorne dran hat - und falls nicht, diese zeichenfolge automatisch mit zum ausgegebenen link dazuaddieren zu lassen.

da ich nicht SO der PHP-experte bin, wollte ich mal fragen, ob jemand sein gästebuch dahingehend bereits modifiziert hat --- ansonsten heißt es für mich wohl "kaffeemaschine anschmeißen, buch zur brust nehmen - und herum(wall)probieren..."

[sollte ich zu einem tauglichen ergebnis kommen, werde ich das hier selbstnatürlich posten, aber wie gesagt: falls jemand schon was hat - ich wäre für hilfe dankbar...]

http://www.deineseite.de/wp-admin/wall-options.php

aktivier da mal den haken bei "disable spam protection" - jedenfalls bei mir hat das gästebuch erst dann reagiert.

ich hatte das gleiche problem.

jetzt funktioniert's, nach dem ich die besagte zeile 11 einfach auskommentiert hab.

"wp-content/plugins/RumWall.php"

du musst dafür sorgen, dass auf deiner seite ein link zu deiner "wall.php" auftaucht.

dazu könntest du beispielsweise in deinem template die "sidebar.php" entsprechend bearbeiten.

bei mir gibt's keinen. welchen fehler gibt's denn bei dir?

lösung:

die lösung ist ganz einfach (hab ich mich zuerst gar nicht zu versuchen getraut): in wp-content/plugins(RumWall.php einfach die zeile löschen oder auskommentieren, die ärger macht. in unserem fall ist das die zeile 11:

require_once(ABSPATH.'wp-content/plugins/RumLib/common.php');

weg damit - und es funktioniert.

ich hab das gleiche problem.

in zeile 11 wird nach einer datei namens "common.php" gesucht, die sich im plug-in unterverzeichnis "wp-content/plugins/RumLib" befinden soll.

im rumwall-script war aber keine datei so benannte datei enthalten...

watt nu?

zu gzip konnte ich in der strato-FAQ nichts finden.

meine info.php spuckt mir folgendes aus (was vielleicht entfernt was mit gzip zu tun hat... ich hab leider echt keine ahnung von PHP, ich fummel mich da eher so durch...)

PHP Variables
_ENV["HTTP_ACCEPT_ENCODING"] --> gzip, deflate

zip
Zip support --> enabled

bz2
BZip2 Support --> Enabled
BZip2 Version --> 1.0.2, 30-Dec-2001

kannst du damit was anfangen?

ach ja - seit ich meine .htaccess auf php 4.3.9 umgestellt hab, ist meine seite NOCH ein stück langsamer. ob ich nun bei optionen/lesen gzip aktiviere oder nicht, macht keinen unterschied.

wenn ich php 5.0.2 aktiviere, funktioniert kein link mehr --- ich werde immer auf die startseite geleitet.

schiet, mensch - die performance ist einfach zum davonlaufen, momentan... ich hab zwar den wp-turbo installiert, aber der hat auch nur ein kleines bisschen verbesserung gebracht. woran kann das liegen?

*hüpf* es klappt!

in der .htaccess kann man strato beibringen, sämtliche .php-dateien mit php 4.3.9 oder php 5.0.2 (beide mit GD 2kommanochwas) zu interpretieren. voreingestellt ist hier 4.1 (mit GD 1.6).

änderung in der .htaccess:

AddType application/x-httpd-php5 .php

und jetzt funktioniert's.

danke für eure hilfe!

hört sich doof an.

nu gut - eigentlich brauche ich die galerie auch nicht unbedingt. aber alleine die performance (und die ist im vergleich zu den anderen wordpress-installationen, die ich gemacht hab WIRKLICH mehr als mau) wird mich dann wohl zu einem anderen hoster treiben.

goodbye, strato.

p.s.: wie nahtlos kann man eigentlich einen hoster wechseln? ich hab nämlich n paar sachen für kunden (tut man nicht, ich weiß - aber die hatten halt keine mySQL-datenbank) bei mir liegen - muss ja nicht sein, dass die n paar tage weg vom fenster sind...

p.p.s.: wen empfehlt ihr? (ich brauch mindestens 5 domains und 3 mySQLs. schickes software-paket wäre auch nicht falsch...)

vielen dank erstmal für die antwort...

das plug-in findest du hier.

jaja, strato und die rechte --- das kann z.b. eeewigkeiten dauern, bis man irgendein CMS von seinem server wieder runtergelöscht hat, voll scheußlich. mit WS_FTP (pro-version) hab ich es aber jetzt scheinbar hingekriegt, alle die galerie betreffenden ordner auf 777 zu setzen. sicher bin ich mir da allerdings nicht, GoLive zeigt was anderes an als WS_FTP.

--> funktioniert leider immer noch nicht.

moinmoin,

ich hab bei einer 1und1 domain wordpress installiert - läuft tadellos. und dort funktioniert auch die lazy-gallery.

bei strato funktioniert auch alles tadellos (nur blöderweise reichlich langsam - werde wohl bald mal wechseln...) probleme bei strato macht mir aber die lazy gallery: es werden keinerlei thumbnails generiert.

ich dachte zunächst, das problem läge darin, dass ich's auf einer der nebendomains ausprobiert hab - jetzt zeigt sich aber: auf der hauptdomain klappt es auch nicht.

info: ich hab ein paket mit 5 domains, und strato verlangt für jeden domainnamen einen entsprechend benannten ordner.

die lazy-gallery.php (im ordner "wp-content/plugins") muss dann für nebendomains so bearbeitet werden, dass im pfad zum ordner "wp-gallery" der name der nebendomain auftaucht.

in meinem falle also

$gallery_address = '/nebendomainname/wp-gallery/';

und für die hauptdomain reicht dann:

$gallery_address = '/wp-gallery/';

alles weitere funktioniert - aber wie gesagt: keine thumbnails, nur rote "x".

woran kann das liegen?

diese schritt-für-schritt-anleitung oben war kein "so macht man das", sondern eher so ein "das hab ich gemacht, und es funktioniert wieder".

kann also gut sein, dass der ein oder andere schritt da überflüssig war (so wirklich die ahnung von webserver-geschichten hab ich nämlich nicht...)

wenn phpMyAdmin gar nicht in einem verzeichnis läuft, auf das du zugriff hast, könnte es auch sein, dass du dir phpMyAdmin mit permalink-gefummel auch gar nicht zerschießen kannst. bei mir lief jedenfalls NICHTS mehr - und ich war schon ziemlich verzweifelt. auch meine anderen domains beim gleichen hoster (domain-umleitung) waren nicht mehr erreichbar.

ich hab alles nur wieder zum laufen gekriegt, indem ich die .htaccess aus dem wordpress verzeichnis gelöscht hab - und meine wordpress-installation selbst (durch ändern des passwortes an der datenbank) außer betrieb gesetzt hab.

danach liefen alle anderen domain-weiterleitungen wieder, phpMyAdmin hat wieder funktioniert. und dem musste ich ja beibringen, dass die wordpress-datenbank jetzt ein neues passwort hat - und dazu braucht man die config.inc.php

[phpMyAdmin hab ich übrigens nachträglich draufgespielt, ist bei strato nicht vorinstalliert...]

grüße,

gunnar

die ganzen .htaccess hab ich mittels FTP-programm umbenannt.

eine config.inc.php gibt es im phpMyAdmin-verzeichnis (zumindest in meinem) aber tatsächlich. da sind die datenbanken mitsamt passwort dazu eingetragen.

grüße,

gunnar

funktioniert wieder ...!

vielen dank für die antwort.

also: ".htaccess" war das erste, was ich probiert hab, danach war aber nur die startseite funktionstüchtig, alles andere hat aber immer noch fehlermeldungen verursacht.

wie gesagt - nicht einmal phpMyAdmin hat funktioniert.

gelöst hab ich das problem dann folgendermaßen:

1. bei strato im kundenbereich das passwort für die wordpress-datenbank geändert.
2. die ".htaccess" im root-verzeichnis komplett gelöscht
3. die ".htaccess" im phpMyAdmin-verzeichnis umbenannt
4. die confic.inc.php im phpMyAdmin-verzeichnis an das geänderte passwort der wordpress datenbank angepasst
5. aus dem (jetzt wieder funktionstüchtigen) phpMyAdmin.menü heraus in der wordpress-datenbank nach "permalink_structure" gesucht und den eintrag dort gelöscht

---> und: funktioniert jetzt wieder alles.

vielleicht hilft das ja jemandem weiter, der ein ähnliches problem hat.

ich hab ein ähnliches problem wie hier: http://forum.wordpress-deutschland.org/viewtopic.php?t=979

im backend wollte ich mal probieren, die permalinks umzubasteln, aber jetzt geht leider nichts mehr. auch das backend ist nicht erreichbar - und (ich vermute, dass ich das problem über die datenbank lösen kann) - in das phpMyAdmin komme ich auch nicht mehr rein.

kann mir irgendjemand helfen? ich will nicht alles noch einmal installieren müssen...

weblog-adresse: http://www.gunnart.de