How to Fix OJS Upload Timeouts and Broken PDF Galleys
If you manage an academic journal on Open Journal Systems, you have probably seen at least one of these problems. An author emails you to say the manuscript upload stopped at ninety percent. A reviewer cannot open the PDF galley. A DOAJ or Crossref export ends with a blank page or a server error. Each time, you check the settings, clear the cache, and try again, and sometimes it works. Then the same problem returns the following week.
Most editors assume the problem is OJS itself, or something they configured wrongly. In reality, the cause is very often the hosting environment. OJS is a specialised publishing platform, and it needs a server that is set up with its demands in mind. This article explains why journals fail on standard hosting, what causes upload timeouts and broken PDF galleys, and what you can do to fix them.
Why OJS Is Not Like an Ordinary Website
A typical business website serves a few pages and some images. The server reads a file, sends it to the visitor, and the job is done. A journal built on OJS behaves very differently. It accepts large file uploads from authors, stores them in a protected directory, runs background tasks, generates PDF and XML files, talks to external services such as Crossref and ORCID, and serves heavy PDF downloads to readers around the world.
Commercial hosting companies design their default servers for the first kind of website. Their settings are tuned for low memory use, short execution times and small uploads, because that keeps costs down when thousands of accounts share one machine. Those defaults are perfectly reasonable for a blog or a small shop. They are a poor match for a journal that handles scholarly manuscripts.
This mismatch explains why the same errors keep coming back. You are not fixing a bug in OJS. You are working against limits that were never meant for a publishing system.
Why Manuscript Uploads Time Out
Upload timeouts are the most common complaint from journal editors, and they usually come from several limits working together. When one of them is too low, the upload fails, and the error message the author sees is often vague or misleading.
PHP Limits That Control Uploads
PHP, the language OJS runs on, has a set of configuration values that decide how large a file can be and how long the server will wait. The upload_max_filesize value sets the biggest single file that can be uploaded. The post_max_size value sets the total size of the request, and it must be equal to or larger than the upload limit. If an author submits a manuscript with figures, supplementary data and a cover letter, the combined request can easily exceed a small default such as 2 MB or 8 MB.
The max_execution_time and max_input_time values control how long PHP is allowed to work on a request. A slow connection, a large file or a busy server can push an upload past these limits, and the process is simply cut off. The memory_limit value matters as well, because OJS needs memory to handle files, generate thumbnails and process metadata. When memory runs out, the request ends with an error or a white screen.
Web Server and Proxy Limits
PHP is only one layer. The web server, any reverse proxy, and any content delivery network in front of your site can each impose their own size and time limits. A request can pass the PHP limits and still be rejected earlier in the chain. This is why editors sometimes raise the PHP values, test again, and see no change at all. Without access to the full server stack, it is hard to know which layer is responsible.
The Reality of Author Connections
Journal authors are spread across the world, and many upload from university networks or mobile connections that are slower than you might expect. A file that uploads in seconds on a fast office connection can take several minutes elsewhere. If the server timeout is short, those authors are the ones who suffer, and they are also the ones least likely to try again. Many will simply submit to another journal.
How to Fix OJS Upload Timeouts
The fix starts with setting the right values at every layer. For most journals, a sensible configuration raises upload_max_filesize and post_max_size to at least 64 MB, increases memory_limit to 256 MB or more, and extends max_execution_time and max_input_time to several minutes. These numbers are a starting point, and journals that accept large datasets or multimedia files may need more.
If you have a control panel, you can often change these values yourself through a PHP settings tool or a custom configuration file. On many shared plans, however, the host locks these values, and your changes are ignored. In that case you need to ask support to raise them, or move to a plan that lets you control them.
After making changes, test with a real manuscript rather than a tiny sample file. Upload a document close to the largest size you expect, and try it from a different network. Check the server error log as well, because it will often name the exact limit that was reached. If your host cannot show you the logs, that is a warning sign in itself.
Why PDF Galleys Break
A galley is the final version of an article that readers see, and for most journals it is a PDF. When galleys break, the damage is more public than a failed upload, because readers, indexers and search engines all run into the problem. A broken galley can mean a blank page, a download that never finishes, a corrupted file or an error message in the viewer.
File Permissions and Storage Paths
OJS keeps uploaded files in a files directory that should sit outside the public web folder. The server account must be able to read and write there, and the paths in the OJS configuration must match the real location on disk. After a server move, a restore from backup or a change of hosting plan, these paths and permissions often end up slightly wrong. The result is that the database says a file exists, but the server cannot open it.
Security Rules That Block Legitimate Files
Many hosts run web application firewalls and security modules that inspect every request. These tools protect against attacks, but they can also flag normal scholarly activity as suspicious. A request that downloads a PDF with an unusual filename, or an upload that contains certain patterns of text, may be blocked without any clear message. Editors then see random failures that seem impossible to reproduce. A host that understands OJS can adjust these rules for the journal. A generic host often cannot.
Memory, Caching and Large Files
Serving a large PDF through PHP uses memory and processing time, and a busy journal may serve many such files at once. On an overloaded server, downloads stall or fail partway through. Poor caching makes this worse, because the server repeats work it could have saved. During peak periods, such as after a new issue is published or when a paper is shared widely, the weakness becomes obvious.
How to Fix Broken PDF Galleys
Start by checking the basics. Confirm that the files directory path in your OJS configuration is correct, that it is outside the public web root, and that the server account can read and write to it. Open the file directly on the server, if you can, to see whether the PDF itself is intact. If the file is fine on disk but fails in the browser, the problem is in the delivery layer rather than the file.
Next, review the server error log at the exact time a galley fails. Entries that mention memory exhaustion, a blocked request or a permission denial will point you toward the cause. If the log mentions a security rule, ask your host to review it. If it mentions memory, raise the limit or move to a server with more resources.
Finally, consider how files are delivered. A well-tuned server with strong caching can serve repeated PDF downloads quickly and with little strain. This reduces failures for readers and also helps your journal’s visibility, since slow or broken downloads can frustrate both people and indexing crawlers.
Failed XML Exports and Scheduled Tasks
Upload and galley problems are the most visible, but standard hosting causes quieter failures as well. OJS relies on scheduled tasks to send reminder emails, process notifications and handle background work. These tasks run through a cron job or through the built-in automatic scheduler, and many shared hosts restrict cron access or run it unreliably. When scheduled tasks fail, reviewers do not receive reminders and editorial deadlines slip without anyone noticing.
XML exports are another weak point. Sending metadata to Crossref, DOAJ or other services means building large XML files and sometimes waiting on a response from an outside server. With low memory or short execution limits, the export can stop halfway and leave your DOI registration incomplete. If you have ever found that a batch of articles never reached Crossref, a hosting limit may be the reason.
The Hidden Cost of Shared Resource Limits
Cheap hosting is usually cheap because many accounts share the same server and the same pool of resources. Hosts enforce limits on processor time, memory, concurrent processes and sometimes the number of files. When your journal reaches one of these limits, the server slows down or returns an error, and you may not be told why.
Journals have uneven traffic. A quiet week can be followed by a sudden rush of submissions before a special issue deadline, or a surge of readers after an article gets attention. A plan that copes with average traffic can fail exactly when your journal most needs to perform well. That is the point at which authors are submitting and readers are arriving for the first time.
Signs That Your Host Is the Real Problem
It can be difficult to separate a hosting problem from an OJS problem, but some patterns give it away. If errors appear and disappear without any change on your side, the server is a likely cause. If problems get worse during busy periods, resource limits are probably involved. If your host tells you to reduce file sizes or ask authors to upload in smaller parts, they are asking you to work around their limits rather than solving the problem.
Other warning signs include support staff who do not know what OJS is, an inability to change PHP values, no access to error logs, no automatic backups and no clear path for upgrading OJS safely. A journal is a long-term academic record. It deserves infrastructure that is treated with the same seriousness.
What to Look for in Hosting for an OJS Journal
The right host for a journal begins with a server tuned for OJS, with generous PHP memory and execution limits, fast storage and good caching. It should support the current stable version of OJS and make upgrades manageable. It should provide free SSL, regular automatic backups, and reliable scheduled task support. Just as importantly, it should offer support from people who understand how journals work, not only how websites work.
It also helps if the host can assist with the wider publishing workflow. Migration from an old platform, DOI and metadata setup, and guidance on indexing requirements are all tasks where technical knowledge and scholarly knowledge overlap. When one provider understands both, problems get solved faster, because nobody has to explain what a galley or a submission queue is.
Final Thoughts
Upload timeouts and broken PDF galleys are rarely random. They are symptoms of a mismatch between a demanding publishing system and a hosting environment built for something simpler. By raising the right limits, checking file paths and permissions, reviewing security rules and making sure scheduled tasks run properly, you can remove many of these problems. When the host refuses to let you do any of this, the most effective fix is to move to a server that was built for OJS in the first place.
At Scholars Host, we run LiteSpeed hosting configured specifically for Open Journal Systems, and we handle migrations with zero data loss so your active submissions and review processes are not interrupted. If your journal keeps running into the problems described here, get in touch with our team and we will help you find the cause and put it right, so your authors can submit smoothly and your readers can always open your articles.