Moving CV storage outside the web root
Step by step, how to point Vakanssi at a CV folder outside your public site, move the CVs you already have into it, and what Vakanssi checks, reports and deletes afterwards.
On this page(11)
By default Vakanssi keeps uploaded CVs in a protected vakanssi folder inside wp-content/uploads/. That folder is guarded and checked, but it still sits in the part of your site the web can reach. Moving it to a folder outside your public site adds one more layer: no web address can ever lead to a CV.
This page covers the whole move. For why the default exists, see Backups & data.
Vakanssi never moves your files for you
Changing the setting only changes where new CVs go. CVs you already have stay in the old folder until you move them yourself (step 4). Vakanssi keeps finding and deleting them there in the meantime, and warns you while any are left.
1. Choose a folder outside the public site
The path must be absolute: it starts with / on Linux and macOS servers, or with a drive letter such as C:\ on a Windows server. Vakanssi refuses a relative path such as private/cvs because it would be created next to wherever PHP happens to be running.
Pick a folder that is not inside your public web folder, often called public_html, htdocs or www. For example, if your site lives in /home/example/public_html, a good choice is /home/example/private/vakanssi.
2. Create the folder and check permissions
Create the folder, and make sure the user your web server runs as can write to it. Vakanssi creates the folder itself if it can. It then sets the folder to 0700 and each CV to 0600 when the server allows it, so other accounts on a shared server cannot list or read the files.
On a multisite network, Vakanssi adds a site-<id> folder for each site inside the path you choose, so one site’s CVs never mix with another’s.
3. Add the line to wp-config.php
Open wp-config.php and add this line above the comment that reads “That’s all, stop editing”:
define( 'VAKANSSI_STORAGE_DIR', '/absolute/path' );
Replace /absolute/path with your folder, for example /home/example/private/vakanssi.
If the path is not absolute, Vakanssi stops storing CVs and says why: Site Health shows a critical “Vakanssi cannot store candidate files” check, and an error notice on Vakanssi’s screens begins “Vakanssi: candidate files cannot be stored”. Applicants who try to attach a CV see “We couldn’t receive your CV right now. Please try again later.” Fix the path to resume.
While the location is invalid, Vakanssi also refuses to delete anything that has a CV. A privacy erasure request keeps the application and reports “Application #N was kept with its CV because the storage location for candidate files is not valid, so the CV could not be erased. Fix the storage location (see Tools, Site Health), then run this request again.”
The candidate record is kept so the request can be re-run, and WordPress’s Force erase personal data button on the request does that. Retention holds those applications until the path is fixed, and removing a single CV from an application is refused with a message to fix the storage location.
4. Move the CVs you already have
Until you move them, your existing CVs stay in the old folder. First find its exact path: Hiring, then Tools, then Status (and Tools, then Site Health) names the previous folder in the note that counts the CVs left in it. Copy that path.
On Linux and macOS, run the commands below in a shell. Set OLD to the path you copied and NEW to your new folder. On multisite, NEW is your custom path plus /site-<id> for that site, for example /home/example/private/vakanssi/site-2, and you repeat the move for each site.
OLD=/home/example/public_html/wp-content/uploads/vakanssi
NEW=/home/example/private/vakanssi
mkdir -p "$NEW" && chmod 700 "$NEW" && test -w "$NEW" \
&& find "$OLD" -maxdepth 1 -type f ! -name '.*' \
! -name index.php ! -name index.html \
! -name nginx.conf.txt ! -name vakanssi-probe.pdf \
-exec mv -n {} "$NEW"/ \; \
&& find "$NEW" -maxdepth 1 -type f ! -name '.*' \
! -name index.php ! -name index.html \
! -name nginx.conf.txt ! -name vakanssi-probe.pdf \
-exec chmod 600 {} +
The command creates the new folder if needed, stops if it cannot write there, and moves only the CV files. It skips the guard files Vakanssi keeps in each folder: .htaccess, .vakanssi-storage, index.php, index.html, nginx.conf.txt and vakanssi-probe.pdf. It never overwrites a file already in the new folder, and sets each CV there to owner-only (0600), since older files may be more open. The guard files keep their modes.
The command reports success even if a single move failed, and it silently skips a CV whose name already exists in the new folder, leaving it in the old one. Before you continue, run ls -A "$OLD" and confirm only the guard files are left, then check that the Status note counting CVs in the previous folder is gone (zero left).
Run it as the same user your web server runs as. If you run it as root, the moved files stay owned by root with 0600, so PHP cannot read them and downloads fail. In that case give them to the web server’s user afterwards, for example chown -R www-data: "$NEW" (the user name differs by host).
Do not move the guard files
The .vakanssi-storage marker is how Vakanssi recognises its own folder. Moving it, or copying a whole folder over, can leave the new folder unrecognised or the old one unguarded. Move only the CV files.
5. What Vakanssi reports until you finish
Vakanssi counts CVs left in the previous folder and tells you where they are:
- Hiring, then Tools, then Status shows a note such as “3 CVs are still in the previous folder … Move them into that folder when you can.”
- Tools, then Site Health shows “Some CVs are still in the previous storage folder” as a recommendation.
The count reads up to 1,000 entries per folder, so a very large folder shows a number followed by +. Downloads, erasure requests and retention all keep working for those CVs in the meantime.
Vakanssi remembers only one custom folder: the one you used just before the current one. Switching from a custom folder back to the default also records the custom one as the previous folder. If you change the constant a second time, the folder from before the last change is forgotten.
So move all CVs out of the previous folder before you change VAKANSSI_STORAGE_DIR again. CVs left in a forgotten folder cannot be found or deleted by Vakanssi, give no warning of their own, and show in Site Health as “Some stored CV files are missing”. The default uploads/vakanssi folder is always checked as a previous folder when it still holds your CVs.
The remembered folder is tied to the site’s host, port and path (not the http or https part). Moving the site from http to https keeps it. If the site’s address changes but VAKANSSI_STORAGE_DIR stays the same, Vakanssi still keeps it. It forgets the folder only when the address and the constant both change, and then it can no longer find or delete the CVs left there.
6. Confirm the new location works
Go to Hiring, then Tools, then Status. The Protected storage tile should read OK. If it does not, fix what the note beneath it says, then click Check storage again to re-run the check right away instead of waiting.
Then submit a test application with a CV and open that CV from the application. A CV that opens through the download link is stored where you expect.
7. Delete the old folder yourself
Once the old folder holds no CVs, delete it. Use the exact previous-folder path from the Status note, not a guess: on multisite the default folder sits deeper than uploads/vakanssi. Vakanssi does not remove it for you.
Vakanssi only ever deletes the CVs its database has a record of in an old folder. Any other file there, such as one left by a failed upload, is kept and reported as remaining by Reset data and by an uninstall purge. Check the folder before you delete it.
8. Include the new folder in backups
A backup that copies only your WordPress folder will miss a folder outside it. Add the new path to your backup, then restore a test copy once and open a CV from it. See Backups & data.
Staging copies and shared folders
Give every staging copy of your site its own uploads folder and its own CV folder. If a staging site’s uploads folder is a symlink to, or shared with, the live site’s, then deleting applications, erasing a candidate, retention, or an uninstall purge on staging can delete live CVs that the staging database has records of.
A staging copy on the same server that uses the same VAKANSSI_STORAGE_DIR value is just as risky: it shares the live site’s CV folder, and it also uses the live site’s previous folder and can delete the CVs it has records of there. Give staging its own CV folder and its own VAKANSSI_STORAGE_DIR value.
What an uninstall purge deletes
If you turned on Delete all data on uninstall, deleting the plugin removes the CV folder currently in use for that site. In the previous folders, it deletes only the CVs your files table names, and removes the folder itself only when nothing else is left in it. Reset data on Hiring, then Tools, then Data follows the same rules.
Files in a previous folder that Vakanssi has no record of are never deleted. They are counted as remaining so you can remove them by hand.
Related
- Firewalls & server compatibility for Nginx and managed hosts.
- Troubleshooting when Site Health says Vakanssi cannot store candidate files.
- Hooks reference for the
vakanssi/storage/base_dirfilter.