Vakanssi: Careers Page, Hiring & Applicant Tracking

No. Uninstalling removes roles, capabilities, and plugin settings, but your hiring data is kept unless you explicitly enable Hiring → Settings → General → Delete all data on uninstall. While another copy of Vakanssi is still installed (for example in a second plugin folder), deleting a copy removes nothing, so the copy you keep runs with its settings and data.

Yes, with defence in depth. Candidate files are stored in a protected vakanssi folder in your uploads directory, under random 128-bit file names, with an Apache deny rule, index guards and a generated Nginx rule. Vakanssi then verifies over HTTP that the folder is not directly reachable, and shows an admin warning (with the exact Nginx rule to add) if it is. The plugin itself only serves CVs through an authenticated, permission-checked download link. To keep them outside your public site entirely, define VAKANSSI_STORAGE_DIR as an absolute path in wp-config.php; moving your existing CVs is covered at https://docs.vakanssi.com/admin/move-cv-storage/

Anyone you grant a hiring role to. Vakanssi ships three roles (Recruiter, Hiring Manager, and HR / Compliance) plus Administrator, and any user with the "view applications" capability can see every candidate and download every CV in the pipeline. In other words, Vakanssi does not restrict staff to only the jobs or candidates assigned to them: it assumes your hiring team is trusted, which is the right default for most small teams. Only grant these roles to people who should see all applicants.

Email security@vakanssi.com rather than posting in the support forum, so a fix can ship before the details are public. Please include the Vakanssi version, your WordPress and PHP versions, and steps to reproduce. You will get an acknowledgement within three business days and an initial assessment within a week, and you will be credited in the changelog for the release that fixes it unless you would rather not be. Only the most recent release receives security fixes, so updating is always part of the answer.

When you run Tools → Export Personal Data for a candidate's email, Vakanssi includes their profile (name, email, phone, location), every application (position, stage, status, date, and whether consent was given), the cover letter, their LinkedIn profile, each uploaded CV/attachment (the file itself, with its filename and upload date), the submission context stored with the application (the page the application was sent from), the recruiter notes and interview notes written about them, their interviews, and the emails Vakanssi sent them. Other details stored with an application or the candidate are included too, under "Additional application data". The export deliberately does not name the staff member who wrote a note, gave a rating, or conducted an interview. That is a third party's personal data, not the candidate's. The matching Erase Personal Data tool removes all of it, including the CV files on disk. Export and erasure share one list of the tables that hold notes, interviews and emails about a candidate, so the two stay in step.

Yes, activated per site or network-wide. Each site keeps its own jobs, candidates, CVs and settings (data is never shared between sites), and each site chooses independently whether deleting the plugin also deletes its hiring data. When Vakanssi is network-activated, deleting a site removes that site's Vakanssi data with it. There is no network-level configuration screen; settings are per site.

Yes. Nginx ignores .htaccess, so add the generated location block to your server config. The plugin's screens show the rule, and Site Health flags the folder, when it is reachable.

Yes, and you do not have to fall back to a shortcode. The block editor gets a Job Listings block. Elementor gets three native widgets (the listing, the application form, and the job details) grouped under a Vakanssi section in the panel, and they work with the free Elementor; if you run Elementor Pro, your Theme Builder archive and single templates for jobs are used instead of ours. Divi gets a Jobs module. Shortcodes ([vakanssi_jobs], [vakanssi_job_apply], [vakanssi_job_details]) still work anywhere else, including builders with no dedicated integration. Themes need nothing special. Block themes on WordPress 6.7 and later get editable "Jobs archive" (while the archive page is on) and "Single job" templates in the Site Editor, built from your own header and footer; classic themes get the built-in archive. The candidate-facing pages are styled so they survive a theme's own CSS reset, so the listing and the apply button look the same whichever theme you run.

Yes. Under Hiring → Settings → Jobs & Careers → Appearance you can turn off Vakanssi's front-end stylesheet entirely, if your theme styles the markup. For your own styling, use WordPress's built-in editor at Appearance → Customize → Additional CSS, which adds no extra request. Vakanssi keeps its own selectors deliberately low-weight and its class names stable. Match their weight, such as .vakanssi-apply-form .vakanssi-apply-button for the application form's Submit button or .vakanssi-apply .vakanssi-apply-button for a job's Apply link, and style :hover, :focus and :active as well, since Vakanssi sets those too. On most pages that is enough without !important. The same vakanssi- class names are on the careers and job pages under block themes and classic themes alike, so one rule covers both. On a block theme your theme keeps control of the page width and spacing and Vakanssi adds no styling of its own to those wrappers, so your rules apply exactly as you write them.

Two things are worth doing on a live hiring site, and both are standard WordPress production hygiene rather than Vakanssi requirements. First, switch WordPress to a real cron trigger: out of the box, WordPress runs scheduled tasks only when someone visits your site, so on a quiet careers site scheduled work can run late. Vakanssi relies on it to purge candidate data once its retention period is up. Add define( 'DISABLE_WP_CRON', true ); to wp-config.php and trigger wp-cron.php every few minutes; most managed hosts offer this as a checkbox. Second, if your host offers a persistent object cache (Redis or Memcached), enable it: Vakanssi uses transients for its dashboard counters, and an object cache keeps those out of the database under heavy traffic. Apply-form rate limits always use the database, so they hold either way. Nothing breaks without either step.

Yes: Hiring → Settings → Jobs & Careers → Job URLs → "Archive page". Single job pages stay live under your job URL base (e.g. /jobs/job-title/); the archive URL becomes available for your own page, such as a Careers page using the [vakanssi_jobs] shortcode.

Every save carries the state the screen was showing when you started editing. If someone else changed that candidate first, the save is refused and you are shown what changed instead of quietly losing one of the two edits. This runs over ordinary REST requests, so it needs nothing special on your server and works on any host that runs WordPress normally.

Yes. Vakanssi Pro is a separate plugin, coming soon, for teams that need more. Everything in this plugin stays free and fully working. Get notified when it launches at https://vakanssi.com/#notify