Download Manager Remote FTP - WordPress Plugin

Download Manager Remote FTP Setup Guide for Remote Files

Download Manager Remote FTP is best understood not as another way to upload an archive to WordPress, but as a connection between a file directory on a separate server and download packages in WordPress Download Manager. This guide covers the full workflow: preparing separate file storage, connecting over FTP or SFTP, limiting which folders editors can browse, attaching a remote file to a package, and confirming that visitors receive the intended file.

The add-on is designed to save editors from repeatedly uploading large installers, archives, manuals, and media files to the site's media library. Visitors still use the familiar download page and the package's access rules, while editors select files through a dedicated remote server browser. This is especially useful when a separate team already manages the directory or the files are stored on a server with more disk space.

This guide does not cover purchasing the add-on, obtaining a license, or gaining access to someone else's server. Instead, it shows how to configure an add-on you already have, from checking its dependencies and testing the connection to working with multiple servers and diagnosing DNS, directory path, and transfer mode issues. It also explains the solution's limits: remote storage does not remove WordPress from the delivery path or replace a carefully planned file access policy.

What the Remote File Browser Does

A standard WordPress Download Manager package stores its attached file on the site's server or points to an external URL. Download Manager Remote FTP adds a third option: an editor connects from the admin area to a separate FTP or SFTP server, browses the permitted folder tree, and attaches selected files to a package. The files stay where the file management team stores them instead of being copied to a standard WordPress directory first.

The practical value of this approach has little to do with FTP itself. It comes from separating responsibilities. The WordPress server handles the package page, description, access rules, locks, and the familiar download flow. The remote server stores the original files. Editors do not need to download a multi-gigabyte image to a laptop and upload it to the site's host just to add it to the catalog. If a file is updated in remote storage, do not assume that every package detail will change automatically. Check the package title, description, order, and information shown in WordPress as separate parts of the publishing process.

From File Selection to Visitor Download

The add-on follows a clear sequence. An administrator enters the connection settings and clicks Test Connection. Once the test succeeds, the file attachment area in a package offers the Browse FTP / SFTP command. The browser opens the folder tree permitted by the settings, displays files in a list or grid, lets the editor select multiple files, and provides the Attach Selected command. Attached files appear in the package's file list with the internal prefix ftp:.

When a visitor requests the package, the add-on retrieves the selected file from the remote server and streams it to the visitor on demand. That is why testing the selection screen alone is not enough. A successful Test Connection confirms that the admin area can reach the host with the supplied credentials. It does not prove that a large file will be delivered quickly, finish without a timeout, or follow the package's access rules as the site owner expects.

Who Benefits Most from This Approach

A natural fit is a technical documentation library, release archive, private partner library, or collection of large files already hosted on a separate server. The content team publishes package pages in WordPress, while the infrastructure team maintains the directory and backups on a file server. Each team keeps its own workflow, and visitors never see the storage system's internal folder structure.

Another good fit is a site with multiple independent file sources. For example, public brochures might be on one host while materials for registered users are on another. The option to set separate credentials at the package level is useful here. It avoids having to switch shared settings before each publication and reduces the chance of attaching a file from the wrong environment. Use the global configuration as the default connection, and reserve package-specific credentials for exceptions with a clear reason.

A third use case is a gradual migration. A company may already have an internal FTP directory where build systems or employees place files. Instead of repackaging the entire library by hand, you can create a few test packages, verify delivery, and then move frequently used items to remote attachments over time. This is not automatic directory synchronization or a way to import an arbitrary site structure. It is a controlled way to attach selected files to specific packages.

When to Choose a Different Solution

Do not treat this add-on as a universal storage solution for every kind of content. If you need global delivery through geographically distributed servers, predictable traffic scaling, direct signed URLs, or object lifecycle management, consider object storage and a compatible WordPress Download Manager add-on. If your team works primarily in Google Drive, OneDrive, or Dropbox and needs collaborative document editing, a cloud file browser with provider authentication may feel more familiar than an SFTP account.

If you only need to host small public PDFs, uploading them to WordPress or using a reliable direct URL is often easier to maintain. Another limitation is visitor access to the file browser. Remote FTP is intended for administrators selecting files, not for giving visitors access to your FTP account's control panel. Configure visitor access through the WordPress Download Manager package itself; do not turn the attachment interface into a public file manager.

A practical rule of thumb: Remote FTP makes sense when you need to keep source files on a managed FTP/SFTP server while publishing and controlling downloads through WordPress Download Manager packages. If a regular link is enough or you need a full cloud storage setup, do not add complexity just to use the add-on.

Before You Start: What to Check Before Installation and Connection

Failed first attempts often have less to do with the WordPress interface than with setting up a connection before deciding who is responsible for what. Before installing the add-on, write down five details: the server address, the protocol, the port, a dedicated account for delivery, and the root directory in which editors are allowed to select files. This information will help with the initial test and make it easier to hand the setup over to another administrator.

Dependencies and Access

The add-on requires WordPress Download Manager Pro and a supported PHP version. Standard FTP also requires the FTP extension to be enabled on the WordPress server. SFTP support uses a library bundled with the add-on, so a separate SFTP library installation in WordPress is generally not needed. Still, check the system setup: the WordPress host needs a network route to the remote host, and the remote server must allow the selected protocol and user.

Do not rely only on old forum answers or instructions showing outdated screens. Earlier versions of the add-on had different features, including import tools. The current release centers on an FTP/SFTP browser, connection testing, encrypted credentials, and package-level attachments. Before migrating, do not look for an old automatic import field as a required step. First confirm that your installed version includes the current FTP / SFTP and Browse FTP / SFTP options.

Anyone working in the admin area needs permission to edit packages. The add-on's browser checks user capabilities and uses WordPress nonces, but those safeguards do not replace proper role management. Do not grant broad administrator privileges to someone who only needs to create a package. Likewise, do not give that person the shared storage password if you can create a separate, restricted account instead.

Why Start with SFTP Instead of Familiar FTP?

FTP and SFTP are not two names for the same protocol. SFTP uses SSH File Transfer Protocol, while FTP uses a different transport and has its own transfer modes. The add-on supports both, but for a new connection, SFTP is usually the better place to start if the server offers it. This reduces the risk of sending credentials over an unprotected connection and makes it easier to explain the access policy to your security team.

Some environments only support FTP or require passive mode because of their network setup. If that is the case, do not guess at settings in WordPress. Ask the storage administrator for the exact protocol, host, port, outbound connection rules, and whether passive mode is required. Then create a separate test account with access to just one non-production folder. Testing against a sample directory is safer than starting with a production account that can see the entire archive.

The Root Directory Sets a Boundary, Not Just a Starting Folder

The root directory setting limits which areas the file browser can access. Treat it as both a technical and organizational boundary. If you set the root too high, editors may see archives, backups, intermediate builds, and internal files that should not be attached to packages. If you set it too deep, the releases they need may be inaccessible, prompting risky attempts to expand permissions.

A good setup has a separate publishing directory on the remote server, with subfolders organized by product or language, and an account that can access only that folder tree. WordPress uses that same directory as its root. Editors then see clear folder names and do not have to decide whether a system file is safe to attach. This also simplifies audits: if something unexpected appears in the browser, the issue is with permissions or the root directory, not an editor choosing the wrong item.

Quick Pre-Installation Checklist

• Check the parent plugin. WordPress Download Manager should be active, and the editor should be able to create and save a test package.
• Confirm the protocol. Record whether the server uses SFTP or FTP. Do not substitute one for the other just because a port number looks familiar.
• Create a restricted user. Read access to a dedicated directory is usually enough for publishing, if the server's policy supports it.
• Prepare two test files. Use one small file for a quick check and a noticeably larger one to test realistic streaming.
• Agree on the root directory. Record the path as it appears on the remote server and decide in advance which subfolders editors are allowed to see.
• Check network access. The WordPress host must allow outbound connections to the right host and port, and it must be able to resolve the server's DNS name.

This checklist can feel like busywork until the first incident. Then it becomes clear that a hostname typo, a protocol mismatch, and missing passive mode can all look the same in WordPress: the file cannot be selected. A little preparation lets you check likely causes in order instead of trying dozens of password and port combinations.

Installing the Add-on and Making a Safe First Connection

First install and activate WordPress Download Manager and the required Pro component in the configuration used on your site. Then install the Download Manager Remote FTP archive as a standard WordPress add-on from the Plugins area and activate it. Do not move straight to a production package after activation. Start with a draft package and a non-public test file.

This order helps for two reasons. First, a failed attachment will not disrupt an existing download page. Second, you can tell an installation issue from a remote server issue. If the FTP/SFTP tab does not appear after activation, check the plugin status and compatibility before looking at the remote server credentials. If the tab is available but the connection test fails, the add-on has loaded; the next checks should focus on the network, protocol, or access.

Create a Test Package

In the admin area, open Downloads → Add New and create a package with a clear title, such as Remote Archive Test. Do not make it available to all users. Add a short internal note so the team can recognize it as a test, then save it as a draft. This package becomes your baseline: if delivery stops working after a configuration change, you can use a known small file to test without affecting business materials.

A package has two layers. The first is its WordPress data: title, description, category, template, access rules, and publication status. The second is its attached files. Remote FTP changes the second layer, not the first. Configure access, password forms, roles, limits, and display through WordPress Download Manager just as you would for a local file. A remote source should not bypass the package's access rules.

The First Test Helps Pinpoint Problems

After entering the global credentials and testing the connection, open the test package, find Attach Files, and select Browse FTP / SFTP. You should see the restricted directory you prepared, not the root of the entire disk. Open the folder containing the small test document, select it, and click Attach Selected. Then save the package. The attachment list will show an entry with the ftp: prefix, giving editors a quick visual cue that the file is remote.

Do not confuse seeing a file in the browser with successful delivery. Open the package in a safe preview mode and request the download as a user with the right role. Record the outcome: filename, size, whether the archive or document opens, and any relevant log entries if your site uses them. Only after that check should you move an existing materials directory to Remote FTP.

FTP/SFTP Settings: From Credentials to Controlled Access

The main configuration screen is Downloads → Settings → FTP / SFTP. It is not a place to experiment with production settings. Before filling it out, understand what each field does in the delivery chain. Then, if something fails, you will know which part is unverified: the server address, transport, account, connection mode, or boundary of the file tree.

Protocol, Server, Port, and Credentials

Choose the protocol confirmed by the storage administrator: FTP or SFTP. Then enter the host, port, username, and password. Do not enter the website URL instead of the FTP/SFTP host, include a protocol in the host field if the form expects only a server name, or put the directory path in the port field. These mistakes may seem obvious, but they are common when copying one long line from an infrastructure team's email.

The add-on says that saved passwords are encrypted using WordPress Download Manager, but that is no reason to use an account with unrestricted permissions. Encryption helps keep the password from being stored as plain text in the settings. It does not address backups, administrator access, server compromise, or excessive privileges on the file host. Create a separate account for this integration and restrict it to the publishing directory.

After saving, click Test Connection. A successful response means the credentials passed a basic check. If it fails, do not change every field at once. First compare the protocol and port with the server administrator's information, then check the hostname, username, password, and outbound access. This order helps avoid assuming that the password is wrong when WordPress is actually trying to connect an FTP client to an SFTP service.

Active and Passive FTP: Enable Passive Mode Only When Needed

The passive mode toggle applies to FTP only. Use it when the network setup, firewall, or FTP server configuration requires data connections to use passive mode. Do not treat it as a general speed boost. It does not apply to SFTP in the same way, and the right FTP setting depends on the specific network.

Start with the setting agreed on by the server team. If the basic connection test succeeds but the folder browser or file listing does not work, record the symptom and ask the server administrator whether passive mode and a port range are required. After changing the setting, repeat the test with a small file, then a large one. Do not change modes on a production connection in the middle of a bulk publication. Test on the control package first; otherwise, you will not know which of several simultaneous changes affected the outcome.

Remote Directory Root and Boundary Check

Set Root Directory to the folder that should be the browser's top level. After saving, open the picker and check two things. First, can you see the subfolder with the test files? Second, can you also see a parent or internal folder that editors should not browse? The second check matters more: it confirms that the restriction actually enforces a boundary instead of simply setting a convenient starting location.

Choose a root directory name that will make sense to the person maintaining the site six months from now. Instead of one general files folder, agree on a structure such as publish/manuals and publish/releases on the storage server. You do not have to copy this example exactly. The important thing is that the path describes its purpose rather than reflecting an arbitrary location in an administrator's home directory.

Global Credentials and Package-Level Connections

Global settings work when all packages select files from the same trusted server. They reduce duplicate data and make the editors' workflow predictable. But when a second server is involved, do not rewrite the shared credentials before every package. In the package editor, expand Package Settings and use Use Custom FTP / SFTP Credentials for an exception that genuinely needs a different source.

A package-specific connection might be used for an isolated partner catalog or a separate project site. Add an internal note to the package or your team's procedures explaining why it uses a different source. Without that note, the next editor may replace it with the global settings, see a different folder list, and assume the add-on is broken. In a multi-server setup, the package name, the purpose of the remote directory, and the access rules should all tell the same story.

What Not to Put in Settings Fields

Do not put internal comments, temporary passwords, ticket numbers, or instructions for colleagues in the server name field. Settings fields should contain only the relevant value. Use an internal project log, secrets manager, or team document for explanatory notes. Do not put the remote storage path, username, or internal folder structure in a public package description. Visitors do not need that information, and exposing it makes the setup harder to maintain securely.

In short: Choose the agreed protocol, use a restricted technical account, set the smallest practical root directory, verify the connection, and test passive mode or credential changes with the control package.

Attaching Remote Files to Packages Without Confusion

Once the connection is configured, editors can return to the familiar package editor. Do not look for the remote file in the WordPress media library or paste an FTP client path into a random text field. Use Browse FTP / SFTP in the file attachment area. It opens the dedicated browser and saves the connection to the remote object in the package.

Selecting Files in the Package Editor

1. Open an existing package under Downloads or create a new one in Downloads → Add New.
2. Enter a clear title and description first so the filename is not the only clue to the package's contents.
3. Find Attach Files and select Browse FTP / SFTP.
4. Check the breadcrumbs and current folder so you do not mistake an old release for the current one.
5. Select the files using their checkboxes. Opening a folder does not attach its contents.
6. Click Attach Selected and return to the package's file list.
7. Save the package, then test the download from the public side using the appropriate user role.

The add-on's current browser supports list and grid views, breadcrumb navigation, and selecting multiple files. These conveniences do not replace good file naming. If a folder contains release-final.zip, release-final-new.zip, and release-final-new2.zip, the problem is not WordPress; it is an unmanaged directory. Use filenames that make the version, purpose, and status clear at a glance, but do not make visitors guess the storage system's internal structure from the public package title.

One File, Multiple Files, and Download Order

A WordPress Download Manager package can contain multiple files. In the parent plugin, attachment order affects how files are displayed and, in some configurations, what goes into a generated archive. After selecting files through FTP/SFTP, do not stop at seeing a green row in the list. Confirm that all expected files are attached, no test file is included, and the order makes sense for the package. Using a remote source does not change the need for this check.

If a user needs one large installer, it is usually clearer to give it its own package with an accurate description. A package can also group several related documents. Before publishing, find out how multiple files are handled in your specific installation: as one archive, separate buttons, or another layout. This matters for large files because combining several remote files into one output puts a different load on the server than delivering one ready-made file.

An Attachment Is Not a Copy

Remote FTP attaches a remote file to a package and streams it when requested. It does not move the file to a WordPress directory. If you delete or rename the file on the remote server, the package page may still be there, but delivery will fail. Changes to the file library should go through the same publishing process as changes to the package page: update the source, test it with a draft package, then verify the published version.

This matters especially when replacing a release. A safer approach is to upload the new file to the remote server under its final name, verify it using your team's usual checks, update the package attachment, and test delivery. Remove the previous version only after confirming the new path and agreeing on how long old versions should be kept. This avoids a gap in which WordPress points to an object that has already been deleted.

The Package Page Is Still the User-Facing Promise

Visitors do not need to know that a document comes from a remote server. They need a clear title, a description of the contents, compatibility information, file size if useful, access rules, and a clear outcome when they click the download button. Include the information that helps them choose the right material, but do not expose technical credentials. If the file is protected by a role or form, explain the requirement in plain language and test it with a separate account.

Do not use the filename as the package description. Names on remote servers often follow automation rules, while a download page needs clear editorial wording. There may be a relationship between build_8421.tar.gz and the public package name, but that relationship should be documented for the team rather than left for visitors to guess.

How the Connection Works: Settings, Package, Stream, and Verification

This sequence is what sets Download Manager Remote FTP apart from simply pasting in an external link. The administrator provides the credentials and root folder. An editor then selects a remote file in the add-on's browser. The WordPress Download Manager package stores a reference to that file alongside its own access rules. When a visitor is allowed to request the download, the add-on contacts the remote server and streams the file on demand.

Why This Is Different from a Direct URL

With a regular external URL, the parent plugin can send the visitor to the file's address. Remote FTP works differently: the add-on uses the connection credentials to retrieve the file from the remote server when a visitor requests it. This keeps the editor's selection process inside the browser and avoids publishing a direct URL to visitors or storing a copy of the file on the WordPress server.

That does not mean the main site is no longer involved in traffic. The file passes through WordPress's delivery logic and PHP, so performance depends on the hosting resources, execution time, network between the two servers, and number of simultaneous requests. This may barely matter for a small PDF. A large archive, especially one being downloaded by dozens of people at once, needs load testing and may call for a different storage or delivery solution.

What Determines What Visitors See

The visitor's experience depends on four things: the remote file exists and the permitted account can access it; Remote FTP can find it within the configured root; the WordPress package has the correct attachment; and the package's own rules allow the current visitor. A problem at any layer can lead to the same complaint, "I can't download it," but troubleshooting should proceed from the package and access status down to the remote file, not the other way around.

This approach also helps with support. If an employee says a download works for the author but not for a visitor, do not immediately ask them to change the SFTP password. First check whether a user with the same role can see the button, whether package locks apply, and whether the behavior changes in a private browser window. If access is confirmed but the stream stops, move on to the remote server and file size. This is faster than treating every layer as one long list of possible causes.

Credential Security and Content Protection Are Different

The add-on says that it stores passwords in encrypted form and protects admin requests with nonces and capability checks. These safeguards apply to connection management and file selection. Content protection also depends on the package rules, remote server settings, storage policy, and whether the file has been placed in a public folder outside the controlled delivery path.

So you cannot call a file protected just because it is on an SFTP server. SFTP protects the administrative connection in transit, but it does not replace package access rules. Likewise, a package password screen does not fix a technical account with excessive permissions or prevent the file team from manually publishing the same file in an open directory. Check connection security, editor permissions, visitor permissions, and storage policy separately.

Practical Example: A Documentation Library on a Separate SFTP Server

Imagine a department that publishes equipment manuals. The original PDFs and archives of related files are prepared on a documentation server. The WordPress site needs to display a catalog, restrict some materials to partner accounts, and avoid making editors move hundreds of megabytes through a browser every time. This example shows where Remote FTP helps and which parts still require the usual package setup.

Goal and Boundaries

The goal is to publish a package called "Maintenance Manual" with one PDF and one archive of examples stored on the SFTP server. A visitor with the right role should be able to view the package page and download both files under the configured access policy. Editors should not be able to access backups, internal logs, or draft versions of the documentation.

The team creates a separate publishing directory on the SFTP server, with subfolders by subject and language. The WordPress account can read only that publishing directory. It cannot delete files, rename them, or browse above that level. If the server platform supports restricting a user to a specific root, configure that on the server. Set the same directory as Root Directory in WordPress so the editor interface matches the actual permissions.

Step 1: Create and Test the Connection

The administrator opens Downloads → Settings → FTP / SFTP, selects SFTP, and enters the address, port, and credentials for the restricted account. The root directory points to the publishing folder. The administrator runs Test Connection before publishing anything. If the test fails, publishing stops until the host, port, and network access have been checked. Do not create a package with an unverified source.

After a successful response, test folder browsing in a test package. The two prepared files should be visible, but neighboring internal folders should not. This step is sometimes skipped because the connection test seems sufficient. In fact, it confirms a key part of the editor workflow: the user sees exactly the set of files they are allowed to choose from.

Step 2: Build the Package Page for Visitors

The editor creates a package under Downloads → Add New. The title describes the material, not its server path. The description says which model or process the manual covers, what is included in the attachments archive, and what access conditions apply. The category helps visitors find it in the catalog. If the site uses roles or locks, configure them in the package settings before attaching files.

Next, the editor opens Browse FTP / SFTP from Attach Files. They navigate within the permitted directory tree, select the PDF and archive, click Attach Selected, and return to the package. The file list should show both files with the ftp: prefix. If a local test file is still attached, remove it through the normal file list controls; do not try to delete the remote file from the server.

Step 3: Configure the Visitor Experience

Before publishing, decide what a successful download should look like. In this example, an authorized partner is signed in, sees the package page and a clear download button, and receives exactly two files. If the template combines them into one archive, test it with both files. If it displays separate files, make sure both names are clear and do not reveal internal labels. A public library may use a different access mechanism, but the principle is the same: access is controlled by the package, not by knowing the remote server address.

Do not tell visitors that "the file is on SFTP." That is a technical detail, not an instruction. It is more useful to describe what is included, the current internal version if needed, and any terms of use. The page should still make sense a year later, even if the source has moved to different managed storage.

Step 4: Verify the Download in Two Ways

First, check the package as an administrator. Confirm that it is saved, the ftp: entries are present, and the files can be downloaded. Then test it as an actual visitor. Use a separate test account with the same role or access level as a partner. Confirm that an unauthorized user is denied access, an authorized user sees the button, both downloads start and finish, the file sizes are correct, and both files open.

Do more than click the button. Open the downloaded PDF, extract the archive, and confirm that they contain the expected versions rather than older files with the same names. If the site tracks downloads, check whether this test matches your reporting policy. Agree on whether test downloads count as real events so diagnostics do not get mixed in with visitor activity.

Step 5: Update Materials Without Interrupting Downloads

Suppose the team prepares a corrected PDF. First, they put it in the permitted directory under a clear filename, verify its integrity using the team's internal tools, and notify the editor. The editor creates a draft package or a copy of the current one, attaches the new file through the Remote FTP browser, and runs both checks. Only after the checks pass do they update the production package. Keep the old file until the review period ends, if that fits the storage policy.

The risky order is the reverse: delete the old file from the remote server first, then hope to update the package attachment quickly. The live page will return an error in the meantime, and troubleshooting will happen under pressure. A good process keeps delivery uninterrupted and makes rollback simple: restore the previous package attachment if the new file fails verification.

Working with Multiple Servers Without Chaos

Package-level FTP/SFTP credentials in Package Settings are useful, but they can also introduce hidden complexity. If you enable them for every package without a plan, editors end up with dozens of subtly different connections, and the administrator loses track of which server is actually delivering each file. This feature is intended for clear exceptions to the default source, not for copying the same configuration repeatedly.

Consider three types of materials. The central manual library lives on the primary SFTP server and should use the global settings. A private partner catalog is hosted on another server because an external team maintains it. An archive of old releases is being moved temporarily during a migration. In this setup, only the second and third types need package-specific credentials. The first should keep using the shared connection; otherwise, changing the primary storage address would mean updating many package pages by hand.

Deciding When to Override the Global Settings

Before enabling Use Custom FTP / SFTP Credentials, ask three questions. Is there a genuinely different server or isolated directory? Does it require a different protocol, port, or technical account? Could the next administrator explain why without having to search through chat history? If any answer is unclear, keep the global settings. A separate connection should not be a workaround for a problem with the default one.

For each exception, make a short internal record: package ID or title, purpose of the server, account owner, permitted root directory, date of last verification, and replacement plan. This is not for publication and should not include the password. Its purpose is to explain why the package should not automatically inherit a future change to the global host.

Package Labels and Visible Clues

Do not add "Server A" or "SFTP" to a public title just for technical convenience. Visitors are choosing a file, not infrastructure. Instead, use a consistent internal process: a category, editor's note, or managed list of packages with a custom connection. If your project interface has no internal notes, keep a separate procedure alongside the publishing tasks.

When troubleshooting a package-specific override, compare it with the global configuration first. Confirm that you have the right package open, that the custom credentials option is enabled intentionally, and that its root points to the expected server. Then repeat the full sequence: Test Connection, browse the directory, and test delivery. Do not assume a package error is a site-wide error until you have checked whether the package uses a separate source.

Safely Moving to a Second Server

If a partner server changes its address or SFTP keys, do not update every published package at once. Create one control package with the new credentials and a small, safe file. Verify access for both the editor and an authorized visitor. Then update production packages in small groups, confirming each group as you go. This is especially important when the old and new storage systems will run in parallel for a while.

Parallel operation is a chance to test rollback, not a reason to keep two unclear versions forever. Decide in advance which package will stay on the old source until the review date, how you will mark the migration as complete, and who will disable the old technical account. After the move, check the new server's root directory: user permissions often change with the infrastructure, and the new browser may unexpectedly expose an extra folder level.

Common Mistakes in Multi-Server Setups

The first mistake is copying the global credentials into every package "just in case." That creates multiple independent password copies, and no one knows which ones are current. The second is using one powerful account for every source. It may save five minutes during setup, but a single compromised account exposes every directory. The third is failing to assign an owner to a server: an editor sees an error, while the infrastructure team does not know who is responsible for the files.

The fourth mistake is mixing test and production sources in one package. A package should point either to verified production files or remain a draft. Do not let its first file come from a test host and its second from production while presenting them to visitors as one set. If that combination is intentional, document why and verify each path separately.

Publishing Workflow: From a Server File to a Reliable Download Page

Remote FTP reliability depends not only on the settings but also on when a file is considered ready. If editors attach everything that appears in a folder, WordPress becomes an accidental showcase for intermediate builds. A short publishing workflow is more dependable because it accounts for the physical file, package, visitor permissions, and rollback plan.

Stage 1: The File Team Prepares the File

The file is uploaded or created on the remote server in a staging area. The owner checks that it opens, has the expected size and filename, and is not an older version under a new name. It is then moved or published to the directory WordPress is allowed to access. Follow the server team's approved process here. That might mean atomically renaming a completed file, using a separate release folder, or following another procedure already approved by the infrastructure team.

Remote FTP should not be used to upload files to the remote server. Its role is to browse, select, and attach a file that is already available. This keeps responsibilities clear: the build team owns the source, while site editors own the presentation and package access rules. When one task changes the storage contents, credentials, and public page at the same time, it is harder to verify and roll back safely.

Stage 2: The Editor Creates or Updates the Package

The editor starts with the package page. They check the title, description, category, access rules, visible template, and visitor context. Only then do they add a remote file through Browse FTP / SFTP. This order matters: instead of treating the file as the whole publication, the editor builds a clear experience for visitors and adds the file as verified package content.

When updating a live page, it is safer to use a draft or copy if your process allows it. That lets you test a new file without disrupting the existing page. Once verified, move the change into the published package according to your team's process. If you do not use copies, at least record the old attachment and the time of the change so you have a clear way to revert.

Stage 3: Check the Role, Browser, and File

Verify the publication at three levels. In the admin area, make sure the selected files appear in the package list and the changes are saved. In the remote server browser, confirm that you selected the intended path, not a similarly named file from a neighboring folder. On the public page, test the user role, button, downloaded file, and access restrictions. Each level answers a different question, and none replaces the other two.

If the material is confidential, use a test account with the same access level, not an administrator account. Administrators may bypass restrictions, making the package appear to work even when a regular partner cannot access it. A private browser window is useful for checking the signed-out state, but it does not replace a role test. Ideally, the team keeps two test accounts: one authorized and one that should be denied access.

Stage 4: Monitor After Publishing

You do not need to manually download every file every five minutes after publication. But for the first download from a new source, record that the test succeeded and watch for connection errors. If users report intermittent failures, note the time, file size, and steps they took instead of just writing "it doesn't work." These details help distinguish remote server instability from a package or access problem.

Regular reviews are especially important for libraries where files are replaced by an automated system. The system may change the contents under the same filename while WordPress continues to deliver the file successfully. If content integrity matters, require the file team to use unique filenames for new revisions and add a check before updating a package attachment. This is not an interface feature; it is a way to preserve visitor trust in published files.

Stage 5: Roll Back Without Panic

Plan the rollback before publishing. In a simple case, restore the previously verified file in the package. During a server migration, temporarily restore the old credentials for the affected package. If access permissions were changed by mistake, restore the previous package rule and test again as a regular user. Do not edit WordPress core files, the parent plugin, or the add-on to make an emergency rollback. That can destabilize the system and complicate future updates.

After rolling back, confirm what the visitor sees. A successful admin check is not enough. Download the file as an authorized user, open it, and only then close the incident. If the cause was infrastructure-related, keep the control package as a recovery check. It will help you verify future changes without touching the live library.

Verify the Setup: Access, File Integrity, and Performance

A connection test is useful, but it is only the first level. A full Remote FTP check should answer four separate questions: can an editor select the right file; is it attached to the right package; can an authorized visitor download it; and can the full process handle the actual file size and download time? If you skip any of these, the setup may appear to work until the first large release.

Check the Admin Area

Open the package and confirm that the expected files appear in the attachment list. Check the ftp: prefix, file order, and whether any outdated entries remain. Reopen the FTP/SFTP browser and make sure it starts in the expected root directory. Do not change the connection settings during this check. The goal is to verify the saved configuration, not create a new one.

If the package uses custom credentials, note that in your internal log and confirm that the exception is still needed. A difference between the global and package-level connections may be correct, but it should be explainable. Otherwise, during the next update, the team may test one server while actually delivering files from another.

Check What Visitors See

Open the package page in a private browser window or sign in with a test account. First, try without the required role; the protection should behave as expected. Then sign in with an authorized role, request the download, and save the file. Check the filename and size, open the document, or verify the archive's integrity. Do not hand this step off to another employee: the person who configured the package should see the exact visitor experience at least once.

If the page template displays a file list, check whether it shows an internal filename that could confuse visitors. If the package contains multiple files, make sure the differences between them are clear. If the access policy limits download counts, do not run dozens of tests with one account without coordinating first; otherwise, testing itself may create a false report that the limit has been reached.

Test Large Files and Download Time

Test with a typical large file as well as a small PDF. Watch for both the start and completion of the download. If it stops, record the time, file size, user role, and connection status. Then compare those details with your WordPress host's PHP settings and available resources. Large downloads can be affected by memory and execution-time limits, as well as streaming behavior. In a remote setup, the network between WordPress and the file server adds another factor.

Do not draw a confident conclusion about throughput from a single download at the office. Run at least several consecutive requests at a safe time, and coordinate with the infrastructure team before testing a critical library. If simultaneous large downloads become a bottleneck, do not blindly raise every PHP limit. First decide whether streaming through WordPress fits your workload or whether you need another delivery method.

Recheck After Infrastructure Changes

DNS changes, a remote server move, a PHP update, a technical account password change, firewall changes, or an update to the parent plugin are all reasons to repeat the control test. Keep it short but complete: Test Connection, browse the permitted folder, attach a test file, and download it as an authorized user. This takes less time than urgently troubleshooting a live catalog.

Maintenance and Safe Working Practices

Remote FTP works best as part of a predictable process, not as a one-time trick in the editor. Assign an owner for remote storage, an owner for WordPress packages, and a process for coordinating changes. One person may fill both roles on a small site, but the responsibilities still matter: who places the file, who attaches it to the package, and who verifies delivery?

Filenames, Versions, and Deletion

Use remote directory filenames that make the purpose and status clear without labels like final2 or new. A WordPress package can have a visitor-friendly title while the internal filename stays stable and useful for team procedures. When a new release is published, decide in advance whether old versions will stay alongside it, move to an archive, or be deleted after a rollback period. Do not leave that decision to an editor at the moment of publication.

Do not use the package's attachment removal button to manage the remote directory if your only goal is to unlink a file from the page. First confirm which item and action are selected. For important materials, treat the remote server as the source and manage deletions through a separate approved process; use WordPress to manage how those files are published.

Backup Access and Credential Rotation

Assign an owner to the integration credentials and set a review schedule. When the password changes, do not wait for a visitor to report a failure. First update the credentials in a test environment or through the control package, confirm the connection, and perform a visitor download. Then record who received the new credentials and where the secret is stored. Never put the password in a WordPress task description, package comment, or article text.

If access needs to be revoked, first pause future changes in WordPress, agree on what to do with active packages, and prepare a replacement source. Disabling the account immediately may be the right emergency response to an incident, but doing it without a plan during routine rotation can make downloads unavailable. A control package helps confirm that the new connection works before the old one is revoked.

A Small, Reversible Interface Adjustment

You do not need to add code to change Remote FTP itself, and you should not invent hooks that do not exist. However, in a local package page template, you can add a helpful label next to the file list if the template already outputs a container with the .wpdm-download-link class. This does not change the protocol, access, file, or add-on behavior. The snippet below is an author-created adaptation based on standard CSS practice. Use it only if this selector is present in the site's public markup.

/* Add this under the theme's Additional CSS settings.
   It changes only the visible hint next to the existing button. */
.wpdm-download-link::after {
  content: "Check access permissions before downloading";
  display: block;
  margin-top: 0.5rem;
  font-size: 0.9rem;
  color: #56616f;
}

Before adding it, open a package page and confirm that the selector applies to the intended link rather than every button on the site. After saving, check both a regular package and a restricted one. To roll back, remove this small CSS block. If the class is not present or the theme uses a different template, do not guess at a selector. It is better to skip a cosmetic change than disrupt the catalog display.

Troubleshooting Remote FTP: Symptoms, Checks, and Safe Fixes

Remote file problems are easier to solve when you check the connection, browser selection, package save, and actual delivery separately. The same visible symptom can have different causes. The table below gives you an order of checks that minimizes risky changes to production credentials.

Quick troubleshooting guide for a remote file source

Symptom	Likely area	What to check first	Safe next step
Test Connection fails	Host, port, protocol, credentials, or network	Compare the protocol and port with the server administrator's information	Check DNS and outbound connectivity, then test with a separate account
The browser opens but cannot see the needed folder	Root directory or user permissions	Compare Root Directory with the server-side boundary	Correct the root or storage permissions without granting access to the entire disk
A file is selected but does not appear in the package	Attachment step or package save	Check whether you clicked Attach Selected and whether the ftp: entry appears	Repeat the selection in a test package and save the page
The button appears, but visitors cannot get the file	Package access, file path, or streaming delivery	Check the test account's role and confirm that the remote file exists	Compare delivery of a small test file with a large one
The directory listing hangs or is incomplete	FTP mode, network, or large directory	Check passive mode for FTP only and the size of the selected folder	Confirm network requirements, narrow the root, and test in a small subfolder

Server Name Resolution Error

If a log or response contains an error such as php_network_getaddresses: getaddrinfo failed, the first thing to check is whether the hostname can be resolved. Do not start by changing the password. Compare the server name in the settings with the infrastructure team's information. Check for an extra protocol, space, path, subdomain typo, or outdated internal DNS name. Then ask the administrator to confirm that the hostname resolves from the network where the WordPress host is located.

After correcting the name, do not immediately return the production package to service. Confirm Test Connection, open the file list in the browser, and download a test file. If the hostname changed during a migration, add this check to the change procedure: DNS may already be updated for the office but still be unavailable from the site server.

The Connection Works, but the Needed Folder Is Inaccessible

This symptom usually means the root directory and permissions do not match. The remote server may accept the account but restrict it to a home directory or only allow access to part of the folder tree. First find the actual starting directory for that user, then compare it with Root Directory. Do not try to work around the problem with ../ paths or a shared server administrator account. That defeats the path restriction and could expose files that should not be published.

There are usually two fixes: adjust the root directory in the add-on settings or ask the storage administrator to grant the technical account read access to the required subfolder. After making the change, check both conditions: the target folder is accessible, and neighboring internal folders are not visible. If the second condition fails, the account has more access than it needs.

FTP Browsing or File Transfers Do Not Work

If the basic connection succeeds but the folder browser cannot get a listing or the download stops, check FTP mode separately. The add-on's passive mode setting is for networks where the server requires it. Record exactly what is failing: opening the listing, selecting a file, starting a download, or completing a large one. Then confirm the configuration with the FTP server administrator.

Run the check with one small directory and one small file. If changing passive mode fixes browsing, repeat the test with a larger file. If it does not, restore the previous value and check the network, firewall rules, and server settings. Do not leave the toggle at a random setting after a series of attempts. The project log should show one verified configuration.

The Package Points to a File That Is No Longer There

If a remote file was renamed, moved, or deleted, the package attachment remains as a reference to the old location and may lead nowhere. First find the current file on the remote server using the permitted browser. Then attach it to a draft copy of the package or a test page, save, and verify the download as a user. Do not edit the path directly in the database or modify the add-on's core files.

To prevent this from happening again, keep the publishing directory separate from the temporary build area. Only files that have passed internal checks and have stable names should go into the publishing directory. When replacing a file, add the new one first, verify it, and then remove the old one according to the storage policy. This makes the change reversible.

A Large File Starts Downloading but Stops

Do not assume that changing one PHP setting will fix this symptom. The delivery chain includes WordPress, PHP, the network to the remote server, the file server itself, and the visitor's browser. First confirm that a small file from the same directory downloads reliably. Then test with a large file and record where the transfer stops. Compare the host's time and memory limits with the transfer behavior, but remember that remote streaming also creates its own load.

If the issue occurs with several simultaneous requests, it is an architectural question about delivery. Do not promise visitors unlimited concurrent downloads before a coordinated load test. One safe option may be to keep Remote FTP for a controlled library while moving high-volume public downloads to storage and delivery designed for that traffic.

A Feature from an Old Guide Is Missing

Outdated Remote FTP descriptions may show import tools and elements from an earlier interface. The add-on has since been redesigned, and unfinished CSV and XML import features have been removed. If you cannot find a field, first reconsider what you are trying to accomplish rather than searching for its old name. The current workflow for attaching a remote file to a package uses the FTP/SFTP settings, a connection test, and the Browse FTP / SFTP browser.

Do not try to restore old features by installing random code snippets or replacing plugin files. That will complicate updates and does not guarantee compatibility with the current parent plugin. Describe the need separately: bulk package creation, directory synchronization, one-time attachment, or delivery of a large file. Each may call for a different supported tool.

Questions About Working with Remote Storage

Do I Need to Copy the File to the WordPress Server After Attaching It?

No. With Remote FTP, the editor selects a file on a remote FTP/SFTP server, and the add-on streams it when a visitor requests the download. But the original file must remain on the remote server for as long as the package points to it. Deleting the source file breaks delivery, even if the package page is still published.

Why Is SFTP Recommended if the Add-on Also Supports FTP?

SFTP is generally preferable for a new connection because it uses SSH File Transfer Protocol. Choose FTP when that is the transport supported by your infrastructure and the server administrator has confirmed the settings. In either case, use a separate technical account with minimal permissions and a restricted root directory, not a shared administrator account.

Does Every WordPress Download Manager Site Need Remote FTP?

No. It is useful when files already live on a separate FTP/SFTP host and need to be attached to packages without uploading them to WordPress again. For small local files, public direct links, or files in a cloud service, the parent plugin's standard method or a dedicated cloud add-on may be simpler.

Can I Configure Different Servers for Different Packages?

Yes. The add-on lets you override the global FTP/SFTP credentials for an individual package. Use this only when the setup calls for it, such as a separate project storage server, partner catalog, or isolated library. Record the exception so another editor does not mistake it for a configuration error.

Can Visitors Use the FTP/SFTP Browser?

No. The browser is for administrators selecting and attaching files. Visitors use the package page and WordPress Download Manager access rules. If visitors need to download the files, configure a role, lock, or other permitted access method on the package. Do not give them the remote storage credentials.

Why Does Test Connection Succeed When Downloads Do Not Work?

The test checks the basic connection to the server, not the entire visitor workflow. The root directory may be wrong, the file may have been removed or renamed, the attachment may not have been saved, package access may be misconfigured, or the file size, timeout, or network load may be causing a problem. Check in order: the file list, the ftp: entry, the visitor's role, a small file, and then a large file.

Will the Add-on Affect Site Speed?

The add-on's presence alone does not determine the answer. When a file is delivered, it passes through WordPress, so large files and simultaneous downloads depend on hosting resources and the network to the file server. That may be acceptable for a typical document library, but high-volume delivery needs real load testing and an architecture suited to the traffic.

What Should I Do If an Old Guide Recommends an Import Feature That Is Missing?

Use the current interface and focus on what you need to do. The current add-on uses the FTP/SFTP tab, a connection test, and the file browser; older import features were removed during the redesign. If you need bulk processing, define that need separately and choose a supported tool instead of trying to restore the old screen by editing plugin files.

When Download Manager Remote FTP Is a Good Fit

This add-on fits a WordPress project where files already live on a managed FTP/SFTP server and downloads should remain part of well-organized WPDM packages. Its strength is not the number of settings it offers, but the complete workflow: a restricted connection, file selection within the permitted directory, package attachment, streaming delivery, and verification from a visitor's perspective.

Start with one non-public package and two test files. Document the directory boundary, keep technical access separate from public access rules, and do not delete the old file before verifying its replacement. If this setup fits your workflow, you can get the WordPress version, test it with a package, and only then connect your production library.