Hilfe - Suche - Mitglieder - Kalender
Vollansicht: Uploadproblem bei grösseren Modulen
Forum Sefrengo.org > Allgemeine Foren > Anwenderforum
Mephistos
Mhh

Bekomme immer die Meldung
"Es wurde keine gültige *.cmsmod- Datei hochgeladen", wenn ich das Modul hochladen will.

Hab jetzt schon zweimal gedownloaded, weil ich dachte, beim DL wäre was schief gelaufen. Die Version 1.03.01 ist doch die aktuellste und sollte doch damit funktionieren, oder?

Schade sieht nämlich wirklich super aus und ist genau das, was ich brauche :-/

Hat jemand ne Idee?

Danke
MaZderMind
Du hast auch schon dran gedacht das ZIP-Archiv vorher zu entpacken, oder?

Gruß, Peter
Mephistos
ZITAT(MaZderMind @ Fri. 19. January 2007, 01:17) *
Du hast auch schon dran gedacht das ZIP-Archiv vorher zu entpacken, oder?

Gruß, Peter


Hehe :-). Ja. Hab auch schon andere Module erfolgreich bereitgestellt.

Die Datei, die ich auswähle zum Upload heißt: MrList_v02_05_01.cmsmod

Dann kommt immer die Fehlermeldung. Ich checks nicht :-(
amk
keine ahnung ... bist der erst mit solchem problem ... geht's denn mit anderen modulen (oder bspw. auch der MrList-standard-version im package)?
Mephistos
ZITAT(amk @ Fri. 19. January 2007, 10:50) *
keine ahnung ... bist der erst mit solchem problem ... geht's denn mit anderen modulen (oder bspw. auch der MrList-standard-version im package)?

Mhh. Also irgendwas stimmt da wirklich nicht (bei mir).

ContentFlex, MrList melden beide diesen Fehler.

Navigation2.0 hat aber funktioniert.

Ich hatte gestern mal ein paar Stunden das ganze unter die Lupe genommen und die cmsmod Datei verändert. Wenn ich aus dem input Tag einen Großteil lösche funktioniert der Upload auf einmal (nur Inhalt gelöscht - alle XML Tags blieben bestehen). Aber ansonsten bricht er schon direkt beim ersten Tag (dem <name>) ab und meldet den Fehler. Dafür verantwortlich ist der preg_match Befehl im Repository.

Mir ist schon klar, dass es grundsätzlich funktionieren muss und es kein Fehler im Quellcode oder der cmsmod Datei sein kann, weil es ja bei allen funktioniert. Ich wollte dem nur mal auf den Grund gehen.

Das einzige was mir noch einfällt, wäre irgendeine serverseitige Konfiguration, die da mit reinspielt.

Hat vielleicht jemand ne Idee, ob es an irgend einer PHP Einstellung liegen könnte.

Ich bin echt ratlos. Eventuell installiere ich Sefrengo noch mal neu. So jedenfalls bringt es leider nix :-(

Danke schon mal
Meph

P.s. Was meinst Du mit der Standard Version. Ist MrList bei den vorinstallierten Modulen dabei? Bei mir nicht.
MaZderMind
Hi
Auf was ist deine upload_max_filesize in der phpinfo gestellt?

Gruß, Peter
amk
ZITAT(Mephistos @ Fri. 19. January 2007, 13:13) *
P.s. Was meinst Du mit der Standard Version. Ist MrList bei den vorinstallierten Modulen dabei? Bei mir nicht.

nein das meine ich nicht ... ich meine damit die im zip-archiv befindliche nicht vorkonfigurierte version.

bitte alles weitere zu modulinstallationsproblemen im anwender-forum. smile.gif
mistral
Hallo zusammen

Ich habe den Fhler auch schon gesehen. Scheint am Sever zu liegen. Ich habe das Problem aber noch nicht gelöst.
Aber folge Infos dazu.
Es liegt nicht am ZIP-Support. (cmsmod sind nicht komprimiert)
Es betrifft alle Module die eine gewisse Grösse haben (ca. 50kB)
Der Fehler tritt an folgender Stelle auf:
Datei class.repository.php
function cms_mod($xmlstring)
Zeile 492
QUELLTEXT
if(!preg_match("/(<" . $key . ">)(.*)(<\/" . $key . ">)/ims", $xmlstring, $match) && $key != 'config' && $key != 'repository_id' && $key != 'install_sql' && $key != 'uninstall_sql' && $key != 'update_sql') return '1603';


Ich vermute es liegt am memory welches für den Seitenauafruf limitiert ist. Das ist aber nur ein vermutung.

@MaZderMind: an upload_max_filesize liegt es meiner Meinung nach auch nicht, da dass Modul bei mir komplet hochgeladen war, aber die Auswertung mit dem preg_match in die Hose ging.

@Mephistos
Php-Version?
Betriebssystem?
Apache Version?
Gruss
Reto
Mephistos
ZITAT(mistral @ Fri. 19. January 2007, 13:33) *
Hallo zusammen

Ich habe den Fhler auch schon gesehen. Scheint am Sever zu liegen. Ich habe das Problem aber noch nicht gelöst.
Aber folge Infos dazu.
Es liegt nicht am ZIP-Support. (cmsmod sind nicht komprimiert)
Es betrifft alle Module die eine gewisse Grösse haben (ca. 50kB)
Der Fehler tritt an folgender Stelle auf:
Datei class.repository.php
function cms_mod($xmlstring)
Zeile 492
QUELLTEXT
if(!preg_match("/(<" . $key . ">)(.*)(<\/" . $key . ">)/ims", $xmlstring, $match) && $key != 'config' && $key != 'repository_id' && $key != 'install_sql' && $key != 'uninstall_sql' && $key != 'update_sql') return '1603';


Ich vermute es liegt am memory welches für den Seitenauafruf limitiert ist. Das ist aber nur ein vermutung.

@MaZderMind: an upload_max_filesize liegt es meiner Meinung nach auch nicht, da dass Modul bei mir komplet hochgeladen war, aber die Auswertung mit dem preg_match in die Hose ging.

@Mephistos
Php-Version?
Betriebssystem?
Apache Version?
Gruss
Reto

OK. Erst mal danke fürs verscheiben und sorry.

Kann Dich nur bestätigen. Dieser preg_match Befehl ist die Ursache für mein Problem.

Server ist wie folgt:
Apache/2.0.54 (Debian GNU/Linux) PHP/5.2.0-7~bpo.1

Upload_max_file_size liegt bei 2MB, sollte also eigentlich kein Problem darstellen.

Schade, dass Du noch keine Lösung gefunden hast. Wie oder wo kann man den Speicher für den Seitenaufruf bestimmen?

Ich werd wohl mal ein ernstes Wörtchen mit meinem Provider sprechen müssen ;-)

Danke auf jeden Fall schon mal.
STam
Tausch mal die Zeile 526 gegen diese aus:
QUELLTEXT
$match = null; $key = null; $value = null;
... und teste nochmal.

Gruß

Edit: ich meinte Zeile 500
bkm
Hatte das Problem unter PHP 5.2.0 auch, hat wohl was hiermit zutun
Laufzeit Konfiguration was jetzt neu ist.
mit setzen von pcre.backtrack_limit=-1 hats funktioniert
Mephistos
Leider hat der Tipp von STam nicht funktioniert.

Dann hab ich in der main.php folgendes eingefügt.
CODE
ini_set('pcre.backtrack_limit',-1);


Habs auch über ini_get_all überprüft. Lokal war richtigerweise die -1 gesetzt. Leider hats trotzdem nicht funktioniert.

Hab meinen Provider jetzt noch gebeten das direkt in der php.ini zu ändern. Allerdings eher aus Verzweiflung, weil das ja eigentlich keinen Unterschied machen sollte.

Ich bin ratlos. Schade.
mistral
Hallo zusammen

STams Tip funktioniert bei mir auch nicht, auch wenn ich die Zeile 500 ersetze.

Bei mir funktioniert aber das Setzen der pcre.backtrack_limit.

Ich habe die Zeile vor dem while eingefügt und so funktioniert es bei mir.
QUELLTEXT
ini_set('pcre.backtrack_limit',-1);
        while (list ($key, $value) = each ($this->_xmlexport['mod'])) {
            // funktionalit?t von cmsmod v0.2 bleibt erhalten
            if(!preg_match("/(<" . $key . ">)(.*)(<\/" . $key . ">)/ims", $xmlstring, $match) && $key != 'config' && $key != 'repository_id' && $key != 'install_sql' && $key != 'uninstall_sql' && $key != 'update_sql') return '1603';


@Mephistos ev funktioniert es ja so auch bei Dir.
STam
Vieleicht könnte jemand mal diese Zeile vorher einbauen (am besten vor dem while (list ($k...):
QUELLTEXT
flush();
ob_end_flush();
... damit wir mal eine richtige Fehlermeldung bekommen smile.gif
... oder gleich die Methode so ersetzen (nur zum Testen!):
QUELLTEXT
/**
    * repository::cms_mod()
    *
    * Parse and check a Module XML-Code
    *
    * @param string  $xmlstring Module Content
    */
    function cms_mod($xmlstring) {
        $trans_tbl = get_html_translation_table (HTML_ENTITIES);
        $trans_tbl = array_flip ($trans_tbl);
        $xml_array = array();
        flush();
        ob_end_flush();
        while (list ($key, $value) = each ($this->_xmlexport['mod'])) {
            // funktionalitaet von cmsmod v0.2 bleibt erhalten
            if(!preg_match("/(<" . $key . ">)(.*)(<\/" . $key . ">)/ims", $xmlstring, $match) && $key != 'config'
                && $key != 'repository_id' && $key != 'install_sql' && $key != 'uninstall_sql' && $key != 'update_sql') {
                echo preg_last_error();
                return '1603';
            }
            $match['2'] = strtr ($match['2'], $trans_tbl);
            if ($key == 'created' && $match['2'] < 1) $match['2'] = time();
            if ($key == 'lastmodified') $match['2'] = time();
            if ($key == 'author') $match['2'] = $this->_auth->auth['uid'];
            $match['2'] = make_string_dump ($match['2']);
            $match['2'] = $value == 'char' ? (string) $match['2'] : (int) $match['2'];
            $xml_array["$key"] = $match['2'];
            $match = null; $key = null; $value = null;
        }
        ob_start();
        if ($xml_array['repository_id'] == '' ) $xml_array['repository_id'] = $this->gen_new_mod($xml_array['name'], true);
        return $xml_array;
    }

Und dann könnte man noch damit PHP: Memory Usage, was testen.

Gruß

P.S.: übrigens meinte ich oben die Zeile 500... nicht 526, Sorry.
Mephistos
So. Also nachedm mein Provider die php.ini geändert hatte und es immer noch nicht klappte, hab ich kurzerhand Sefrengo komplett neu installiert.


Und schwupps, schon funktioniert es :-)

Wahrscheinlich hab ich bei meiner ganzen "Self Dubuggerei" wohl irgendwas übersehen.

Vielen, vielen Dank auf jeden Fall für die ganze Hilfe hier und den Trick mit dem backtrack_limit, auf den ich im Leben nicht gekommen wäre.

Danke.
mistral
@STam

ZITAT
flush();
ob_end_flush();

ergab keine neue Fehlermeldung.

Mit der neue Funktion hat der upload auch nicht funktioniert, einzige eine '2' wurde zusätzlich ausgegeben. Dies entspricht 'PREG_BACKTRACK_LIMIT_ERROR'.

PHP: Memory Usage funktioniert bei mir nicht da PHP ohne --enable-memory-limit kompiliert wurde.

Gruss
Mistral
bjoern
Der Bug ist seit Sefrengo 1.4. behoben. ini_set('pcre.backtrack_limit',-1) ist da bereits im Core enthalten.
SefrenTo
ZITAT(bjoern @ Mon. 12. November 2007, 12:38) *
Der Bug ist seit Sefrengo 1.4. behoben. ini_set('pcre.backtrack_limit',-1) ist da bereits im Core enthalten.


Ein Update wäre mir zu heikel bei einem laufenden Projekt. Kann ich in irgendeiner Datei diese Zeile austauschen "ini_set('pcre.backtrack_limit',-1)".

Wenn ja, welche Datei muss ich modifizieren und an welcher Stelle und wo befindet sich diese Datei???

Danke für die Tips!
gunwalt
ZITAT(SefrenTo @ Tue. 13. November 2007, 11:47) *
Ein Update wäre mir zu heikel bei einem laufenden Projekt. Kann ich in irgendeiner Datei diese Zeile austauschen "ini_set('pcre.backtrack_limit',-1)".


Auch eine Zeile auszutauschen, würde ich als Update bezeichnen.
SefrenTo
ZITAT(gunwalt @ Tue. 13. November 2007, 14:10) *
Auch eine Zeile auszutauschen, würde ich als Update bezeichnen.


OK aber welche Zeile ist es????????????

Danke für eure Hilfe!
gunwalt
Welche Version von Sefrengo?

Eine einzelne Zeile zu ersetzen könnte ganz andere Auswirkungen haben, als ein richtiges Update.
SefrenTo
Ich hab Version 01.04.00.

Wie geht denn das Update? Was müsste ich ersetzen?

Danke und Grüße!
andi
im wiki gibt es einen upgrade-leitfaden.

gruss andi
SefrenTo
Hab grad gesehen, dass ich mit 01.04.00. scheinbar schon die neuste Version installiert habe.

Also muss ich vielleicht doch diese Datei einzeln ändern.
Kann mir vielleicht irgendwer doch noch verraten wie diese Datei heißt und wo sie liegt?

Danke und Gruß!
andi
hallo

also, wie hier im beitrag geschrieben handelt es sich bei der von dir gesuchten datei um backend/inc/class.repository.php. da du allerdings schon die neuste version am laufen hast und dieser bug darin schon behoben ist lieft es wohl eher am upload_max_filesize in deiner php.ini (bei mir 32 mb). mach dir eine php-datei mit folgendem inhalt:

QUELLTEXT
<?php phpinfo(); ?>


lade sie per ftp auf dein webspace und rufe diese danach per browser auf. dann siehst du, welche upload_max_filesize bei dir eingestellt ist. falls du die erhöhung nicht selber vornehmen kannst, kontaktiere dein hoster.


gruss andi
SefrenTo
dry.gif hab grad gesehen das die Server zu voll war und die Datei nicht mehr hochgeladen werden konnte.
Es lag also nicht an dem upload_max_filesize (der laut php-info übrigens bei 8MB liegt).

Schade das sefrengo diesen missverständlichen Fehler ausgibt, sonst wäre ich vielleicht früher drauf gekommen.

Vielen Dank für eure Hilfe!!!
andi
ZITAT(SefrenTo @ Wed. 14. November 2007, 12:14) *
Schade das sefrengo diesen missverständlichen Fehler ausgibt, sonst wäre ich vielleicht früher drauf gekommen.

sorry, aber da solltest du dir schon selbst einen um die ohren klatschen blink.gif. schade um die zeit der antwortenden, welche für «das problem» drauf ging. bei den heutigen ressourcen denkt wohl kaum einer an speicherknappheit.


gruss andi
SefrenTo
Ok, das kam in der Anwort vorhin wohl nicht ganz rüber, das ich mir schon einen um die Ohren geklatscht hatte....
Da ich das aber nicht auf meinem eigenen Server, sondern auf dem eines Kunden installiert hatte, hatte ich dieses Problem aber leider auch nicht auf dem Schirm...von daher wäre eine entsprechende Fehlerausgabe wirklich nicht schlecht.

Aber nochmals DANKE an alle die mir geantwortet haben!!!
maeldrew
Hallo zusammen

Genau dieses Problem hatte ich beim dedi, es half nicht mal eine neu installation. Da ich dort im Schilf stehen gelassen wurde, suchte ich nach einer Alternative und ich fand nach kurzem suchen Sefrengo.
Ich habe es installiert und mit Sefrengo funktioniert es problemlos.
Nun ja, so vieles habe ich schon gesehen was mir an Sefrengo besser gefällt, vom Layout bis zu den vielen kleinen und sehr praktischen Änderungen und die Community scheint hier echt hilfbereit zu sein. rolleyes.gif

Gruss Thomas
FireFlyer
Hab genau das gleiche Problem! Kann mir jemand dabei helfen?

Sefrengo v01.04.00

phpinfo.php

Wenn alle Stricke reissen sollten, dürfte doch noch die harte Tour über das direkte Einfügen in der DB gehen, oder?

Brauch nur noch 2 Module. Gästebuch und Fotoalbum.
bkm
du wirst wohl mit ini_set bzw. mit php_flag die php einstellung während der laufzeit nicht überschreiben können.
darum funktioniert es nicht.
Dieses ist eine vereinfachte Darstellung unseres Foreninhaltes. Um die detaillierte Vollansicht mit Formatierung und Bildern zu betrachten, bitte hier klicken.
Invision Power Board © 2001-2024 Invision Power Services, Inc.