post_max_size

post_max_size is de PHP-instelling die de totale grootte van ontvangen POST-gegevens begrenst. Deze grens is relevant bij formulieren en uploads. Je onderzoekt de aanvraag als geheel, niet alleen het grootste bestand dat je selecteert.

Laat bij een mislukte inzending vaststellen welke gegevens de toepassing ontvangt en waar de aanvraag wordt tegengehouden. Alleen naar de grootte van één bijlage kijken kan een onvolledig beeld geven.

Wat wordt hier begrensd?

De PHP-configuratiehandleiding beschrijft post_max_size als de maximale omvang van POST-gegevens. Uploads vallen daar ook onder. De grens voor een afzonderlijk bestand, upload_max_filesizeupload_max_filesize is de PHP-instelling die de maximale grootte van één geüpload bestand begrenst., heeft dus een ander bereik.

Vraag je beheerder om die twee instellingen samen te beoordelen wanneer een formulier bestanden verstuurt. De PHP-handleiding noemt ook dat memory_limitmemory_limit is de instelling die bepaalt hoeveel werkgeheugen één taak van je website krijgt voordat die stopt met een foutmelding. doorgaans groter hoort te zijn dan post_max_size; laat beide samen beoordelen.

Denk bij de diagnose vanuit het formulier. Welke velden vul je in en welke bestanden voeg je toe? Beschrijf de volledige inzending die je probeert te doen.

Een test met alleen een klein bestand is geen gelijkwaardige vervanging voor een formulier met meerdere bijlagen en ingevulde tekstvelden.

Waarom lijkt een inzending soms leeg?

Volgens de PHP-handleiding zijn de gebruikelijke verzamelingen $_POST en $_FILES leeg wanneer de POST-inhoud groter is dan post_max_size. Dat geeft een concrete onderzoeksvraag voor een ontwikkelaar. Een formulier dat lege gegevens meldt bewijst echter niet op zichzelf dat deze grens is overschreden.

Laat de fout aan de effectieve instelling toetsen.

Vraag welke informatie het onderzoek ondersteunt. Je hebt geen volledige inhoud van een klantformulier nodig in een openbaar ticket. Het tijdstip, de route, de totale testopzet en de foutmelding zijn een bruikbaar begin.

Laat de ontwikkelaar de technische waarneming toelichten zonder gevoelige veldwaarden in de overdracht te kopiëren.

Bewaar ook wat je aan de voorkant ziet. Verschijnt er een foutmelding, blijft het formulier staan of zie je een bevestiging zonder resultaat? Dat zijn verschillende observaties.

Schrijf je eigen waarneming op voordat je er een oorzaak aan verbindt. Daarmee blijft het onderzoek open voor een andere beperking in de aanvraagroute.

Waar controleer je de ingestelde waarde?

De beheerder moet de effectieve waarde voor het betreffende domeinEen domeinnaam is het webadres waarmee bezoekers jouw website vinden, zoals jouwbedrijf.example. controleren. De naam php.iniphp.ini is het instellingenbestand van PHP, waarin staat hoeveel ruimte en tijd je website krijgt en of foutmeldingen op het scherm verschijnen. alleen zegt niet welke configuratie jouw aanvraag gebruikt. Vraag waar de waarde wordt ingesteld en hoe is vastgesteld dat die configuratie geldt voor het formulier.

Laat een terminalcontrole niet stilzwijgend als bewijs voor de website dienen.

De hostergidsen helpen bij het vinden van het juiste beheerpad. Laat de uitvoerder vastleggen welke omgeving wordt gewijzigd. Als je een testkopie gebruikt, vraag dan welke relevante instellingen overeenkomen met de live website.

Een testresultaat is pas bruikbaar voor de overdracht wanneer de geteste omgeving duidelijk is.

Hoe bereid je een wijziging voor?

Beschrijf eerst welke inzending moet worden ondersteund. Geef aan welke bestanden en velden daarbij horen. Vraag om een passende grens met een uitleg van de afweging.

Kopieer geen hoge waarde uit een willekeurige handleiding zonder dat iemand heeft beoordeeld waarom jouw formulier die ruimte nodig heeft.

Laat de oude en nieuwe waarde bij de onderhoudstaak bewaren. Spreek af wie de wijziging beoordeelt en hoe de oorspronkelijke instelling wordt hersteld als de gekozen aanpassing niet helpt. Daarmee maak je van een los hostingexperiment een gerichte wijziging met een resultaat dat je zelf kunt controleren.

Voer de test uit met fictieve formuliergegevens. Controleer niet alleen de bevestigingsmelding, maar ook of alle verwachte velden en bijlagen aanwezig zijn op de bestemming. Kies die bestemming vooraf: bijvoorbeeld het beheerscherm waar de inzending hoort te staan.

Vermijd een test die onbedoeld echte ontvangers benadert.

Wat doe je bij een blijvende fout?

Vraag om de relevante regel uit het foutlogEen foutlog is een bestand waarin de server opschrijft welke fouten er op je website zijn voorgekomen, met tijd en plek. als die beschikbaar is. Vergelijk het tijdstip met je test. Een oude melding uit hetzelfde bestand kan bij een andere aanvraag horen.

In de Error Hub vind je uitleg bij herkenbare fouten; gebruik die uitleg als context bij de concrete waarneming.

Laat de beheerder aangeven welke hypothese nu is uitgesloten. Als de aanvraag binnen de gecontroleerde grens blijft, is verder verhogen zonder aanvullende aanwijzing geen gerichte vervolgstap. Vraag welk onderdeel vervolgens onderzocht moet worden en welk resultaat dat onderzoek moet opleveren.

Laat in de overdracht duidelijk staan welke combinatie van velden en bijlagen daadwerkelijk met succes is gecontroleerd.

Vraag hulp met de formulierroute, testopzet en vastgestelde instellingen. Staat ook een versieaanpassing gepland, neem deze volledige formuliertest mee bij PHP updaten. Dezelfde invoer vóór en na het onderhoud maakt het resultaat beter vergelijkbaar.