WP All Import scheduled jobs with the uploads folder locked

WP All Import Scheduled Jobs With Uploads Locked

by

WP All Import scheduled jobs allow WordPress websites to download and process CSV, XML, Excel, Google Sheets, and product-feed data automatically. However, scheduled imports may stop working when a security plugin or server configuration locks the WordPress uploads directory.

The important question is what locked means.

If the lock only prevents visitors from browsing files directly, scheduled imports may continue working normally. If the lock makes wp-content/uploads read-only, WP All Import will probably fail or complete only part of the import.

This guide explains why WP All Import needs write access, which directories should remain writable, and how to protect the uploads folder without breaking scheduled jobs.

The Direct Answer

WP All Import scheduled jobs should not be expected to work reliably while the entire wp-content/uploads directory is read-only.

A scheduled import may need to:

  • Download a new CSV, XML, Excel, or feed file.
  • Create temporary files.
  • Update its working files.
  • Write import-history logs.
  • Download product or post images.
  • Create Media Library attachments.
  • Generate resized image versions.
  • Create a new year or month upload directory.

WP All Import’s manual cron system downloads the source file and then processes it across repeated requests until the import finishes. Therefore, successfully triggering the cron URL does not prove that the plugin can write the files required to complete the job.

What Does “Locked Uploads Folder” Mean?

There are several different ways an uploads folder can be described as locked. They do not all have the same effect.

Direct access or directory browsing is blocked

A security rule may prevent visitors from listing or directly accessing certain uploaded files.

This normally does not prevent WordPress or WP All Import from writing files on the server. The directory can remain writable while public access is restricted.

PHP execution is blocked

A server rule may prevent .php, .phtml, or similar executable files from running inside wp-content/uploads.

This is different from making the directory read-only. Images, documents, CSV files, logs, and import files can still be created while potentially dangerous PHP files cannot execute.

Filesystem write access is removed

A site-lock or server-permissions feature may make the folder read-only.

For example, Site Lockdown Security describes its Site Lock feature as making selected WordPress files and folders read-only. It recommends unlocking protected areas when legitimate maintenance or file changes are required.

This is the type of lock that can break WP All Import.

Why WP All Import Needs Access to wp-content/uploads

WP All Import does more than update WordPress database records. It also uses the filesystem during many imports.

WP All Import maintains its own upload area

WP All Import commonly uses a directory under:

/wp-content/uploads/wpallimport/

Depending on the import and plugin version, this area can contain directories such as:

/wp-content/uploads/wpallimport/files/
/wp-content/uploads/wpallimport/uploads/
/wp-content/uploads/wpallimport/logs/

WP All Import’s official documentation instructs users to place server-hosted import images in:

/wp-content/uploads/wpallimport/files/

The plugin then copies those images to the normal WordPress Media Library directory during the import.

WP All Import support also identifies its files, uploads, and logs directories as locations that can contain import source files, uploaded files, and import-history logs.

If the wpallimport directory cannot be written to, the plugin may be unable to save the latest feed, maintain a log, or prepare the import for processing.

Imported media uses the normal uploads directory

When WP All Import downloads an image from an external URL, it adds that image to the WordPress Media Library.

The final destination is normally similar to:

/wp-content/uploads/2026/07/

The actual directory depends on the site’s WordPress media settings and the date assigned to the imported attachment.

WordPress uses wp_upload_dir() to determine and, when necessary, create the destination directory. WordPress returns an error when the directory cannot be created because its parent is not writable.

Therefore, excluding only the wpallimport directory from a lock may not be sufficient when the import also downloads images or attachments.

Additional image processing may run later

WP All Import can defer the generation of image metadata and additional image sizes until after the main import. Those tasks are then processed through WordPress cron.

The main import may appear complete while thumbnails or other image sizes are still waiting to be generated. Those later operations also require write access to the Media Library directories.

Will a Database-Only Import Work While Uploads Is Locked?

It might, but it should not be assumed.

Consider an import that only updates:

  • Product prices
  • Product stock
  • Post titles
  • Custom fields
  • Taxonomies
  • Existing database records

The imported content itself may not require a new Media Library file. However, WP All Import may still need to download the current source feed or update files and logs inside its own wpallimport directory.

A database-only import can work when:

  1. The source file is available without needing to be replaced locally.
  2. WP All Import’s required working directories remain writable.
  3. Logging does not fail because of permissions.
  4. No image or attachment processing is enabled.
  5. No custom import function creates files.

If the entire wp-content/uploads directory and all of its subdirectories are read-only, even a database-only scheduled import is at risk of failing.

Will Imports With Images Work While Uploads Is Locked?

Usually not.

An import that creates or updates images may need to:

  1. Download the original image.
  2. Save it temporarily.
  3. copy it to the Media Library.
  4. Create an attachment record.
  5. Generate thumbnails.
  6. Generate theme or WooCommerce image sizes.
  7. Write image metadata.

Even if the import feed is processed successfully, the products or posts may be created without their images.

Common symptoms include:

  • Featured images are missing.
  • Product galleries remain empty.
  • Images use old versions.
  • The import history reports download failures.
  • WordPress displays “Unable to create directory.”
  • Only text and database values are updated.
  • The import remains stuck in processing.
  • The log contains “Permission denied” or “Failed to open stream.”

The Recommended Configuration

The best setup depends on whether the scheduled jobs import media.

For imports that do not create files or images

Keep the main security lock active, but exclude the following directory from read-only protection:

/wp-content/uploads/wpallimport/

Make sure the exclusion includes all directories underneath it.

Then run each import manually and confirm that:

  • The source file is refreshed.
  • The import finishes.
  • The history log is created.
  • No permission warning appears.
  • The same import succeeds through its scheduled cron job.

This configuration may be enough for price, stock, text, taxonomy, and custom-field updates that do not process media.

For imports that download images or attachments

The normal WordPress Media Library path must also remain writable.

The most reliable setup is:

  • Keep WordPress core, themes, and plugin files protected.
  • Keep wp-content/uploads writable by the correct server user.
  • Protect the uploads directory from PHP execution.
  • Monitor the uploads directory for unexpected executable files.
  • Keep WP All Import and its add-ons updated.
  • Restrict access to WP All Import to trusted administrators.

Trying to exclude only the current year and month directory can create a future problem. A July import might work with:

/wp-content/uploads/2026/07/

The same configuration may fail in August when WordPress tries to create:

/wp-content/uploads/2026/08/

For recurring imports with media, keeping the appropriate uploads path writable is usually safer than maintaining month-by-month exclusions.

Using Site Lockdown Security With WP All Import

When the lock is provided by Site Lockdown Security or another plugin that changes filesystem permissions, use its built-in exclusion controls rather than manually changing permissions behind the plugin’s back.

A practical configuration is:

WordPress root: Locked
wp-admin: Locked
wp-includes: Locked
wp-content/plugins: Locked
wp-content/themes: Locked
wp-content/uploads/wpallimport: Excluded and writable
wp-content/uploads: Writable when imports create media

Site Lockdown Security supports targeted exclusions and states that the site can be unlocked for legitimate updates or maintenance before the lock is applied again.

Do not assume a plugin automatically recognizes every directory required by WP All Import. Run a complete scheduled-import test after applying the lock.

A Safer Alternative to Making Uploads Read-Only

A WordPress uploads directory normally needs to accept legitimate files.

WordPress security documentation explains that files requiring write access must remain writable by the relevant server process. It also describes wp-content as user-supplied content that is intended to be writable by the site owner and, where required, the web server.

Instead of making the complete uploads directory permanently read-only, use multiple security layers.

Use appropriate file permissions

A common starting point is:

Directories: 755
Files: 644

These values are not correct for every hosting environment. File ownership and the user running PHP are equally important, so check with the hosting provider before changing permissions recursively.

Never use 777 as a general fix for a failed import.

WordPress documents 755 for directories and 644 for files as one possible permission scheme, while also explaining that server ownership and hosting configuration determine what needs to be writable.

Block PHP execution inside uploads

Uploaded images and import files generally do not need to execute as PHP.

For an Apache or LiteSpeed server that allows .htaccess overrides, a rule similar to the following can be placed in:

/wp-content/uploads/.htaccess
<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

Back up the existing .htaccess file and test the site after adding the rule.

For Nginx, the equivalent restriction must be added to the server configuration, normally before the general PHP-processing rule:

location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|phar)$ {
    deny all;
}

Nginx does not process .htaccess files. Ask the hosting provider or server administrator to implement and test the restriction when you do not manage the server configuration.

This approach lets WP All Import create legitimate CSV files, images, logs, and directories without allowing uploaded PHP scripts to run through the browser.

How to Test the Configuration Safely

Test on staging first when the scheduled imports affect WooCommerce products, prices, stock, or large amounts of content.

Step 1: Create a backup

Create a backup of:

  • The WordPress database
  • wp-content/uploads
  • WP All Import settings
  • Any custom import functions

Step 2: Run each import manually

Go to:

All Import > Manage Imports

Run each scheduled import manually.

Verify:

  • The source file downloads.
  • The expected records are created or updated.
  • Products retain correct prices and stock.
  • Images appear in the Media Library.
  • Featured images and galleries work.
  • The import reaches 100%.
  • The import history contains no permission errors.

WP All Import itself recommends testing an import manually before scheduling it.

Step 3: Apply the uploads lock or exclusions

Enable your security configuration and run the same import again.

Do not change the import settings between the unlocked and locked tests. This makes it easier to determine whether filesystem protection caused the failure.

Step 4: Test the real schedule

For manual scheduling, WP All Import uses:

  • A trigger URL that starts the import.
  • A processing URL that continues running the import until it finishes.

The processing URL is normally called repeatedly because a large import may require several requests.

Check both cron jobs. A successful HTTP response from the trigger URL does not guarantee that the processing requests completed the import.

Step 5: Review logs after the scheduled run

Look for:

Permission denied
Unable to create directory
Failed to open stream
Directory is not writable
Could not download file
Unable to save import file
Image download failed
Log file is not writable

Also compare the import’s last-run timestamp with the expected schedule.

Checking Write Access With WP-CLI

When WP-CLI is available, run the following from the WordPress installation directory:

wp eval '
$uploads = wp_upload_dir();

$paths = array(
    $uploads["basedir"],
    $uploads["basedir"] . "/wpallimport",
    $uploads["path"],
);

foreach ( $paths as $path ) {
    echo $path . " : ";
    echo is_writable( $path ) ? "WRITABLE" : "NOT WRITABLE";
    echo PHP_EOL;
}
'

An example result is:

/home/example/public_html/wp-content/uploads : WRITABLE
/home/example/public_html/wp-content/uploads/wpallimport : WRITABLE
/home/example/public_html/wp-content/uploads/2026/07 : WRITABLE

If the wpallimport directory does not yet exist, create or run an import before checking it.

The command only tests the current PHP process’s ability to write to those locations. A cron process using a different PHP user or execution method may behave differently.

What If the Import Runs Only While the Folder Is Unlocked?

That confirms the issue is related to filesystem access rather than the schedule itself.

Use one of these solutions:

  1. Exclude the required WP All Import directories from the lock.
  2. Leave uploads writable and block PHP execution instead.
  3. Unlock uploads before the scheduled import and relock it after completion.
  4. Ask the security-plugin developer to add a WP All Import compatibility exclusion.
  5. Ask the host to confirm ownership and permissions for cron-triggered PHP processes.

Unlocking and relocking manually is not suitable for unattended daily imports. A permanent, narrowly scoped exclusion is usually more reliable.

Avoid creating raw chmod cron jobs unless a server administrator has verified ownership, permission inheritance, and compatibility with the security plugin. Direct permission changes can conflict with the plugin’s stored lock state.

Frequently Asked Questions

Can I lock the uploads folder if WP All Import uses existing Media Library images?

Possibly, but WP All Import may still need write access for its source files, temporary data, and logs.

Using existing Media Library images reduces new media writes, but it does not guarantee that the entire import is filesystem-free.

Do scheduled imports use normal WordPress WP-Cron?

WP All Import supports manual server cron jobs and its optional Automatic Scheduling service. Manual scheduling uses separate trigger and processing requests rather than relying only on ordinary page-visit-driven WP-Cron.

Some related image-processing operations may still be deferred to WordPress cron.

Can the folder remain locked between imports?

Yes, provided it is unlocked before the job starts and remains writable until all processing and image-generation tasks finish.

This approach requires dependable automation. It is less reliable than maintaining carefully limited writable exclusions.

Is chmod 777 a valid solution?

No. It grants write permission far more broadly than normally required and can create a serious security risk.

Correct ownership and narrowly scoped write access should be fixed instead.

Why does the cron URL return success when nothing is imported?

The trigger request may have successfully started the job while later processing failed because the plugin could not create, download, or update a required file.

Always inspect the import history and confirm the expected records changed.

Final Recommendation

WP All Import scheduled jobs should not run with the entire uploads directory made permanently read-only unless every directory required by the import has been explicitly excluded.

For imports without media, keeping this path writable may be sufficient:

/wp-content/uploads/wpallimport/

For imports that create images or attachments, the applicable WordPress Media Library directories must also remain writable.

The best balance between reliability and security is generally to:

  • Protect WordPress core, plugin, and theme files.
  • Keep uploads writable only by the correct server user.
  • Use appropriate file ownership and permissions.
  • Block PHP execution inside uploads.
  • Keep WP All Import updated.
  • Monitor unexpected changes.
  • Test every import manually and through its real cron schedule.

This allows scheduled imports to complete without leaving the entire WordPress installation unnecessarily writable.

Leave a Comment