Title: Unifyca Audit Connector Author: unifyca Published: जून 26, 2026 Last modified: अक्टूबर 2, 2026 --- Search plugins ![](https://ps.w.org/unifyca-audit-connector/assets/banner-772x250.png?rev=3590387) ![](https://ps.w.org/unifyca-audit-connector/assets/icon-256x256.png?rev=3587073) # Unifyca Audit Connector By [unifyca](https://profiles.wordpress.org/unifyca/) [Download](https://downloads.wordpress.org/plugin/unifyca-audit-connector.2.5.1.zip) * [Details](https://mai.wordpress.org/plugins/unifyca-audit-connector/#description) * [Reviews](https://mai.wordpress.org/plugins/unifyca-audit-connector/#reviews) * [Installation](https://mai.wordpress.org/plugins/unifyca-audit-connector/#installation) * [Development](https://mai.wordpress.org/plugins/unifyca-audit-connector/#developers) [Support](https://wordpress.org/support/plugin/unifyca-audit-connector/) ## Description **Unifyca Audit Connector** is a WordPress audit and monitoring plugin that can optionally connect to Unifyca, a WordPress Website Management and Website Documentation platform for agencies and freelancers. Works locally. No account required. Connect to Unifyca only if you want centralized WordPress management and website documentation. The plugin is designed for: * **Freelancers** who maintain WordPress sites for clients and want a fast, repeatable way to review them. * **Agencies** who need a consistent maintenance and reporting workflow across many WordPress installations. * **Site owners** who want a clearer picture of the operational health of their site without learning the WordPress internals. The audit logic runs entirely on your own server. No site data leaves WordPress unless you explicitly connect the site to the Unifyca SaaS (described below). You can use the plugin for free, locally, without creating an account. Complete documentation, setup guides and screenshots: [View the documentation](https://unifyca.com/en/docs/) #### What the local audit checks **Security** * WordPress debug mode (`WP_DEBUG`) running on production * WordPress file editor enabled * XML-RPC endpoint enabled * HTTPS not enabled for the site URL * Directory listing on the site root * PHP execution allowed inside the uploads folder * Sensitive files publicly accessible (e.g. `wp-config.php`, `.env`, `.git/`) * Default `admin` username with administrator role * New administrator users detected since the last audit * `debug.log` file present in `wp-content/` **Maintenance** * WordPress core version outdated * Plugin updates pending * Active theme update pending * Inactive plugins / inactive themes accumulating on disk * PHP runtime older than the version WordPress currently recommends * No backup plugin detected * No caching plugin detected * Maintenance mode currently active * Expired transients accumulated in `wp_options` **SEO** * Search engines discouraged (Settings Reading) * Homepage with no H1, multiple H1s or an empty H1 **Privacy & compliance** * Detection of files in the uploads directory that may carry identifying metadata( EXIF / GPS in images, author or device data in PDFs) and publicly-accessible backup files. This check is intentionally separate from the standard audit because it can be slower on large installations. #### What you get for free, locally * On-demand local audit with one click from wp-admin * Overall website health score plus per-category scores (Security / Maintenance/ SEO / Privacy) * Severity-aware issue cards with a human explanation, why it matters and the recommended action * Counters by severity (Critical / High / Warning / Info) * Clean, agency-friendly dashboard styling * No account required to use the plugin locally #### What is Unifyca? Unifyca is a WordPress Website Management platform. It centralizes: • WordPress maintenance • Website monitoring • Backups • Website documentation • Hosting & domains • Credentials • Client reports Everything around your websites in one place. #### What Unifyca SaaS adds (optional) Manage multiple WordPress websites from one dashboard. You can connect the site to the Unifyca SaaS at [unifyca.com](https://unifyca.com) for centralised WordPress maintenance: * Apply safe fixes automatically from one dashboard * Manage every WordPress site you operate from a single screen * Schedule Autopilot fixes inside a configurable maintenance window * Receive uptime alerts when a site goes down * Generate white-label maintenance reports for clients * Keep a complete history of every audit and fix that has been applied * Keep hosting, domains, SSL certificates and credentials documented next to each website Connecting is fully optional. The plugin will continue running local audits even if you never create a Unifyca account. #### What this plugin is not * It is not a “set it and forget it” security shield. It detects and explains issues; it does not patch your site automatically without your action. * It does not add anything to your pages on its own. Structured data (JSON-LD) is printed on the homepage only after an authorised Unifyca user explicitly publishes it, and it can be stopped from wp-admin at any time. * It does not guarantee security, GDPR compliance, or freedom from vulnerabilities. The local audit helps you spot common problems and review them — it does not certify any outcome. * It does not send telemetry. There is no anonymous usage tracking and no analytics. ### External services This plugin can optionally connect to **Unifyca**, a Software-as-a-Service (SaaS) platform for WordPress website management and documentation. The connection is ** never automatic**: it requires an explicit administrator action (pasting the connection token generated by the plugin into the Unifyca dashboard). Until you do that, the plugin runs entirely locally and contacts no external service. #### Service and domains When the site is connected, the plugin communicates with the Unifyca SaaS over these domains: * [Unifyca](https://unifyca.com) — Website, documentation and account area. * [Unifyca App](https://app.unifyca.com) — Application/API, including the optional disconnect-feedback endpoint described below. #### What the service does Unifyca lets agencies and freelancers manage many WordPress sites from one place: it runs remote audits, applies administrator-approved fixes, runs and stores backups, monitors uptime, publishes homepage structured data when explicitly asked to, and keeps maintenance history and documentation. The connector exposes a set of HMAC- authenticated REST endpoints that the Unifyca SaaS calls to provide these features. #### What data is sent, and when * **Local audits do not transmit any data externally.** Running an audit from wp- admin keeps all results on your server. * Data is sent to Unifyca **only after the site is explicitly connected**, and only when the SaaS initiates an authenticated (HMAC-SHA256 signed) request — there is no scheduled or background “phone home”. * When connected, the data sent is the standard audit payload: WordPress core version, site URL, locale, timezone and multisite flag; installed plugins/themes metadata( name, slug, version, status, on-disk size, and where WordPress gets their updates from: WordPress.org slug or the host name of a declared Update URI — never code); server metadata (PHP version, memory limit, HTTPS state, `WP_DEBUG` and XML-RPC state, locally-resolved server IP); the WordPress Site Health diagnostic report( the same information WordPress exposes under Tools Site Health Info: configuration constants, database charset, directory sizes and file-system writability — with absolute server paths such as ABSPATH and WP_CONTENT_DIR removed); administrator account metadata (ID, login, email, display name, registration date and a one- way SHA-256 fingerprint of the password hash — never the hash itself); pending comment counts; and audit findings. Administrator login metadata (timestamp and IP of the last login) may be transmitted only when required for the security- monitoring features. * **Structured data publishing** sends nothing from your site except a short status( whether Unifyca’s JSON-LD is being printed, its publication number and a content hash) and the homepage URL. The JSON-LD itself travels the other way, from Unifyca to your site, and only when an authorised user presses Publish. See _Structured data publishing_ under _Privacy_ below. * **Storage analysis** (disk usage) results are sent only when an administrator runs a storage analysis from Unifyca: directory totals and a bounded list of the largest files, identified by paths relative to the WordPress folder. See _Storage analysis_ under _Privacy_ below for the exact data. * **Clean core replacement** sends only the progress of the operation (step names and states, the WordPress version, counts of checked files, relative names of the backup copies and the recovery instructions). It downloads the official package of the installed WordPress version from `https://downloads.wordpress.org` and its checksums from `https://api.wordpress.org` — the same WordPress.org services WordPress itself uses for updates — and only when an authorised Unifyca user starts it. * **Core integrity check** (read-only) sends only counts and a short list of file names relative to the WordPress folder (missing, modified or unexpected core files). It compares the installed core with the official checksums from `https:// api.wordpress.org` (through WordPress’s own `get_core_checksums()`) and only runs when an authorised Unifyca user requests the final verification of a security incident. Nothing is changed, downloaded or deleted. * **Recovery point status** (read-only) sends only, for each backup copy left by a clean core replacement, its relative name and whether it still exists on the server. Nothing is changed, deleted or followed through symbolic links. * The plugin never sends database contents, post or page content, user passwords, or hosting/FTP/SSH/database credentials. #### Optional disconnect feedback When you disconnect the site from Unifyca through the **Connect to Unifyca** tab, the confirmation modal exposes an _optional_ “what made you disconnect?” reason selector with a short comment field. Submitting it is never required to disconnect. **No personal user data is sent automatically.** The connected site URL and the optional feedback reason/comment may be shared with Unifyca **only** when you explicitly submit the disconnect feedback form. The site URL is included because, in some setups, it can identify a business or organisation; we are upfront about this so you can decide whether to submit feedback at all. If — and only if — you fill in one of those fields, the plugin sends a single non- blocking HTTPS POST to `https://app.unifyca.com/ajax/wp-disconnect-feedback.php` containing: the selected reason code, the optional comment (up to 500 characters), the site URL, the connection token (so Unifyca can match the entry to the correct tenant), and the plugin version. The connection token is transformed into a non- reversible representation before storage. The connection token is never stored in its original form. The connection token is the only stable identifier the plugin holds for the connected tenant — the handshake does not store a separate Unifyca tenant/project/site ID. The shared secret is deliberately never included in this payload. The request is fire-and-forget: if it fails, the disconnect still completes normally. Nothing else is transmitted at this step. #### Terms and privacy * [Terms of Service](https://unifyca.com/en/terms/) * [Privacy Policy](https://unifyca.com/en/privacy/)= Privacy = This plugin performs a local WordPress audit. Connecting the site to the Unifyca SaaS at unifyca.com is entirely optional and requires explicit administrator action. Local audits do not contact any external service; external communication only occurs after the administrator explicitly connects the site to Unifyca. #### Data the plugin stores locally The plugin writes a small set of options and user metas inside your WordPress database: * `unifyca_connection_token`, `unifyca_token_status`, `unifyca_shared_secret`, ` unifyca_connection_status`, `unifyca_connected_at` — connection state, only populated when the site is connected to Unifyca. * `unifyca_prev_admin_ids` — list of administrator user IDs at the time of the last audit; used internally to detect newly added administrators between audits. * `unifyca_disable_xmlrpc` — set to 1 when an administrator chose to disable XML- RPC through a connector fix action. * `unifyca_last_local_audit_at` — ISO timestamp of the last local audit. * `unifyca_last_privacy_lite_scan` — structured result of the last lightweight privacy review (counts and a few sample relative paths, never metadata values). * `unifyca_last_privacy_lite_scan_at` — ISO timestamp of the last lightweight privacy review. * `unifyca_structured_data` — structured data (JSON-LD) published from Unifyca for the homepage, with its publication number, a content hash and whether it is currently printed. Only written when an authorised Unifyca user publishes or unpublishes, or when an administrator stops the output from wp-admin. * `unifyca_core_ops` — state of the last clean core replacements (at most 10): steps, WordPress version, relative names of the backup copies and whether they were deleted. Only written when an authorised Unifyca user starts a clean core replacement. The backup copies themselves live in the WordPress folder (`wp-admin. unifyca-backup-*`, `wp-includes.unifyca-backup-*`, `.unifyca-core-*`), are protected against web access on Apache and IIS (on nginx, deny `/\.unifyca-core-` and `/ wp-(admin|includes)\.unifyca-backup-` in the server configuration) and are only deleted when an authorised user asks for it. * `unifyca_disconnect_feedback_log` — rolling local log of the last 20 disconnect feedback submissions (reason code, optional comment, site URL, connection token at the time, plugin version, ISO timestamp). Only written when the administrator submits the optional disconnect feedback form. Always available for inspection via WP-CLI: `wp option get unifyca_disconnect_feedback_log --format=json`. * `_unifyca_last_login_at`, `_unifyca_last_login_ip` (user metadata) — timestamp and IP of the most recent successful login for administrator users only. Used to flag suspicious administrator activity. When the site is connected to Unifyca, this information may be transmitted to the Unifyca service to generate security alerts related to administrator account activity. The information is not used for advertising or profiling purposes. All of the above are removed on plugin uninstall. #### Data sent to Unifyca The plugin does not transmit any data to Unifyca unless an administrator explicitly connects the site. When connected, the plugin sends audit results and connection metadata required for the Unifyca service to operate. #### Privacy scan: what is analysed and what is sent The optional privacy scan inspects the files published in your uploads folder to report metadata that anyone downloading those files could read. The analysis happens entirely on your own server: files are opened read-only, only their metadata containers are examined (EXIF, IPTC and XMP in images, the document information dictionary and XMP block in PDFs), and the scan itself never modifies a file. Document text is not extracted, no OCR is performed, and file contents are never uploaded. What is sent to Unifyca when the site is connected are the findings and the metadata values that were found, so that the account holder can see the evidence and show it to the site owner. Those values can include personal information that was already readable by anyone with the file, for example: * author, artist, creator, owner, by-line and credit names; * e-mail addresses, phone numbers and postal addresses present in image or document metadata; * GPS coordinates, altitude and GPS timestamps; * camera and lens make, model and serial numbers; * creation and modification dates; * the software used to create or edit the file; * copyright notices and usage terms; * document titles, subjects and keywords. This is not a zero-knowledge design: the metadata values are stored in your Unifyca account so the audit report can display them. Values are length-limited and stripped of control characters, and the file itself never leaves your server. The transmission uses the same HMAC-signed channel as the rest of the connector. The plugin does not send: * WordPress user passwords. * Hosting, FTP or SSH passwords. * Database passwords. * WordPress post or page contents. * Uploaded media files, thumbnails or any part of a file’s contents — only the metadata values described above. * Backup archives unless the administrator explicitly configures an external backup destination or uses a Unifyca backup feature that requires file transfer. #### Metadata cleaning (optional, administrator-initiated) When the site is connected, an administrator can ask Unifyca to remove the metadata from a single file reported by the privacy scan. Nothing is cleaned automatically: every clean is started by a person, one file at a time, after a confirmation. * Only JPEG, WebP, PNG and PDF files inside the uploads folder can be cleaned. Any other location or format is refused. * Only metadata that can be removed without changing how the file looks or renders is removed. Images are never re-encoded or recompressed, and no image library, external tool or shell command is used; PDFs are only changed when the metadata can be blanked … ## Installation 1. Install **Unifyca Audit Connector** through Plugins Add New, or upload the plugin folder to `wp-content/plugins/`. 2. Activate the plugin. 3. Go to **Unifyca Audit** in the wp-admin sidebar. 4. Click **Run audit** to perform the first local audit. Results appear inline. 5. (Optional) To connect this site to the Unifyca SaaS, open the **Connect to Unifyca** tab, copy the connection token and paste it into the corresponding Unifyca dashboard. #### Requirements * WordPress 5.8 or newer * PHP 7.1 or newer * PHP `curl` extension recommended (used to read the homepage HTML when checking SEO heading structure) * PHP ZipArchive extension required for backups. ## FAQ ### What is WordPress Website Management? WordPress Website Management is the practice of centralizing updates, audits, monitoring, backups and the infrastructure around websites. Unifyca combines: * Security audits * Monitoring and uptime * Backups * Website documentation * Hosting and domains * Credentials * Client reports Everything around your websites in one place. ### Does the plugin modify my site automatically? No. Local audits are read-only. No changes are made unless an administrator explicitly performs an action. ### Does this plugin send my data anywhere? No, not unless you explicitly connect the site to the Unifyca SaaS through the ** Connect to Unifyca** tab. When **not connected**, the local audit performs no outbound requests to any external service. The only network requests it can make are HTTPS loopback requests to your own site URL (to read the homepage HTML and to check whether files like `wp-config. php` respond publicly). No site contents, no posts, no users, no credentials and no audit results are transmitted anywhere unless the site is explicitly connected. See the _External services_ section below for what happens once you connect. ### How is the audit triggered? Only on explicit action: * The wp-admin user clicks **Run audit** in the dashboard. * The Unifyca SaaS sends an HMAC-authenticated REST request to `/wp-json/unifyca/ v1/audit` (this happens only when the site is connected). There is no scheduled or background audit. There is no telemetry. ### Can I keep using the plugin without creating a Unifyca account? Yes. The local audit dashboard works fully without a Unifyca account. The **Connect to Unifyca** tab is purely optional. ### What user role can run the audit? Only users with the `manage_options` capability (typically administrators). All admin actions and the AJAX endpoint validate this capability and a WordPress nonce on every request. ### Why does the audit take a few seconds? The audit performs HTTP checks against your own site URL (homepage, sensitive paths) and synchronously calculates Site Health values. These checks are intentionally local and can take a few seconds on larger installations. Run the audit when you want fresh results — the dashboard does not auto-refresh. ### Why is the score for one of my sites not 100? The plugin penalises each detected issue based on severity (Critical, High, Warning, Info) and shows you exactly which checks contributed. When the site is **not connected** to Unifyca, the dashboard exposes per-category tabs (Security, Maintenance, SEO, Privacy) with the full local list of findings and explanations. When the site **is connected** to Unifyca, the wp-admin dashboard becomes a lightweight companion view and the detailed breakdown, fix history and automation live in the Unifyca dashboard. ### Can I uninstall the plugin without leaving residual data? Yes. When you delete the plugin from wp-admin Plugins, the `uninstall.php` script runs and removes every option and user meta value the plugin has stored. No data remains. ### Does this plugin guarantee my site is secure? No. The audit helps detect and explain a number of common operational and security issues, but it cannot guarantee that a site is secure. Treat the findings as a checklist to review and improve — not as a certification. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “Unifyca Audit Connector” is open source software. The following people have contributed to this plugin. Contributors * [ unifyca ](https://profiles.wordpress.org/unifyca/) “Unifyca Audit Connector” has been translated into 2 locales. Thank you to [the translators](https://translate.wordpress.org/projects/wp-plugins/unifyca-audit-connector/contributors) for their contributions. [Translate “Unifyca Audit Connector” into your language.](https://translate.wordpress.org/projects/wp-plugins/unifyca-audit-connector) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/unifyca-audit-connector/), check out the [SVN repository](https://plugins.svn.wordpress.org/unifyca-audit-connector/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/unifyca-audit-connector/) by [RSS](https://plugins.trac.wordpress.org/log/unifyca-audit-connector/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 2.5.1 * New: read-only status of the recovery points left by a clean core replacement( whether the previous wp-admin, wp-includes and root core file copies still exist on the server). Relative names only; nothing is changed, deleted, downloaded or followed through symbolic links. * New: read-only check of the integrity of the WordPress core, used by the final verification of Unifyca security incidents. It compares wp-admin, wp-includes and the official root core files with the official WordPress checksums of the installed version and reports only counts and file names relative to the WordPress folder. It never changes, renames, downloads, backs up or deletes anything; wp- content, wp-config.php (and its variants), .htaccess, .user.ini and web.config are not part of the check. #### 2.5.0 * New: clean WordPress core replacement. When an authorised Unifyca user starts it (from a security incident), the plugin reinstalls the SAME WordPress version from the official package on downloads.wordpress.org. It never updates WordPress. * The package is downloaded, extracted and checked against the official WordPress checksums before anything on the site is touched; if any check fails nothing is modified. * Only wp-admin, wp-includes and the official core files of the root folder are replaced. wp-content, wp-config.php (and any copy or variant of it, such as wp- config-old.php), .htaccess, web.config and any other file are never modified or deleted (wp-config-sample.php is an official core file and is replaced like the others); files that are not part of WordPress are only reported. * The previous core is kept for rollback (renamed folders with a random suffix and a protected folder with the replaced root files, plus plain-text recovery instructions). If anything fails after the first change, the previous core is restored automatically. The copies are only deleted when an authorised user asks for it. * Other fixes wait while a core replacement is running. #### 2.4.1 * Security: the temporary backup of WordPress core taken before a core update no longer includes wp-config.php (or copies of it). The updater never changes that file, and it holds the database credentials and salts. * Security: backup archives now get an unguessable name and restrictive file permissions, are built under a temporary name and only kept when complete, and the backup folder also blocks directory listing and IIS access. * The local dashboard now uses the same alert severities as the Unifyca SaaS for every alert both report. #### 2.4.0 * New: structured data publishing. An authorised Unifyca user can publish JSON- LD for the homepage; the plugin stores it in its own option and prints it in ` ` on that exact homepage URL only. Nothing is printed until someone explicitly presses Publish in Unifyca. * Theme files and the structured data of other plugins (Yoast SEO, Rank Math, …) are never modified; Unifyca only adds its own marked scripts, and unpublishing removes only those. * Administrators can stop the output from the Connect to Unifyca tab at any time, including after disconnecting. Uninstalling the plugin removes it. * The received JSON-LD is validated, size-limited and re-encoded so it can never break out of its script element. Publications are numbered, so an older request can never overwrite a newer one. * The audit sync now reports the WordPress home URL (which differs from the site URL when WordPress lives in a subdirectory). #### 2.3.0 * New: storage analysis. When requested from Unifyca, the plugin measures how much disk space the WordPress installation uses and where. Only file sizes and dates are read: files are never opened, uploaded or modified, symbolic links are not followed, and nothing outside the WordPress folder is read. See _Storage analysis_ in the Privacy section for exactly what is sent. * The analysis runs in short, bounded, resumable steps (adjusted to the server’s own time limit), so large installations with hundreds of thousands of files can be measured without long-running requests. * Results are reported as folder totals down to four levels below the WordPress folder, plus a short list of the largest files — never a list of every file. * Hardened the path validation used when deleting a WordPress core backup from Unifyca. #### 2.2.0 * New: metadata cleaning. From Unifyca, an administrator can remove the metadata that the privacy scan found in a single JPEG, WebP, PNG or PDF file in the uploads folder. Every clean is started by a person and confirmed first; nothing is cleaned automatically. * Everything that can be removed without changing how the file looks is removed: location, author and contact details, camera identifiers, dates, software, copyright and document properties. Images are never re-encoded, so their quality is exactly the same; colour profiles and orientation are kept. * The cleaned file is built and verified before it replaces the original, and the original is put back if the result does not verify. Files that cannot be cleaned safely (for example encrypted, signed or archival PDFs) are left untouched and reported as such. * The privacy scan now also reads WebP metadata. * Adding a sitemap reference to robots.txt no longer discards the rules the site was already serving. When no robots.txt file exists, WordPress generates one and SEO plugins usually add their own directives to it; creating a real file replaces that generated document entirely. The new file is now written with exactly the content the site was serving, with the sitemap line appended to it, so nothing that was in force is lost. * The fix reports when it had to create the file and where its content came from, so the change is visible rather than silent. #### 2.1.0 * Large sites can now be audited completely. Until now the privacy scan ran in a single request and stopped at a fixed budget, so a site with more files than that budget was only ever partly examined and could never be reported as finished. The scan can now be carried out over several short visits, each picking up exactly where the previous one stopped, so the whole uploads folder is covered however large it is. * Each visit is deliberately brief and bounded, so the scan never keeps the site busy for long stretches and never holds large amounts of data in memory — a folder with fifty thousand files costs the same memory as one with fifty. * Directories are read in a stable order, so what the scan reports no longer depends on the order the filesystem happens to return files in. * Folders that cannot be read are now reported as such, instead of being indistinguishable from folders that contained nothing. * Symbolic links inside the uploads folder are not followed. * Sites connected to an older version of Unifyca keep the previous single-request behaviour exactly as before. #### 2.0.11 * The privacy scan now reads much more of what is actually published inside your files. For images it reads EXIF, IPTC and XMP instead of EXIF alone, so author names, contact details, copyright notices, capture dates, camera and lens identifiers and location coordinates are all reported. PNG files are inspected again, through a dedicated reader for their text and EXIF chunks. For PDFs it now also reads Subject, Keywords, creation and modification dates and the XMP metadata block, and it correctly decodes names written in Unicode. * Findings are now grouped by the kind of information exposed — location, personal identity, contact details, device, dates, software, copyright, document properties— instead of by file format, so the same category reads the same way whatever the file is. * Files are now identified by their actual content rather than by their extension. A document renamed to look like a photo is inspected as what it really is, and the mismatch itself is reported. * Images can now be inspected even on servers without the PHP EXIF extension, using a small built-in reader. The scan reports which readers were available and which ones actually ran, so a category that could not be inspected is never presented as “nothing found”. * PDFs that are encrypted, or whose structure prevents a reliable reading, are now reported as not fully inspected instead of appearing to have no metadata. * Word, Excel and PowerPoint files are no longer counted as inspected. Their metadata was never actually read; they are now honestly reported as pending a future release. * The audit no longer fails outright on slow sites. Several checks ask the site to fetch its own pages, and on a slow server those requests together could take longer than the audit was allowed to run, so no report was produced at all. They now share a time budget that also takes into account how long the audit has already been running: the most valuable checks run first, anything that does not fit is skipped, and the audit returns what it did manage to look at. A skipped check is reported as “not checked” and never as a clean result. * robots.txt is read once per audit instead of twice. #### 2.0.10 * The privacy scan now reports whether the site could actually read image metadata. If the server has no EXIF support, the result says so instead of looking identical to “no metadata found”, so a site that could not be inspected is never presented as verified clean. * The privacy scan also reports clearly when it stopped early because it reached its own safety limits (number of files, number of findings or elapsed time). Previously a partial scan was indistinguishable from a complete one. * PNG files are no longer treated as an inspected image format. PNG metadata containers were never actually read, yet PNG files counted towards the scan limits as if they had been inspected. They are still checked by file name, and PNG metadata reading will come in a future release. #### 2.0.9 * Fixed active plugins being left deactivated after being updated from Unifyca. The update used a WordPress routine that deactivates a running plugin before replacing its files and does not switch it back on; the plugin now uses the same routine the WordPress Plugins screen uses, which never deactivates anything. As an extra safeguard, any plugin that was active before the update and is not active afterwards is switched back on silently, and the result reports it. Plugins that were inactive stay inactive. * The connector can now update itself when a connected Unifyca account asks it to. The new version is installed through WordPress’s own plugin update system from the WordPress.org directory, exactly like pressing “Update now” in Plugins; nothing is downloaded from any other location and the request cannot choose which plugin to update — it is always this one. The connector keeps its activation state, including network activation on multisite, and if it is ever left inactive the result says so instead of failing silently. #### 2.0.8 * Fixed plugins being reported as “WordPress.org plugins” when WordPress had merely checked them for updates. WordPress lists every installed plugin in its update- check data, so premium and custom plugins were classified the same as plugins from the WordPress.org directory. A plugin (or theme) is now identified as a WordPress.org item only when the WordPress.org update service itself returned it. * The audit now reports, for each plugin and theme, where WordPress gets its updates from: WordPress.org (with its WordPress.org slug), a third-party updater or “ Update URI” header (only the host name is sent), none, or unknown. This lets Unifyca avoid mistaking a custom plugin for a WordPress.org plugin that happens to use the same folder name. No new data is collected from the site beyond what WordPress core already stores for its own update checks. #### 2.0.7 * Fixed plugin (and theme) update availability being reported as “up to date” for every plugin on the first audit after updating a plugin. WordPress deletes its cached update data when a plugin is updated; the audit now refreshes that data through WordPress core’s own update checks before reading plugin and theme information, instead of afterwards. #### 2.0.6 * Fixed the WordPress Site Health directory sizes (“WordPress directory size”, “ Uploads directory size”, themes, plugins, database and total) being reported as “Loading…” instead of the real value. These sizes are computed asynchronously in wp-admin; the connector now computes them synchronously via `WP_Debug_Data:: get_sizes()` and uses the resulting values whenever available, instead of relying on the internal `loading...` placeholder marker. On large sites the audit may take a few extra seconds while the sizes are calculated. * Stripped absolute server paths from the Site Health data before it is sent. Every section is scanned — the core “WordPress constants” (ABSPATH, WP_CONTENT_DIR, WP_PLUGIN_DIR …) and “Directories and Sizes” (the WordPress, uploads, themes and plugins directory locations) sections, as well as any section added by third- party plugins (for example Redux Framework’s “Data Directory”). WordPress core exposes these paths locally in Tools Site Health Info, but they are no longer transmitted to the connected service, consistent with the path-disclosure hardening in 2.0.2 / 2.0.4. Non-path diagnostics (versions, memory limits, database charset, directory sizes, writability, etc.) are unchanged. * Fixed WordPress admin notices (theme/plugin update prompts, etc.) rendering next to the plugin logo instead of in their normal position. Added the standard `wp- header-end` marker so core moves notices below the page header. #### 2.0.5 * Fixed administrator login IP detection behind proxies. The recorded “last login IP” previously defaulted to REMOTE_ADDR, which on sites served through Cloudflare, a reverse proxy, a load balancer or a managed-hosting front-end is the proxy/ server address rather than the real administrator IP. * IP resolution now trusts forwarded headers only when the request genuinely arrives through a proxy: CF-Connecting-IP is used only when REMOTE_ADDR is a known Cloudflare edge range, and X-Forwarded-For is used only when REMOTE_ADDR is not a public client IP. Private, reserved, loopback and invalid forwarded values are rejected, and REMOTE_ADDR remains the safe fallback. * Resolution stays fully local to the current request’s server variables — no external service or outbound request is used. IPv4 and IPv6 are both supported. #### 2.0.4 * Compliance pass following the WordPress.org manual review. * Determine file/directory locations through the WordPress API instead of internal constants: the audit payload now reports the public content URL via `content_url()`, and other plugins’ on-disk size is measured by deriving the plugins root from` plugin_dir_path()` on the main file rather than `WP_PLUGIN_DIR`. * Disk-free-space probing no longer falls back to an absolute server path: if ` wp_upload_dir()` cannot be resolved the probe is skipped. * Database backups are now stored as a protected ZIP archive (`database.zip`) only. The raw SQL is streamed to a temporary file (`wp_tempnam()`), added to the ZIP, and deleted immediately in both success and failure paths — a loose `database. sql` is never left on disk. ZIP support is required; there is no loose-SQL fallback. * Removed the literal `ABSPATH` token from user-facing error messages. #### 2.0.3 * Restored the automatic “disable file editor” fix using a runtime-only define. When enabled, DISALLOW_FILE_EDIT is set with `define()` on every request from the plugin bootstrap — wp-config.php is never modified, no file is written to disk and an existing definition is never overridden. * WP_DEBUG remains detection-only with a manual recommendation; it is never changed automatically. #### 2.0.2 * Compliance pass following the WordPress.org manual review. * Replaced all plugin cURL calls with the WordPress HTTP API (`wp_remote_get`). * The plugin no longer edits wp-config.php automatically. The WP_DEBUG and file- editor fixes now return a manual recommendation telling the administrator exactly which line to add; the audit still detects the issue. * Pre-modify file backups (e.g. .htaccess, robots.txt) are now stored inside ZIP archives in the protected uploads backup directory — no loose `.bak` or config files are ever written. * Stopped exposing absolute server paths (ABSPATH, WP_CONTENT_DIR, document root) in the audit payload and error messages. * Added the `UNIFYCA_PLUGIN_URL` constant and tidied file/directory location handling; writable storage always uses `wp_upload_dir()`. #### 2.0.1 * WordPress.org compliance pass following directory pre-review. * Removed the external public-IP lookup (`api.ipify.org`). Local audits now make no outbound requests to any external service; the server IP is resolved locally only. * Removed the connector self-update mechanism. The plugin now relies exclusively on the WordPress.org update infrastructure and no longer writes the `update_plugins` site transient. * Hardened backup storage: backups are stored under `wp-content/uploads/unifyca- backups/` (via `wp_upload_dir()`), always protected with an `index.php` and a deny-all `.htaccess`. Core backups are written as a single ZIP archive — the plugin never leaves loose, web-accessible PHP files (e.g. `wp-config.php`, `wp- settings.php`) in the backup directory. * Replaced every `__return_true` REST permission callback with dedicated callbacks that verify the connection state, the HMAC signature (timestamp freshness + shared- secret), and, for backup downloads, the short-lived signed token. * Documented all external services and updated the Privacy section. #### 2.0.0 * New wp-admin dashboard. Replaces the previous connector-only settings page with a full website-health audit experience. * Local audits run without a Unifyca account. The plugin can be used standalone. * New score system (overall + per-category) with consistent severity colours. * Issue cards include human explanations, “why it matters” and recommended actions. * New `Unifyca_Audit_Engine` class. Single source of truth for all audit checks. * New `Unifyca_Alert_Catalog` class. Translates raw audit data into UI-friendly issue cards. * New `Unifyca_Score` class. Pure score-calculation layer. * AJAX-driven “Run audit” button. No page reload. Nonce + `manage_options` enforced. * `uninstall.php` removes every option and user meta the plugin created. * WordPress.org-compliance pass: connector self-update gated behind `UNIFYCA_ALLOW_CONNECTOR_SELF_UPDATE`( off by default). #### 1.0.17 * Connector-only release. Token pairing, HMAC validation and SaaS sync. ## Meta * Version **2.5.1** * Last updated **1 week ago** * Active installations **10+** * WordPress version ** 5.8 or higher ** * Tested up to **7.0.7** * PHP version ** 7.1 or higher ** * Languages * [English (US)](https://wordpress.org/plugins/unifyca-audit-connector/), [Spanish (Chile)](https://cl.wordpress.org/plugins/unifyca-audit-connector/), and [Spanish (Spain)](https://es.wordpress.org/plugins/unifyca-audit-connector/). * [Translate into your language](https://translate.wordpress.org/projects/wp-plugins/unifyca-audit-connector) * Tags * [security audit](https://mai.wordpress.org/plugins/tags/security-audit/)[wordpress backup](https://mai.wordpress.org/plugins/tags/wordpress-backup/) [WordPress Management](https://mai.wordpress.org/plugins/tags/wordpress-management/) [wordpress monitoring](https://mai.wordpress.org/plugins/tags/wordpress-monitoring/) * [Advanced View](https://mai.wordpress.org/plugins/unifyca-audit-connector/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/unifyca-audit-connector/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/unifyca-audit-connector/reviews/) ## Contributors * [ unifyca ](https://profiles.wordpress.org/unifyca/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/unifyca-audit-connector/)