Versiunea DataLife Engine: 9.8
Tipul de licență al scriptului: Licența este activată [Nulled by Zagruzka-Plus]
Sistem de operare: Windows NT 6.1
Versiune PHP: 5.3.18
Versiunea MySQL: 5.5.28 MySQLi
Informații despre GD: GD Versiune: pachet (2.0.34 compatibil), FreeType Suport: Activat, FreeType Corelare: cu freetype, T1Lib Suport:, GIF Citește Suport pentru persoane cu handicap: Activat, GIF Creare Suport: Activat, JPEG Suport: Activat, Suport PNG : Activat, Suport WBMP: Activat, XPM Suport: pentru persoane cu handicap, XBM Suport: Enabled, JIS-mapate Suport fonturi japoneze: pentru persoane cu handicap,
Modul mod_rewrite: Activat
Modul sigur: dezactivat
Memorie alocată: 128M
Caracteristici dezactivate: Undefined
Dimensiune maximă de încărcare: 2 GB
Spațiu liber pe disc: 23,04 Gb
Încărcarea fișierului: videoplayback.mp4 a eșuat
Nu au fost selectate fișiere pentru descărcare.
cum o poți rezolva?
Verificați setările php hosting - poate că există o restricție acolo
1) Încercați php.ini doar pentru a schimba valoarea la mai mult.
2) Uită-te la ce drepturi sunt în dosarul de încărcare din rădăcina site-ului.
După cum rezultă din definiție, post_max_size limitează dimensiunea datelor transmise, astfel încât php rezervă un buffer de această dimensiune în memorie. Ce se întâmplă dacă cantitatea de date este mai mare decât această valoare (de exemplu, fișierul încărcat este mai mare decât era de așteptat)? Totul este foarte simplu - php resetează $ _POST și $ _FILES, ca în cazul în care încărcarea nu sa întâmplat, în timp ce jurnalele sunt după cum urmează:
PHP Avertisment: POST Content-Length de X octeți peste limita de octeți Y în Unknown on line 0 Acesta este același efect secundar. Într-adevăr, dacă numai o parte din datele POST se încadrează în tampon, scriptul php se poate comporta imprevizibil. Pentru a minimiza daunele - php nu va trece nimic în scenariul tău.
Dacă restricția este declanșată upload_max_filesize, putem învăța despre ea de matrice $ _FILES, elementul său corespunzător „eroare“ va conține UPLOAD_ERR_INI_SIZE cod de eroare. În cazul limitărilor de funcționare post_max_size, așa cum am descris, $ _FILES goale, iar sdetektirovat de eroare, iar utilizatorul trebuie să scrie. Din fericire, încă mai avem la dispoziție _GET $, prin urmare, rezolvată prin adăugarea GET-parametru în atributul action al formularului nostru:
Acum, în scriptul care acceptă formularul, putem verifica existența parametrului doing_upload și că $ _FILES este de fapt gol și este frumos să-i spunem utilizatorului că este greșit. Aproximativ astfel:dacă (isset ($ _GET ['doing_upload'])
($ _ FILES) || (numără ($ _ FILES) == 0)))
imprimare „Ne pare rău, post_max_size este în vigoare“ Dacă fișierul de injectare pe formular există orice domeniu, aveți posibilitatea să le piardă în cazul în care utilizatorul face o greșeală cu dimensiunea fișierului și, astfel, nu știe despre existența butonul Back (se întâmplă uneori) . Prin urmare, recomandăm ca formularul de încărcare a fișierului să fie expediat într-o iframe separată. Sfatul principal: dacă proiect este o formă de descărcarea de fișiere, încercați să depășească post_max_size și a vedea modul în care aplicația poate manipula.
Iată o altă întrebare: care este parametrul dvs. php.ini:
Dacă fișierul cântărește mult mai mult decât acest parametru, mi se pare că poate apărea o astfel de eroare.