[stese 4.6.8_060806] fehler kategorie konfiguration

[oio]

hallo an die gemeinde,

hat jemand eine idee, wo ich hiermit weiterkomme:

source: stese 4.6.8_060806
- standardinstallation mit mandanten und beispiel (komplett)
- einziger setup-fehler: kein gdlib installiert

ohne irgendwelche einstellung oder anpassungen vorzunehmen, erhalte ich folgenden fehler, wenn ich versuche eine der angelegten kategorien zu konfigurieren (beim abspeichern):

Warning: Cannot modify header information - headers already sent by (output started at *server*/contenido/classes/class.template.php:249) in *server*/contenido/includes/functions.general.php on line 290

administration system log:

[13-Aug-2006 21:45:15] PHP Warning: Cannot modify header information - headers already sent by (output started at *server*/contenido/classes/class.template.php:249) in *server*/contenido/includes/functions.general.php on line 290

teilweise gehen template-konfigurationen für die kategorien beim versuch des speicherns oder einfach bei aufruf verloren.

soweit habe ich das ganze nachvollziehen können:
- in der class.template wird wohl der seitenteil per echo ausgegeben
- in der functions.general soll wohl wieder per header auf die übersicht geschoben werden

header kann hier also nicht funktionieren, da schon ein echo erfolgte.

alles mögliche habe ich durchgesucht und mit früheren versionen verglichen, in denen der fehler nicht auftrat (allerdings anderer server).

merkwürdig auch, dass bisher kein ähnlicher fall im forum zu finden ist.
das macht mich schon stutzig.

danke für unterstützung

cu
cg

[stese]

lade die dateien noch mal hoch. das sieht sehr stark nach nem übertragungsfehler aus. und wenn möglich nicht mit wsftp

[oio]

hi stese,

danke für deine rückmeldung

ich benutze webdrive, bzw. die shell des linux um den source zu übertragen.

exakt die gleiche version habe ich jetzt einfach mal auf einen 1und1 server übertragen (installiert) -> ergebnis: es läuft problemlos

fast ärgerlich, da das finden des fehlers echt schwierig wird.
die source kann aber also als direkte ursache ausgeschlossen werden.

der fehler taucht nicht auf in der vorkonfiguration der templates.

wenn du übertragungsfehler schreibst, hast du bestimmte teile in verdacht?
die server-einstellungen sind recht hart. selbst die chmod-änderungen kann ich nur als root über die konsole machen.


bei der gelegenheit eine frage: warum haben die dateien seit den aktuellen versionen scheinbar einen utf-8 header wurden aber nicht ordentlich von ascii nach utf-8 transformiert?
in ultraedit werden mir die dateien in utf-8 geöffnet, sonderzeichen werden aber verhunzt, da die datei wohl noch ascii bit kodiert ist.

cu
cg

edit: ups, meine natürlich iso nicht ascii

[stese]

das mit der übertragung ist eine vermutung gewesen, da wir hier oft den fall haben, dass user mit ws_ftp daten auf den server uploaden und ws_ftp irgend etwas an die dateien vorn anfügt bzw den download auch mal stillschweigend abbricht, so dass eine datei nur halb hochgeladen wurde - das merkt man mitunter erst später, wenn man in dem bereich ist, wo man die datei benötigt.

hast du es mal versucht, die zip hochzuladen bzw bei dir lokal zu entpacken und per gzip oder tarball zu packen und dieses gzip archiv direkt auf dem server zu extrahieren?

zur utf konvertierung kann ich nichts zu sagen. is mir aber auch schon aufgefallen, da ich in einer datei die umlaute ändern musste und diese umlaute in der datei definitiv nicht utf8 gespeichert werden dürfen! die sollten tunlichst im ISO Format belassen werden.

[oio]

mh, der fehler ist echt kein kinderproblem

bisheriges ergebnis:
- übertragung kann als fehlerquelle ausgeschlossen werden
- offensichtlich ist irgendeine konfiguration des servers verantwortlich

ich habe den admin angemailt, um das apache-modul: mod_headers zu prüfen und bzgl. header directive und order of processing zu kontrollieren.

prinzipiell habe ich zwar vollen root-zugriff, möchte aber ungern in der apache-konfiguration rumbasteln.


kann bitte mal jemand zum vergleich ein php(info) auf seinem server laufen lassen und mir mitteilen, ob bei ihm unter "loaded modules" das mod_headers auftaucht?

vielen dank dafür

cu
cg

[stese]

ja läuft bei mir und daneben noch die:

mod_fastcgi, mod_frontpage, mod_userdir, mod_php4, mod_perl, mod_ssl, mod_setenvif, mod_so, mod_usertrack, mod_headers, mod_expires, mod_cern_meta, mod_proxy, mod_digest, mod_auth_db, mod_auth_dbm, mod_auth_anon, mod_auth, mod_access, mod_rewrite, mod_alias, mod_speling, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status, mod_negotiation, mod_mime, mod_mime_magic, mod_log_referer, mod_log_agent, mod_log_config, mod_define, mod_env, mod_vhost_alias, mod_mmap_static, http_core

(all-inkl. großes webpaket, kein managed oder rootserver)

[oio]

vielen dank fürs nachgucken.

das mod_headers läuft jetzt auch auf dem "problemserver"
-> der fehler besteht allerdings weiterhin

grob hatte ich schon mal überflogen, was contenido beim setzen der templatekonfiguration für die kategorien macht.

das werde ich jetzt wohl schritt für schritt auseinandernehmen müssen.

hoffentlich findet sich was ...


kann es ein problem sein wenn der besitzer der dateien, die auf dem server liegen, ein anderer ist, als der user über dem php läuft?

öhm, ganz grundlegende idee nebenbei - kann es daran liegen, dass auf dem server php5 (modul) und nicht php4 läuft?

cu
cg
... dankbar für hinweise, die zur ergreifung des fehlers führen

[oio]

ich habe jetzt erst einmal die zeile 109 in der include.tplcfg_edit.php auskommentiert.

Code: Alles auswählen

               
            } else {
                conGenerateCodeForAllartsInCategory($idcat);
                //backToMainArea($send);
            }

 

hier muss man bei gelegenheit mal nachsehen, da mit php5 offensichtlich variablen fehlen, um die ausgabe des template zu unterdrücken.
eigentlich sollte hier bei änderung der template-konfiguration zur übersicht zurück ge"headert" werden.
mit php5 wird aber trotzdem vorher das template ausgegeben.

cu
cg

edit: gibt es irgendwo eine bug-liste für php5? da sollte man das aufnehmen.

[stese]

welche php5 version ist es denn? im detail? da wir ja auch einige php5 server schon getestet haben und der fehler dort nicht auftrat

[oio]

php version ist: 5.1.2

und buggy ist es immer noch.
die fehlermeldung ist zwar weg, da er nicht mehr zur übersicht springen will, die abzuspeichernden einstellungen gehen aber sogar schon bei aufruf der template-config ohne abspeichern verlustig.

d.h. schon beim aufrufen der kategorie-config semmelt contenido die einstellungen aus der db (setzt sie auf die vorkonfigurationswerte).

arghh, also heute nacht mal die include.tplcfg_edit.php zerlegen/debuggen ...

danke vielmals für deine anteilnahme, stese

cu
cg

[oio]

das ist jetzt nicht die standardinstallation, aber die con_template_conf sieht dann doch nicht wirklich korrekt aus:

idtplcfg idtpl status author created lastmodified
1 1 NULL sysadmin NULL NULL
2 1 NULL NULL NULL NULL
3 1 NULL NULL NULL NULL
4 1 NULL NULL NULL NULL
5 1 NULL NULL NULL NULL
6 1 NULL NULL NULL NULL
9 1 NULL NULL NULL NULL
10 1 NULL NULL NULL NULL
11 1 NULL NULL NULL NULL
12 1 NULL NULL NULL NULL
13 1 NULL NULL NULL NULL
15 1 NULL NULL NULL NULL

cu
cg

[oio]

ok, ich komme der sache hoffentlich näher:

in der template-konfiguration (area: str_tplcfg) werden die beiden [main]-dateien ausgeführt:

include.tplcfg_edit_form.php
include.tplcfg_edit.php

es sollte so sein, dass zuerst die include.tplcfg_edit.php dann die include.tplcfg_edit_form.php includet wird.

auf betreffendem server ist dies jedoch andersherum, so dass das abspeichern, etc. nicht funktioniert und das formular zum editieren ausgegeben wird abwohl eigentlich durch die include.tplcfg_edit.php schon wieder zur übersicht geswitcht werden sollte.

bleibt noch die frage: warum?



cu
cg

[emergence]

hmm...

such mal in der db tabelle con_files
einen eintrag mit
filename -> include.tplcfg_edit.php
filetype -> main

und ändere das filetype dort auf inc

der eintrag sieht irgendwie falsch für mich aus...

falls das bei dir geht und zu keinen weiteren problemen führt, ist das ein bug...

[oio]

das dürfte als main schon ok sein, da es auch in den file array für die main.php als main gesetzt und aufgerufen wird.

aber hier der entscheidende unterschied:

file-array auf 1und1-server:

Array
(
[inc] => Array
(
[0] => includes/functions.con.php
[1] => includes/functions.tpl.php
)

[main] => Array
(
[0] => includes/include.tplcfg_edit.php
[1] => includes/include.tplcfg_edit_form.php
)

)

file-array auf dem problemserver:

Array
(
[inc] => Array
(
[0] => includes/functions.con.php
[1] => includes/functions.tpl.php
)

[main] => Array
(
[0] => includes/include.tplcfg_edit_form.php
[1] => includes/include.tplcfg_edit.php
)

)

man beachte die sortierung im main array und damit die reihenfolge des ausführens.

in der class.backend werden die files nach folgendem schema der db entnommen:

Code: Alles auswählen

$sql .= " ORDER BY b.filename";

jetzt muss ich mal sehen, ob die noch irgendwo sortiert werden und wie ORDER BY arbeitet.

evtl. ist doch eine server-einstellung / mysql-konfiguration verantwortlich.


ganz schön harte nuss für mich als konzepter/designer ...

cu
cg

edit: zur ergänzung - mysql-version: 5.0.22

[emergence]

wieso versuchst du es nicht einfach...
ich bin der meinung das dort inc richtiger wäre als main...

in der class.backend werden die files nach folgendem schema der db entnommen:

Code: Alles auswählen

$sql .= " ORDER BY b.filename";

ähm... auch da kommt mir vor als wäre es blödsinn...

Code: Alles auswählen

$sql .= " ORDER BY b.idfile";

müsste auch die reihenfolge berichtigen...