![]() |
Probleme mit lauffähigem Upload-Script
Hey ihr Lieben!
Ich benötige für meine Seite derzeit ein Upload-Script, also wollte ich lernen wie man soetwas schreibt. Ich habe mir also verdammt viele Seiten durchgelesen, Codes angeschaut, herum probiert und sonst noch was unternommen...doch irgendwie funktioniert gar nichts. Jetzt habe ich ein Script gefunden, was zumindest ansatzweise zu laufen scheint...zumindest gibt's mir die Rückmeldung, dass die Datei hoch geladen wurde...nur kann ich sie auf meinem Server nirgends finden. Die Datei wird zunächst in den Temp-Ordner hochgeladen und von da aus in den Ordner kopiert, in den ich die Datei auf meinem Server liegen haben möchte. Das wäre in diesem Fall der Ordner "uploads". Das Script sagt mir, dass die Datei nun dort liegt...tut sie aber nicht. Nix da. Kann mir einer von euch vielleicht weiter helfen? Das wäre voll super! Hier der bisherige Code: Code:
<?php Zitat:
Weiß jemand einen Rat? Viele liebe Grüße, Garion |
Hi Bastian,
Ich denke du solltest mal schauen, ob es klappt, wenn du im Script erstmal einen fixen Dateinamen einträgst. Ich hab grad gespickt und den Befehl für den Upload entdeckt. Eventuell mag der Befehl das zusammenbasteln des Namensunterschrift dieser Form nicht. Nur ne idee. Wenn das so ist eventuell eine Variable benutzen. Gruß Heike |
Hat der Ordner "uploads" Schreibrechte auf dem Server? Also chmod 777? Da könnte der Fehler liegen da das Script, so wie es aussieht, nicht auf diese Rechte prüft und somit, auch wenn der Upload wegen mangelnder Schreibrechte fehlschlägt, trotzdem ein positives Ergebnis ausgibt.
|
Hab meine Antwort oben etwas verändert :whistling:
|
Oh, hier hat jemand geantwortet...hab's gar nicht unter "Neue Beiträge" gesehen... :nixweiss:
CHMOD 777 ist drin. Ich versuch's mal mit dem fixen Namen. |
Wenns mit fixem Namen klappt, dann liegts an der Definition mit dem Namen.
As findest du dann aber raus. |
??? :nixweiss: ???
Das ganze Script hat von Anfang an funktioniert...nur hab ich die Dateien auf dem Server nicht gesehen...trotz Trennung und Neuverbindung der Verbindung zum Server...erst durch drücken von F5 zur Aktualisierung wurden die Dateien sichtbar... ...ich habe mir aber an Heike's Kommentar ein Beispiel genommen und habe durch $i date ("d.m.Y-H:i:s-") dem Dateinamen Monat, Jahr, Stunde, Minute, Sekunde vorangestellt...so sollte es nicht zu Dateiüberschreibungen kommen. Vielen Dank euch beiden ;) |
Gerne.
Wie schaust du denn auf den Server. Nicht mit FTP? Gruß Heike |
FileZilla ;)
|
Ok, ich dachte, dass das in der Lage wäre die Änderungen zu sehen ohne dass man immer aktualisiert...
|
Ich nute ebenfalls FileZilla und ich bekomme die Änderungen auf dem Server angezeigt OHNE zu aktualisieren.
|
ein unix-timestamp ist besser als date, da das eine immer fortlaufende Nummer ist.
|
Scheinbar nicht ;)
Ach mist...da waren zwei schneller als ich... ;) Also wie ich schon sagte: Ich find's sehr merkwürdig, aber ich hatte bei FileZilla erst die Dateien im entsprechenden Ordner, als ich F5 gedrückt habe. Selbst ein schließen des Programms und neu Öffnen hat nichts geholfen. Die Dateien lagen da auch definitiv schon vorher und sind nicht zufällig in dem Moment "angekommen", in dem ich F5 gedrückt habe. ;) Was den Unix-Code angeht, so geb ich dir in fast allen Punkten Recht Holger. Gerade für große Uploadzahlen an Dateien ist sowas super. Ich rechne allerdings mit maximal 2-5, wenn ich Glück habe sogar mit an die zehn oder gar knapp über zehn Uploads. Danach werd ich das Script eh nicht mehr verwenden können und es wird im Archiv versinken. Das ist ne einmalige Geschichte mit geringer Anzahl an zu erwarteten Uploads...von daher finde ich persönlich situativ das Datum ganz gut. So kann ich immer gleich auf den ersten Blick sehen, wann die Datei hoch geladen wurde. |
Woran kann es eigentlich liegen, dass das Script keine .avi Dateien hoch laden will?
Habe als erlaubtes Array "avi" drin und als MIME Type von avi alles erlaubt, was ich zu avi gefunden habe...was da wäre:
Dennoch bekomm ich immer die Nachricht "invalid file". Die Dateigröße liegt bei 18Mb und ist somit im erlaubten Größenbereich. Hat jemand eine Ahnung? |
Schau mal in deiner Serverkonfiguration (info.php) nach diesem Wert: upload_max_filesize
Ist dieser seitens des Providers unter 18 MB wird der Upload abgelehnt. |
Hm...ich kann auf meinem Server eine solche Datei nicht finden und im Kundenbereich finde ich ebenfalls keinen Hinweis auf irgendetwas dergleichen...
|
Schau mal in der Hilfe mit dateibeschränkungen. Das kann schon sein. Z.b. Wenn der Web FTP Beschränkungen hat, könnte es der serve auch haben. Ansonsten mal beim Support nachfragen ;)
|
Erstelle eine Datei mit folgendem Inhalt
PHP-Code:
Dann lädst du sie via FTP auf deinen Server und rufst sie über den Browser auf, z.B. http://www.example.com/info.php Dann bekommst du so ziemlich alles was die Serverkonfiguration betrifft, angezeigt. |
Vielen Dank euch für eure Hilfe bis hierher. :ok:
Der Upload mit .avi Dateien scheint vorerst zu funktionieren...was wohl irgendwie an der .php lag. Mein Programmierer hat noch mal rumgebastelt und jetzt läuft es...sagt er...zumindest auf seinem Server...mal sehen wie's bei mir ist. Mit seiner geschriebenen .php gibt's da allerdings ein Problem. Er meint, es würde an meinem Server liegen...und ehrlich gesagt liegt dieser Verdacht auch recht nahe...denn auf seinem Server gibt es dieses Problem nicht. Wenn ich die upload.php im Browser aufrufe, steht ganz oben im Fenster, in der ersten Zeile folgendes: Zitat:
|
google spuckt aus:
http://forum.cmsmadesimple.de/viewtopic.php?id=1887 ich hoffe, dass es das nicht ist. Hier: http://php.net/manual/de/function.session-start.php ist etwas weiter unten in den Kommentaren einer, der den Fehler gelöst hat, in dem er den Session start in die erste Zeile verschoben hat. Das wäre aus meiner Sicht einen Versuch wert. Warum das dann aber beim Progger geht und bei Dir nicht, kann ich nicht sagen. Scheinbaar zeigt nicht jeder Browser diesen Fehler an. Gruß Heike |
Vielen Dank Heike...auch wenn unter deinen Links nicht die gesuchte Lösung war, wär ich dennoch ohne dich nicht auf die Lösung gekommen. Ich habe heraus gefunden, dass das Problem durch BOM's ausgelöst wurde...was das auch immer für Teile sein mögen. Scheint wohl irgendetwas mit Zeichenkodierung und unerlaubten Leerzeilen zu tun zu haben.
Jedenfalls arbeite ich mit Notepad++, wo man die Zeichenkodierung für Speichervorgänge der Dateien auswählen kann. Ich hatte utf-8 gewählt. Habe das auf utf-8 ohne BOM umgestellt und siehe da: Problem gelöst. Vielen Dank euch allen! :yahoo: |
Na da muß man mal drauf kommen, aber schön daß es jetzt funktioniert :ok:
Hier mal was zu BOM: http://de.wikipedia.org/wiki/Byte_Order_Mark |
Freut mich :)
|
So...habe mal Strato angeschrieben. Neben vielerlei Dingen die ich manchmal verstanden und manchmal weniger verstanden habe, haben sie mir aber folgenden Link gegeben, über dessen Bedeutung des Inhalts ich mir aber nicht ganz sicher bin:
:re:http://www.strato-faq.de/1569 Will da mal jemand drüber schauen und mir sagen, was das jetzt für mich persönlich im Klartext heißt? |
Das heißt für Dich im Klartext, dass Du prüfen solltest, welches Paket Du hast und was für eine PHP Version Du aktiviert hast. Danach kannst du schauen, was die Standard-Einstellungen sind und mit dem Programmierer Deines Vertrauens klären, was er für sein Script für Einstellungen haben möchte, damit alles gut klappt.
|
Mit anderen Worten ich kann mithilfe einer php.ini die maximale Upload-Größe festlegen?
|
So wie es aussieht. Wobei ich immer die Standardwerte genutzt habe ;)
Aber wenn du eh einen progger hast, würde ich ihn an Deiner Stelle fragen, was er genau will ;) |
Also...habe heute mal angerufen. Das was ich vor habe ist mit dem POST Befehl gar nicht machbar. PHP unterstützt lediglich eine Uploadgröße von bis zu 10MB. Der Techniker am Telefon hat mir geraten einen FTP Account in das PHP Script mit einzuarbeiten. So könne man auch 5GB hoch laden und es würde keine Probleme geben. Zusätzlich hätte man so die Möglichkeit durch die Abfrage von Upload Geschwindigkeit, Fortschritt etc. pp. sogar Fortschrittsbalken etc. auf der Seite anzeigen zu lassen. Super...dann weiß ich ja jetzt wonach ich googlen muss ;)
|
Wenn Du es gefunden hast, dann wäre das auch für uns hier interessant ;)
Viel Glück |
Also, ich denke ich habe etwas gefunden, bin mir aber nicht sicher. Ich habe es jedenfalls eingebaut. Es läuft aber nicht, da immer folgende Meldung kommt (notwendige Daten durch xxx ausgetauscht):
Zitat:
PHP-Code:
PHP-Code:
Ich habe das versucht, doch dann bekam ich die Meldung vom Browser über ein "unexpected '@' "... :nixweiss: Hat jemand genügend Kenntnisse um mir da weiter helfen zu können? Edit: Ich habe den Befehl $connection_id durch $conn_id ersetzt...es läuft jetzt glaube ich teilweise...mal schauen wie weit ich noch komme... |
Hier das habe ich zu dem ersten Fehler gefunden:
http://www.liga-manager-online.de/lm...p?f=15&t=11706 Bei dem anderen bin ich grad zu müde um weiter zu suchen. Aber klingt so, als ob der Befehl mit dem Usernamen nicht klarkommt. Was ist, wenn Du dich normal mit dem Namen einloggst (z.B. FTP Programm)? |
Was soll der klartext-HTML-Bereich unten? sollte das nicht auch als echo ausgegeben werden?
Den benutzer würde ich mal ohne das @bla.de ausprobieren. |
Dadurch, dass ich die $connection_id Variable in $conn_id umgeändert habe läuft's (fast) rund. Ich kann mich aber zumindest schon mal mit dem FTP Server verbinden, obwohl ich ein @ Zeichen im Usernamen habe. Warum das mit der neuen Variable jetzt kein Problem mehr darstellt weiß ich nicht, aber es läuft.
Der PHP Bereich oben ist die Technik des Formulars, der Klartext-HTML Bereich ist die optische Seite. Diese gibt eigentlich nur die Existenz von Datei-Input-Feld (um die Datei auszuwählen die man hoch laden will) sowie dem Absendebutton aus, was hinter den Kulissen läuft steht im PHP Bereich. Wenn ich jetzt aber den Klartext-HTML Bereich als echo ausgeben lasse...funktioniert die Seite denn dann noch? Also, sieht sie dann noch genauso aus? Greift die .css dann noch? Was ich im Moment noch für Probleme habe: Zitat:
Im Übrigen sieht Zeile 27 noch so ziemlich genauso aus, wie übernommen...außer der veränderten $conn_id Variable: Code:
$upload = ftp_put($conn_id, $lokale_datei, FTP_ASCII); |
Um das ganze mal ins deutsche zu bekommen... Übersetzt lautet die Fehlermeldung so:
erwartet mindestens 4 Parameter, 3 gegeben und das sind diese 3: PHP-Code:
Also denke ich daß in deinem Script irgendwo noch ein Parameter vorhanden ist, der hier nicht übergeben wird und daher diese Meldung auslöst, aber wo? |
Zur Echo-Ausgabe von HTML:
Funktioniert genauso als würdest du es selbst schreiben. Alles was PHP per Echo ausgibt kommt als text beim Browser an, ao als würdest du es selbst schreiben. Der Browser sieht also alles mit Echo ausgegebene wie HTML-Code an (vorausgesetzt es steht innerhalb von html-tags ;)), also kein unterschied. Zum FTP-Put: Also php-manual sagt folgendes: Code:
bool ftp_put ( resource $ftp_stream , string $remote_file , string $local_file , int $mode [, int $startpos = 0 ] ) Also 5 parameter, 1 optional Dir scheint der zweite Prameter "remote_file" zu fehlen, also wie du schon sachst der Zielordner inklusive dateiname als string. Das kann doch theoretisch in jedem Ordner unterhalb deines Webspace-Roots geschehen wenn ich mich recht erinnere... Die Sache ist jetzt, dass man teilweise den Pfad aber absolut (also vom Serverroot ausgehend) angeben muss, und teilweise nicht (also vom webspace root), müsste man ausprobieren Im originalcode steht der Parameter ja auch noch drin ($zieldatei). Der Wert kommt per Post, also aus einem Formular. Warum per Post ist mir nich ganz klar, kommt wahrscheinlich daher weil das Script modular eingebunden werden soll... den Pfad könnte man auch einfach hardcoden auf die variable $zieldatei. Ansonsten per verstecktem Post-Feld aus einem Formular übergeben. mit bestimmten PHP-Variablen kriegt man auch den webspace-rootpfad als variable, wo dat jetz aber genau war müsst ich auch erst nachgucken,weiss aber grad nicht wo :) Hoffe das war nicht allzu wirr :) |
Ich danke dir erst einmal vielmals für deine Antwort. Ich frage mich im Moment allerdings eine einzige Frage:
Kann man nun mit PHP lediglich 10mb per POST Befehl uploaden oder doch mehr? Ich habe bei Strato angerufen und ein Techniker hat mir am Telefon gesagt, dass ich mit PHP eh nur max. 10mb hoch laden kann, von daher wäre es auch egal wie hoch ich die Werte in der php.ini mache...mittels PHP und POST wären mehr als 10mb einfach nicht drin. Wenn ich mehr hoch laden wollen würde, dann müsste ich das mittels FTP machen, was man in ein PHP Script einbinden und ansprechen kann. Rapidshare und all die anderen Hoster würden das genau so machen und mit dieser Methode könne man so viel Mb oder Gb hoch laden, wie man lustig ist. Auf der anderen Seite lese ich aber dann immer wieder in Foren, dass mit einem über PHP angesprochenen FTP Zugang die Daten nicht vom lokalen Rechner an den Server übertragen werden, sondern vom Server zum Server. Mit anderen Worten, die Daten werden erst per POST Befehl an den Server übermittelt und erst DANN per FTP an den Bestimmungsort geladen. Wenn ich mit POST aber doch max. 10mb hoch laden kann...was bringt dann die ganze FTP Geschichte? Desweiteren lese ich immer wieder in Foren dass man "einfach" die php.ini anpassen soll, indem man die entsprechenden Werte bei Befehlen wie max_filesize etc. pp. abändert und erhöht. Das ist ja alles schön ung gut. Hab ich auch schon versucht. Zum einen gibt's bei Strato aber ja das bereits diskutierte FAQ. Zum anderen: Was bringt es denn die dortigen Werte anzupassen, wenn man mit dem POST Befehl und PHP doch eh nur 10Mb übermitteln kann??? Ich weiß so langsam nicht mehr wo vorn und hinten ist, ob ich Männchen oder Weibchen bin. Ich scheine mich nur noch im Kreis zu drehen...furchtbar. |
Ouh also zuerstmal, hats den geklappt mit dem code grundsätzlich? (unabhängig von der Filesize)
ansonsten: Was du erzählt bekommen hast und gelesen hast scheint für meine verständnisse alles richtig zu sein. So wie ich das verstehe, ist das was du vorhast ja ein php-ftp-client. Wenn ich mich recht erinnere läuft ein upload über php immer als http-upload, das heisst dieser hängt unter anderem von der in der php-ini eingestellten max-filesize ab.Zusätzlich kommen dann noch die unterschiedlichen Browser dazu welche die einstellung mal akzeptieren mal nicht usw und so fort... da gibts dann folgendes Formularelement, welches man vor das uploadfeld packen muss: Code:
<input type="hidden" name="MAX_FILE_SIZE" value="100000000" /> Ob die Einstellung gruundsätzlich größer als 10mb sein kann weiss ich nicht mehr genau, hängt aber wohl teilweise dann auch von den grundeinstellungen des apache/oder dergleichen ab. da kommts auf nen Versuch an denke ich. in der PHP-ini müssten jedenfalls folgende sachen geändert werden, sofern du da rankommst: upload_max_filesize größer als 10M. post_max_size mindestens 40% größer als upload_max_filesize. (hat was mit alten user agents und allem möglichen kram zu tun den Formulare noch mitschicken.) max_input_time mindestens 900 (15 minuten). (Zeit bis zum Timeout, bei großen Uploads dauerts ja schonmal länger, je nach upload) am besten mit den möglichkeiten einfach mal n try-and-error starten :) Irgendwie muss es auf jeden Fall funktionieren, denn bei uploadseiten kann man per http-upload ja auch teilweise bis zu 100mb hochladen!?!?!? oder täusche ich mich da.. |
Deinen Code habe ich noch nicht ausprobiert, tut mir Leid. Ich möchte, bevor ich jetzt irgendwas anderes versuche, grundsätzlich diese Frage beantwortet wissen. Denn wenn ich weiß dass ich's nicht versuchen brauche weil's nicht geht, dann wäre das vegebene Liebesmüh ;)
Was ich mich auch frage: Wie machen's denn Rapidshare & Co. bei denen man mehrere Gb hoch laden kann? Hier mal ein Auszug aus einer Strato-Mail: Zitat:
Achso und brehn... in meinem Formular ist ein Hidden Field mit einer value von 100Mb enthalten ;) |
achso hehe, da hab ich wohl nicht genau genug hingeschaut ;)
Aber zum Thema: Wenn Strato das so festsetzt kann man da denk ich nix machen.. ich denke auch bei anderen Providern wirds bei normalem Webspace ähnlich aussehen. Rootserver wäre ne Alternative und vielleicht garnicht soo teuer, müssen ja keine zig Gameserver + ts etc. drauf laufen sondern "nur" ein Webserver. Da muss man da zwar alles selbst installieren einrichten usw, aber dafür kann man dann auch selbst bestimmen, wobei es auch bei rootservern beschränkungen geben kann was bestimmte Einstellungen angeht. Frage ist, lohnt sich der ganze Aufwand bloss für größeren http-upload...wobei ich mir auch vorstellen kann, dass auf normalen webspace/rootservern solche dateigrößen wie bei rapidshare etc. überhaupt nicht möglich ist... Rapidshare und Co haben halt ihre eigenen Serverfarmen, also niemand der beschränkungen auferlegt. rein technisch scheints ja möglich zu sein. Warum Strato und Co das nu so beschränken, da hab ich allerdings auch keine Ahnung, hat bestimmt mit irgendwelchen Sicherheits- oder Leistungsaspekten zu tun... kann ja mal unseren IT-Fritzen in der Firma fragen :) es sei denn hier hat noch jemand wirkliche Ahnung und nicht solches Halbwissen wie ich :) |
Also, inzwischen habe ich die traurige Gewissheit: Mit einem Strato Hosting Server, wie ich ihn habe, werde ich die 10mb Grenze nicht überschreiten oder umgehen können. Dies ist wohl nur mit einem root-Server möglich. Solche werden zwar von Strato auch angeboten, doch ist es mir weder das Geld noch den Aufwand wert. Wie bereits erwähnt sollte das Upload-Script ja eh nur für die (wenn überhaupt) wenigen Bewerber dienen, die sich melden werden und dann wieder verschwinden.
Ich danke aber allen, die sich an dieser Diskussion beteiligt haben und mir versucht haben mit Rat und Tat zur Seite zu stehen oder mir zu helfen. Vielen Dank, auf euch ist echt Verlass! :ok: |
Alle Zeitangaben in WEZ +2. Es ist jetzt 13:57 Uhr. |
Powered by vBulletin® Version 3.8.7 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
©2005-2024 photoshop-cafe.de