2 Probleme

[anne123]

Hallo liebe Leute, ich habe wieder mal 2 Probleme.
Das wird beides ums verrecken nicht angezeigt. error 404.

http://top10charts.eu/cgi-bin/apf4/docs/index.html
http://top10charts.eu/cgi-bin/apf4/apf_config.cgi

http://top10charts.eu/test.php bringt Fehlermeldungen. Ich hatte schon das gemacht:

omega:~# a2enmod include
Module include installed; run /etc/init.d/apache2 force-reload to enable.
omega:~# /etc/init.d/apache2 restart
und allow_url_include als Test aufd obn gestellt. Aber leider kein Erfolg.

Fehlermeldung:
Warning: include() [function.include]: URL file-access is disabled in the server configuration in /var/www/virtual/stripling.eu/top10charts.eu/htdocs/test.php on line 52

Warning: include(http://www.mrrat.com/cgi-bin/apf4/amazon...000Z0UEU6) [function.include]: failed to open stream: no suitable wrapper could be found in /var/www/virtual/stripling.eu/top10charts.eu/htdocs/test.php on line 52

Warning: include() [function.include]: Failed opening 'http://www.mrrat.com/cgi-bin/apf4/amazon_products_feed.cgi?Operation=ItemLookup&ItemId=B000Z0UEU6' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/virtual/stripling.eu/top10charts.eu/htdocs/test.php on line 52

[rbtux]

die ersten probleme sind probleme mit dem script (machdich mal über die problematiken cr crlf etc... schlau) Ein auszug aus der Errorlog wird vermutlich sowas wie permature end of script... zeigen...

das zweite dürfte mit allow_url_fopen zusammenhängen welches in der php.ini unter den gesperrten funktionen eingetragen ist. eventuell für die besagte domain deaktivieren...

[anne123]

Hat leider nichts gebracht. /var/www/fcgi/stripling.eu/php5

; Fopen wrappers ;
;;;;;;;;;;;;;;;;;;

; Whether to allow the treatment of URLs (like http:// or ftp://) as files.
allow_url_fopen = Off

; Whether to allow include/require to open URLs (like http:// or ftp://) as files.
allow_url_include = Off

[rbtux]

hast du die mal auf on gestellt und apache / php-cgi neu gestartet?

[gOOvER]

Naja, hat nichts mit ispCP zu tun. Ich denke dieser Thread kann geschlossen werden.

Wende Dich an den Support von dem Script.

[joximu]

also, ich möchte hier noch feedback geben, was es war:

domain top10charts.eu ist ein domain-alias. Und seit einer Korrektur im Herbst 07 wurden cgi-settings für domain aliase nicht mehr richtig gesetzt (es gab keine cgi-bin setting in der apache config für diese domain).
Habe das nun mit r1004 behoben.
Natürlich stimmten noch ein paar andere Dinge nicht (falscher Perlpfad etc) - aber ich nehme an, das passierte durch das herumprobieren...

Gruss
J

[zpin]

Zu r1004... Der Index in der Zeile (so um 850):

Code:

my ($als_php, $als_cgi) = (@$als_data[22], @$als_data[23]);

stimmt nicht mehr... Sollte 26/27 sein.
Ich sehe allgemein den Nutzen dieses Commits nicht.

[joximu]

Der Nutzen ist eben ein Post weiter oben beschrieben.

Seit r762
http://www.isp-control.net/ispcp/changes...p-als-mngr
stimmt es nicht mehr mit den Indices, die du angesprochen hast.
Damals filene 4 DB-Felder im Select weg bei der Verschönerung des Codes, aber auf Zeile 860 (heute) wurde immer auf als_data[26] und [27] zugrgriffen - die es nicht gab.
Dadurch gab es keine cgi und php-settings für Alias-Domains... (wobei: php lief wohl immer - aber eben cgi nicht).

2 Lösungen: entweder die Indices auf 22 + 23 setzen (hast du wohl bei dir gemacht) oder die Feldliste wieder auf das ursprüngliche erweitern.

Ich habe mich für die zweite Variante entschieden.

Alles klar?
Gruss J

[zpin]

Achso, mein Fehler... Ich führe nen Mercurial Mirror vom ispCP Repo, da hab ich diesen Fehler mal korrigiert. Jetzt hab ich deine Changes reingemerged, und da waren die Indices natürlich wieder falsch.

Hat dadurch natürlich nen komischen Eindruck gemacht... Er fügt ein paar Fields hinzu die nie benutzt werden, und haut gleich noch nen Bug mit rein. Hat er natürlich nicht gemacht, der Commit ist sehr nützlich

Im allgemeinen könnte die ganze Geschichte wohl nen Cleanup vertragen. Die meisten Fields in diesem Query werden nie benutzt, und per Index darauf zuzugreiffen ist (wie man sieht) Fehleranfällig.

[joximu]

cool - ein Spiegel mit Merkur... :-)

zpin Wrote:Im allgemeinen könnte die ganze Geschichte wohl nen Cleanup vertragen. Die meisten Fields in diesem Query werden nie benutzt, und per Index darauf zuzugreiffen ist (wie man sieht) Fehleranfällig.

Es war noch schlimmer - nämlich "SELECT * FROM ..." und dann numerisch drauf zugreifen. War besonders ärgerlich, wenn man zusätzliche Felder in einer Tabelle hatte und der Select über mehrere Tabellen ging - dann verschob sich alles.
Ich habe das mit raphael angesehen (Ticket existierte...) und alle Felder aneinandergereiht (ausgeschrieben) - als er das dann schöner geschrieben hat (alle Felder übereinander) gingen 4 verloren und niemand hat's bemerkt...
In der gleichen Zeit wurde auch zur Funktion doSQL eine doHashSQL erstellt - diese sollte dann ermöglichen, mit Hash-Indizes auf die Ergebnisse zuzugreifen - aber ich glaube, irgendetwas klemmt noch oder es ist ganz schlicht und einfach eine Riesenarbeit (hast du mal nachvollzogen, wie oft diese Resultat-Arrays weitergereicht werden? :-)

So - das war mein Statement zum Montag Abend
Gruss Joximu