Αύξηση του μέγιστου μεγέθους αρχείου μεταφόρτωσης στο WordPress

Τρεις ρυθμίσεις καθορίζουν το όριο μεταφόρτωσης στο WordPress, και πρέπει να συμφωνούν όλες μεταξύ τους. Το πραγματικό όριο είναι το μικρότερο ανάμεσα σε upload_max_filesize, post_max_size και το όριο αιτήματος του web server σου. Αν αυξήσεις μόνο το ένα και αφήσεις τα άλλα δύο χαμηλά, δεν αλλάζει τίποτα — και ακριβώς γι’ αυτό οι περισσότεροι καταλήγουν να πιστεύουν ότι η διόρθωση «δεν δούλεψε». Έλεγξε πρώτα τις τρέχουσες τιμές σου με το εργαλείο μέγιστου μεγέθους μεταφόρτωσης WordPress· διαβάζει τις ίδιες τιμές που αναφέρει το WordPress και σου δείχνει ποια από αυτές σε κρατάει πίσω.

Γιατί υπάρχει το όριο και πού βρίσκεται

Το WordPress δεν ορίζει το όριο μεταφόρτωσης. Απλώς το αναφέρει. Όταν βλέπεις το μήνυμα «The uploaded file exceeds the upload_max_filesize directive in php.ini», αυτό έρχεται κατευθείαν από την PHP.

Τρεις ξεχωριστές τιμές ελέγχουν μια μεταφόρτωση, και το πραγματικό ταβάνι είναι όποια από αυτές είναι η χαμηλότερη:

• upload_max_filesize (PHP) — το μεγαλύτερο μεμονωμένο αρχείο που δέχεται η PHP.
• post_max_size (PHP) — το μεγαλύτερο συνολικό σώμα POST. Το αρχείο σου ταξιδεύει μέσα στο αίτημα POST μαζί με άλλα πεδία φόρμας, οπότε αυτή η τιμή πρέπει να είναι μεγαλύτερη από το upload_max_filesize.
• Το όριο σώματος του web server — client_max_body_size στον Nginx ή LimitRequestBody στον Apache. Αυτό βρίσκεται εντελώς εκτός PHP, και γι’ αυτό οι διορθώσεις που αφορούν μόνο την PHP αποτυγχάνουν σιωπηλά πίσω από τον Nginx.

Μια τέταρτη τιμή, η max_execution_time, δεν περιορίζει το μέγεθος, αλλά θα διακόψει στη μέση μια αργή μεταφόρτωση μεγάλου αρχείου σε κακή σύνδεση. Είναι ξεχωριστό σύμπτωμα, όχι μέρος του ορίου μεγέθους.

Η παγίδα: ορίζεις upload_max_filesize = 256M, κάνεις επαναφόρτωση, και ακόμα δεν μπορείς να ανεβάσεις ένα αρχείο 100 MB — επειδή το post_max_size παραμένει στα 8M. Η PHP απορρίπτει το αίτημα με βάση το συνολικό σώμα προτού καν εξετάσει το αρχείο. Το όριο δεν σε αγνόησε. Ένα άλλο όριο το έπιασε πρώτο.

Πώς να το διορθώσεις, με τη σειρά

Ξεκίνα από τη λύση με τις περισσότερες πιθανότητες να «κρατήσει» και προχώρα προς την έσχατη λύση.

1. Επεξεργάσου το php.ini (το σωστό σημείο). Βρες το αρχείο που φορτώνει πραγματικά η σελίδα σου — τρέξε μια σελίδα με <?php phpinfo(); και διάβασε το «Loaded Configuration File», ή ρώτα τον πάροχό σου. Όρισε και τις δύο τιμές της PHP, και κράτα το post_max_size μεγαλύτερο από το upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Κάνε επανεκκίνηση του PHP-FPM (sudo systemctl restart php8.2-fpm) ή του Apache. Οι αλλαγές δεν κάνουν τίποτα μέχρι να επανεκκινήσει η διεργασία της PHP.

2. Δεν έχεις πρόσβαση στο php.ini; Χρησιμοποίησε το .htaccess (μόνο Apache + mod_php). Πρόσθεσε στο .htaccess στη ρίζα του WordPress σου:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Αυτό λειτουργεί μόνο όταν η PHP τρέχει ως module του Apache. Υπό PHP-FPM, CGI ή FastCGI, το php_value πετάει σφάλμα 500 — αυτή η αποτυχία σημαίνει ότι είσαι σε λάθος δρόμο, όχι ότι ο αριθμός είναι λάθος. Πέρνα στο .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Αύξησε το όριο του web server — το βήμα που όλοι ξεχνούν. Στον Nginx, η PHP δεν βλέπει καν ένα υπερμεγέθες αίτημα· ο Nginx επιστρέφει πρώτος 413 Request Entity Too Large. Στο server block σου:

client_max_body_size 256M;

Κάνε επαναφόρτωση με sudo nginx -t && sudo systemctl reload nginx. Αν είσαι σε Nginx και οι αλλαγές στην PHP «δεν έκαναν τίποτα», σχεδόν πάντα αυτός είναι ο λόγος.

Μετά από κάθε αλλαγή, ξαναέλεγξε τις αναφερόμενες τιμές. Το εργαλείο μέγιστου μεγέθους μεταφόρτωσης θα σου πει το νέο πραγματικό ταβάνι και θα δημιουργήσει το ακριβές snippet για τη δική σου διαμόρφωση, ώστε να μη μαντεύεις ποια από τις τρεις τιμές παραμένει χαμηλή.

Τι να μην κάνεις

Μην επεξεργάζεσαι το wp-config.php περιμένοντας ότι θα ανεβάσει το όριο. Η ευρέως αντιγραμμένη γραμμή δεν κάνει αυτό που ισχυρίζονται τα άρθρα:

@ini_set( 'upload_max_filesize' , '256M' );

Το upload_max_filesize είναι PHP_INI_PERDIR. Δεν μπορεί να αλλάξει από την PHP κατά την εκτέλεση με ini_set(). Δέχεται νέες τιμές μόνο από php.ini, .htaccess ή .user.ini — ποτέ από τον κώδικα της εφαρμογής. Η γραμμή εκτελείται χωρίς σφάλμα και δεν κάνει τίποτα, κάτι που την καθιστά μία από τις πιο σίγουρα επαναλαμβανόμενες λανθασμένες συμβουλές στο WordPress.

Μην επικολλάς ούτε το @ini_set('post_max_size', ...) — ίδιος περιορισμός, ίδια σιωπηλή αδράνεια.

Μην ορίζεις το WP_MEMORY_LIMIT νομίζοντας ότι είναι το όριο μεταφόρτωσης. Αυτό ελέγχει το ταβάνι μνήμης της PHP για την εκτέλεση κώδικα. Δεν έχει σχέση με το πόσο μεγάλο αρχείο δέχεται ο server.

Μη σταματάς σε ένα μόνο αρχείο. Η πιο συχνή αποτυχία είναι να αλλάξεις μόνο το upload_max_filesize και να δηλώσεις ότι η διόρθωση χάλασε. Άλλαξε και τις τρεις τιμές, και κράτα το post_max_size πάνω από το upload_max_filesize.

Μην ορίζεις παράλογα υψηλά όρια «για σιγουριά». Ένα όριο 2 GB προσκαλεί προβλήματα εξάντλησης πόρων και δεν βοηθάει — αν πραγματικά χρειάζεσαι αρχεία πολλών gigabyte, ανέβασέ τα εκτός browser (SFTP, ή κάποιο plugin τμηματικής μεταφόρτωσης) αντί να τα σπρώχνεις μέσα από ένα μεμονωμένο POST της PHP.

Ακόμα κολλημένος;

Αν και οι τρεις τιμές είναι αυξημένες και εξακολουθείς να χτυπάς σε τοίχο, το αίτημα περιορίζεται κάπου πιο πάνω από τον server σου: ένα CDN ή proxy (το dashboard του Cloudflare περιορίζει το μέγεθος σώματος μεταφόρτωσης από μόνο του), ένα όριο πλατφόρμας ενός managed παρόχου που αγνοεί το php.ini σου, ή ένα .user.ini που δεν έχει ανανεωθεί ακόμα — σέβεται το user_ini.cache_ttl της PHP, οπότε μπορεί να καθυστερήσει μερικά λεπτά αφότου το αποθηκεύσεις. Επιβεβαίωσε τι αναφέρει πραγματικά ο server, όχι τι έγραψες σε ένα αρχείο, και διόρθωσε το επίπεδο που παραμένει χαμηλό. Όταν ο αναφερόμενος αριθμός ταιριάξει επιτέλους με τον στόχο σου, η μεταφόρτωση δουλεύει.