Two screens sit near each other in cPanel's Advanced section, both rarely used, both occasionally exactly what a problem needs. They do different jobs and are easy to confuse.
Apache Handlers: what the server does with a file
A handler maps a file extension to a way of processing it. The server knows .php should be executed. It does not know what you intend by .inc, so it sends the contents as plain text.
That is the symptom that points here: your source code appears in the browser window. The file is being served rather than run.
Adding a handler that maps the extension to the PHP handler fixes it. The screen takes the handler name and the extension, and writes the result into .htaccess.
The security rule for handlers
Never map an extension that users can upload to a script handler.
If .txt or .jpg is set to be processed as PHP, then any upload form that accepts those extensions (and almost every site has one) becomes a way to place executable code on your server. That is not a theoretical risk; it is one of the most reliably exploited misconfigurations there is.
The better answer to "my .inc files show as source" is usually to rename them to .php. It requires no server configuration and cannot be abused later by someone who does not know why the handler exists.
MIME types: what the browser is told it received
A MIME type is the label attached to a file when it is sent, and the browser decides what to do based on that label rather than on the extension.
Get it wrong and the file arrives intact and behaves incorrectly. The common cases:
A font that does not load while the file is plainly there and reachable. The browser was told it was something other than a font.
A video that will not play inline and downloads instead.
A PDF that downloads when you wanted it displayed, or displays when you wanted it downloaded.
The cPanel screen adds a type-to-extension mapping. Modern servers already know the common ones, so you only need this for genuinely unusual extensions, and if a standard type is being sent wrongly, the cause is more often an application setting overriding the server than a missing mapping.
How to tell which one you have
One command answers it:
curl -I https://example.com/path/to/file.ext
Look at Content-Type in the response. If it says text/plain or text/html for something that should be a font, a video or a PDF, it is a MIME type problem.
If instead your PHP source is visible in the page, it is a handler problem; the file was never processed.
Both are account-wide, and both write to .htaccess
Changes here apply to the account, including addon domains and subdomains that live under it. That is occasionally surprising when a handler added for one site changes behaviour on another.
Because both write into .htaccess, a mistake can produce a 500 across the site instead of a subtle misbehaviour. Take a copy of the file before using either screen: File Manager makes that a ten-second job, and it turns a broken site into a restored one.
When neither screen is the answer
If a page is downloading instead of rendering across the whole site, the cause is usually PHP not running at all, which is a different fault with a different fix. MultiPHP Manager deals with confirming the account has a working PHP version, and the error logs will usually name the real problem faster than either of these screens.
Find out what is actually being sent
Both settings affect one thing the visitor can see, which is the header on the response, and reading it removes the guesswork.
curl -sI https://example.com/file.json | grep -i content-type curl -sI https://example.com/font.woff2 | grep -i content-type curl -sI https://example.com/script.js | grep -i content-type
A file served as plain text when it should be something specific is the usual fault, and it produces a browser that downloads the file instead of using it.
Fonts and structured data are the two that appear most, because they are newer than many default configurations. A font served with the wrong type is refused by the browser and the page falls back silently to a different typeface.
Never map an executable type to a directory that accepts uploads
A handler tells the server to run a file rather than serve it, and that is a full compromise when it applies where visitors can place files.
grep -rn 'AddHandler\|AddType\|SetHandler' ~/public_html/.htaccess ~/public_html/*/.htaccess 2>/dev/null ls -la ~/public_html/wp-content/uploads/.htaccess 2>/dev/null
Read every rule of that kind on the account and confirm none of them applies to an upload directory. A handler added at the account root applies everywhere below it, including places nobody was thinking about when the rule was written.
The opposite protection is worth having explicitly: a rule in the upload directory that prevents anything being executed there, regardless of what is above it. That converts a file somebody managed to upload into a file rather than into a program.
Confirm which version a file actually runs under
A handler line changes which interpreter processes a file, and it overrides whatever the panel reports.
grep -rn 'AddHandler\|SetHandler' ~/public_html/.htaccess 2>/dev/null php -v | head -1 curl -s https://example.com/version.php
A single line placed years ago by a migration or a plugin can pin a directory to an old version, so the panel setting saves correctly and has no effect on that directory.
That is the explanation for the confusing state where two sites on one account run different versions and nobody configured it that way. Removing the stale line and setting the version properly is the fix, in that order.
Compression depends on the type being correct
Servers decide what to compress by the declared type, so a file served as the wrong type is either compressed when it should not be or not compressed when it should.
curl -sI -H 'Accept-Encoding: gzip' https://example.com/data.json | grep -iE 'content-encoding|content-type' curl -sI -H 'Accept-Encoding: gzip' https://example.com/font.woff2 | grep -iE 'content-encoding|content-type'
Structured data and vector images are text and compress substantially, and both are missing from older default configurations.
Fonts and images are already compressed and should show nothing. Compressing them again spends processor time for no reduction, which is the same mistake in the opposite direction. Compression and cache headers covers the settings.