System requirements and compatibility

PW Security and Backup system requirements and compatibility

PW Security and Backup is designed to provide WordPress login protection, file monitoring, security analysis, local traffic records, file-integrity controls and manual backup tools from a single administration interface.

The plugin performs its main operations within the website’s own WordPress installation and hosting environment. It does not require a PW Feed account, Poyraz Web account, remote security dashboard, licence key, paid cloud-backup service or external malware-scanning subscription.

Because security scanning, file-integrity analysis and backup creation use server resources, compatibility depends on more than the installed WordPress version. PHP extensions, file permissions, available disk space, memory limits, execution-time limits, WordPress cron behaviour and hosting security rules can all affect individual features.

This page explains the minimum software requirements, recommended server configuration, feature-specific requirements and common compatibility considerations for PW Security and Backup.

Basic system requirements

PW Security and Backup requires:

• WordPress 5.8 or later.

• PHP 7.4 or later.

• An active WordPress installation.

• Access to the WordPress administration area.

• A user account with the required administrator permissions.

• A writable WordPress uploads directory for backup and related file operations.

• Sufficient database and disk capacity for enabled logging, scanning and backup features.

• A modern web browser with JavaScript and cookies enabled.

• A server configuration that allows normal WordPress database, file and scheduled-task operations.

The plugin should be used with a maintained version of WordPress and a PHP version that continues to receive security support from its provider.

Meeting the minimum requirements does not guarantee that every resource-intensive feature can complete on every hosting plan. Manual backup creation and large file scans may also depend on the website’s size and the limits imposed by the hosting provider.

Recommended environment

For more reliable operation, the following environment is recommended:

• The latest stable WordPress version that is compatible with the website’s active theme and plugins.

• PHP 8.1 or later, provided that all installed WordPress components are compatible.

• HTTPS enabled across the website and administration area.

• At least 256 MB of PHP memory for ordinary websites.

• A higher memory limit for large WooCommerce websites or installations containing many files.

• PHP ZipArchive enabled for backup creation and archive inspection.

• Sufficient free disk space for temporary and completed backup data.

• Correct ownership and permissions for WordPress files and directories.

• A working WordPress WP-Cron system or a correctly configured hosting-level cron.

• A reliable WordPress email or SMTP configuration for security notifications.

• Regular external backups maintained independently of the plugin.

• Hosting-level access through a control panel, FTP or SFTP for emergency recovery.

• A staging environment for testing important security, login or recovery changes.

The recommended environment reduces the likelihood of incomplete scans, failed archives, delayed scheduled checks and email-delivery problems.

WordPress compatibility

PW Security and Backup is intended for standard self-hosted WordPress installations.

The minimum supported WordPress version is 5.8. However, administrators should normally keep WordPress updated to a maintained stable release because outdated WordPress versions may contain security weaknesses or compatibility problems that cannot be corrected by an individual plugin.

Before updating WordPress:

• Create a current backup.

• Confirm theme compatibility.

• Confirm compatibility with business-critical plugins.

• Review the hosting provider’s PHP and database support.

• Test the update in a staging environment when possible.

• Verify login access after the update.

• Review the PW Security and Backup administration screens.

A WordPress update should not ordinarily remove the plugin’s settings or stored information. Nevertheless, important updates should always be supported by a current recovery plan.

PHP compatibility

PW Security and Backup requires PHP 7.4 or later.

The plugin should not be installed on an environment using a PHP version older than 7.4. Older PHP releases may lack required functionality and may no longer receive official security fixes.

A maintained PHP 8.x version is recommended when it is supported by the active WordPress version, theme, plugins and hosting provider.

Before changing the website’s PHP version:

1. Create a current backup.
2. Confirm WordPress compatibility.
3. Review the active theme’s requirements.
4. Check all business-critical plugins.
5. Test the change in a staging environment when available.
6. Review WordPress and server error logs.
7. Test login, forms, payment processes and scheduled tasks.
8. Open PW Security and Backup and review its main screens.

A problem that appears after a PHP upgrade may originate from WordPress, the theme, another plugin or custom code. The complete environment should therefore be reviewed before the cause is assigned to one component.

PHP ZipArchive requirement

The PHP ZipArchive extension is required for features that create, inspect or use ZIP backup archives.

Without ZipArchive, the main security and monitoring functions may remain available, but manual full-backup creation and archive-dependent recovery functions cannot operate correctly.

If the plugin reports that ZipArchive is unavailable:

• Open the hosting control panel and review PHP extensions.

• Confirm that the extension is enabled for the PHP version used by the website.

• Check whether the command-line PHP version differs from the web-server PHP version.

• Contact the hosting provider if extension management is unavailable.

• Reload the WordPress administration area after the extension is enabled.

Enabling ZipArchive may require restarting the PHP service. On managed hosting, this process is normally completed by the hosting provider.

Database requirements

PW Security and Backup uses the website’s existing WordPress database.

The database server must meet the requirements of the installed WordPress version. The plugin does not require a separate external database or remote security database.

Depending on the enabled features, the local WordPress database may store:

• Plugin configuration.

• Failed-login records.

• Temporary IP bans.

• IP allowlist and blocklist entries.

• Security events.

• File Scanner findings.

• Ignored-finding information.

• Quarantine records.

• File-integrity information.

• Scheduled-check settings.

• Security Analysis information.

• Live Traffic records when that feature is enabled.

Live Traffic is disabled by default because request recording can increase database activity and storage use, especially on websites receiving significant visitor or bot traffic.

Administrators should monitor database size, select appropriate log-retention settings and clear unnecessary Live Traffic records when they are no longer required.

File and directory permissions

PW Security and Backup needs normal WordPress access to the files and directories involved in scanning, integrity checks, quarantine, recovery and backup operations.

The WordPress uploads directory must be writable for backup creation.

Other operations may require permission to:

• Read WordPress core files.

• Read plugin and theme files.

• Calculate file signatures.

• Move a selected file into quarantine.

• Restore a selected file from a backup.

• Create protected backup directories.

• Write temporary backup information.

• Delete an authorised backup archive.

Permissions should never be made unnecessarily broad simply to make a feature work.

Directories should not normally be set to globally writable permissions. If an operation fails, the website owner should review file ownership and hosting configuration instead of applying insecure permissions.

The hosting provider can confirm the correct ownership and permission values for its server environment.

Disk-space requirements

Security logs and integrity data normally require much less space than a complete website backup. Manual full-backup creation may temporarily require significantly more free space.

A backup archive can include:

• WordPress core files.

• Installed plugins.

• Installed themes.

• Uploaded media.

• Other selected WordPress files.

• WordPress database tables.

The required free space depends on the website’s total size, file compressibility, database size and temporary archive process.

As a practical precaution, available free disk space should be comfortably greater than the size of the website data being backed up. Some hosting environments may need additional temporary space while the archive is being created.

Backup creation can fail when:

• The hosting account is near its storage quota.

• The website contains very large media files.

• Old backups consume available space.

• Temporary files remain from interrupted operations.

• The database is unusually large.

• The hosting provider applies a separate inode limit.

• The server terminates the process before completion.

Administrators should review server storage before creating a large backup and remove obsolete archives only after confirming that a usable recovery copy exists elsewhere.

PHP memory requirements

File scanning, integrity checks and backup creation consume PHP memory.

The exact amount required depends on:

• Number of files.

• File sizes.

• Database size.

• Number of installed plugins and themes.

• WooCommerce data volume.

• Available server resources.

• Other processes running at the same time.

A PHP memory limit of at least 256 MB is recommended for ordinary installations. Large websites may require more.

Increasing the WordPress memory setting cannot override a lower hosting-level limit. If the effective memory limit remains low, the hosting provider may need to change the PHP configuration.

A backup or scan should not be started while the website is performing a major import, update, migration or another resource-intensive task.

PHP execution-time limits

Some hosting providers restrict the maximum duration of a PHP request.

A small website may complete a scan or backup quickly, while a large installation can require substantially more time.

Possible effects of a low execution-time limit include:

• Backup creation stopping before completion.

• A scan ending unexpectedly.

• An incomplete archive.

• A gateway timeout.

• A blank administration response.

• A server-generated 500 or 504 error.

• A browser request ending while the server is still processing.

The plugin cannot always override limits enforced by the hosting provider, PHP process manager, reverse proxy or web server.

When a large operation repeatedly stops at a similar point, review the PHP execution limit, proxy timeout, web-server timeout and hosting security rules.

Web-server compatibility

PW Security and Backup is designed to operate within ordinary WordPress hosting environments, including websites served through Apache, Nginx or LiteSpeed-based configurations.

The exact server behaviour can vary according to hosting rules.

Apache environments may use .htaccess files for certain directory protections. Nginx does not process .htaccess files, so equivalent restrictions may need to be applied through the server configuration.

Regardless of the server type, administrators should verify that protected backup directories and backup archives cannot be accessed by unauthorised visitors through a direct public URL.

If server-level changes are required, contact the hosting provider rather than applying unverified configuration rules to a production website.

WordPress WP-Cron compatibility

Scheduled health checks and file-integrity checks normally depend on WordPress WP-Cron.

Available intervals may include:

• Every 6 hours.

• Every 12 hours.

• Every 48 hours.

• Weekly.

• Every two weeks.

• Monthly.

WP-Cron is normally triggered by website activity. On a low-traffic website, a scheduled event may run later than its configured time.

Scheduled checks may also be delayed when:

• WP-Cron is disabled.

• Loopback requests are blocked.

• A caching or security rule interferes with cron requests.

• The hosting provider restricts background processes.

• A real server cron is incorrectly configured.

• The website receives little or no traffic.

A hosting-level cron can provide more consistent scheduling when it is configured correctly.

Scheduled health and integrity checks do not create automatic full-backup archives in the current version. Full backups are started manually by an authorised administrator.

Email compatibility

PW Security and Backup uses the normal WordPress email system for enabled notifications.

Depending on the selected settings, notifications may be generated for supported events such as:

• File changes.

• Administrator logins.

• IP bans.

Successful notification delivery requires WordPress email to operate correctly.

The plugin passes the message to the configured WordPress mail system, but final delivery may depend on:

• Hosting mail restrictions.

• SMTP authentication.

• Sender-domain configuration.

• SPF, DKIM and DMARC records.

• Transactional email services.

• Recipient-server policies.

• Spam filtering.

• Mailbox rules.

• The accuracy of the recipient address.

If other WordPress email messages are not delivered, PW Security and Backup notifications are also unlikely to arrive reliably.

An SMTP plugin or transactional email service can improve delivery when it is correctly configured. SMTP passwords and other credentials should never be included in public support requests.

Browser requirements

The WordPress administration screens should be accessed through a current desktop or mobile browser with:

• JavaScript enabled.

• Cookies enabled.

• HTTPS access.

• Support for modern HTML and CSS.

• Permission to download authorised reports and backup archives.

Very old browsers may not display administration controls correctly.

Browser extensions, aggressive privacy tools, script blockers or corporate security software may prevent some WordPress administration requests from completing. If a control does not respond, test with a current browser and review the browser console before changing plugin files.

A backup process may also require the administration page to remain open until completion. Closing the browser tab, losing the internet connection or allowing the computer to enter sleep mode may interrupt a browser-dependent operation.

HTTPS compatibility

HTTPS is strongly recommended for every website using PW Security and Backup.

The WordPress login form, security settings, backup downloads and administration pages may contain sensitive information.

HTTPS helps protect information transmitted between the administrator’s browser and the website. It does not protect a compromised server, weak password, exposed backup directory or infected administrator device.

After enabling HTTPS:

• Confirm the WordPress Address and Site Address.

• Redirect HTTP requests to HTTPS.

• Review proxy or CDN configuration.

• Check for mixed-content warnings.

• Test the custom login path.

• Confirm that cookies work correctly.

• Test backup downloads.

• Verify that scheduled tasks continue to operate.

Theme compatibility

PW Security and Backup performs its main work in the WordPress administration area and is not dependent on a specific public-facing theme.

Most properly developed WordPress themes should not affect the plugin’s security screens, scanning, integrity or backup functions.

A theme can still create a conflict when it:

• Modifies the WordPress login process.

• Adds custom authentication.

• Redirects login requests.

• Loads code inside the administration area.

• Changes REST or AJAX behaviour.

• Produces PHP errors.

• Uses non-standard file locations.

If a problem appears only with one theme, test carefully with a standard WordPress theme in a staging environment.

Plugin compatibility

PW Security and Backup is designed to work alongside ordinary WordPress plugins, but overlapping security or login features can cause conflicts.

Special attention is required when another plugin also provides:

• A custom login URL.

• Login-attempt limits.

• IP blocking.

• CAPTCHA protection.

• Question-and-answer verification.

• Two-factor authentication.

• Firewall rules.

• File scanning.

• File quarantine.

• File-integrity monitoring.

• Backup creation.

• Administrator-login notifications.

• Live traffic recording.

• Cron management.

Two plugins applying different rules to the same login request may lock out an authorised administrator or produce inconsistent records.

Before enabling overlapping controls:

1. Identify which plugin should manage the feature.
2. Review both configurations.
3. Create a current backup.
4. Confirm emergency hosting or FTP access.
5. Test the change in a staging environment when possible.
6. Test administrator login in a private browser window.
7. Avoid closing the existing authenticated session until the new login process succeeds.

Caching and optimisation compatibility

Page caching normally affects public pages more than WordPress administration screens. However, an incorrectly configured caching or optimisation system may interfere with login pages, security tokens, AJAX requests or custom login routes.

The following areas should normally be excluded from inappropriate caching:

• WordPress administration pages.

• WordPress login requests.

• The configured custom login path.

• Authenticated sessions.

• Security-related AJAX requests.

• Pages containing unique login verification fields.

JavaScript delay, combination or minification tools can also affect custom login fields.

If a problem appears after enabling optimisation:

• Clear all cache layers.

• Exclude the login page.

• Exclude authenticated administration requests.

• Disable the relevant optimisation temporarily.

• Reproduce the problem.

• Re-enable settings individually.

CDN, proxy and load-balancer compatibility

A content delivery network, reverse proxy or load balancer may change the IP address that reaches WordPress.

This can affect:

• Failed-login records.

• IP bans.

• IP allowlists.

• IP blocklists.

• Administrator-login notifications.

• Live Traffic.

• Security logs.

If WordPress sees only the proxy address, many visitors may appear to use the same IP address. Blocking that address could affect legitimate users or the entire website.

Forwarded-IP headers should be trusted only when the proxy configuration is known and controlled. Arbitrary visitor-supplied headers must not automatically be accepted as the original client address.

Administrators using Cloudflare, another CDN, a managed firewall or a load balancer should confirm the correct visitor-IP configuration with the hosting or proxy provider.

WooCommerce compatibility

WooCommerce is not required to use PW Security and Backup.

The plugin can be used on an ordinary WordPress website, blog, company website, membership website or WooCommerce store.

On WooCommerce installations, manual full backups may contain:

• Products.

• Customers.

• Orders.

• Billing information.

• Shipping information.

• Store settings.

• Plugin configuration.

• Security records.

• Other information stored in the WordPress database.

WooCommerce websites can contain large databases and many uploaded product images. They may therefore require more disk space, memory and execution time during backup creation.

Restoring an old WooCommerce database may overwrite orders or customer changes created after the backup date. The current administration interface focuses on selected-file recovery and does not provide automatic one-click restoration of the complete website and database.

Complete WooCommerce restoration should be planned carefully and may require hosting tools or professional assistance.

WordPress Multisite compatibility

WordPress Multisite environments have different database, upload, permission and network-administration structures from ordinary single-site installations.

PW Security and Backup should not be assumed to provide complete network-wide protection or recovery unless the installed release specifically documents that capability.

Before using the plugin on Multisite:

• Test it in a non-production network.

• Confirm whether it will be activated per site or network-wide.

• Review database-table coverage.

• Review upload-directory handling.

• Verify administrator permissions.

• Confirm backup contents.

• Test recovery using a disposable copy.

• Maintain an independent full-network backup.

Do not depend on an untested site-level archive as the only recovery method for an entire WordPress Multisite network.

Managed WordPress hosting

Managed WordPress providers may restrict:

• PHP extensions.

• Execution time.

• Memory.

• Direct file access.

• Cron behaviour.

• Backup directories.

• Archive creation.

• File quarantine.

• Security plugins.

• Login URL changes.

• Server configuration files.

Some providers already include their own firewall, malware scanning, login protection or backup systems. These services may complement or overlap with PW Security and Backup.

Review the hosting provider’s rules before enabling overlapping features. A provider may block an operation even when WordPress and PHP otherwise meet the minimum requirements.

Shared-hosting considerations

PW Security and Backup can operate on shared hosting when the environment satisfies the requirements, but server resources may be limited.

Shared-hosting limits can include:

• Low PHP memory.

• Short execution times.

• CPU restrictions.

• Input/output limits.

• Process limits.

• Storage quotas.

• Inode limits.

• Restricted cron execution.

• Disabled PHP extensions.

• Automated termination of long-running requests.

Large scans and backup operations should be performed during a quiet period. If an operation repeatedly fails, contact the hosting provider with the exact error, approximate website size, available disk space and stage at which the process stopped.

Security-software compatibility

A hosting firewall, web application firewall or server-security service may block requests that appear unusual.

Security operations can involve long-running administration requests, ZIP creation, file reads, file moves and repeated AJAX communication. A strict hosting rule may stop one of these operations.

Do not disable a hosting firewall permanently to make an operation work.

Instead:

• Record the exact time of the failure.

• Review available firewall logs.

• Identify the blocked rule.

• Confirm the affected request.

• Apply the narrowest safe exception when appropriate.

• Restore the original protection after testing.

• Contact the hosting provider when the rule cannot be reviewed directly.

Backup compatibility and exclusions

A manual full backup is intended to provide a practical copy of WordPress files and database information. It should not be treated as a guaranteed server-image backup.

Information outside the WordPress installation may not be included, such as:

• Web-server configuration stored outside the website directory.

• Hosting control-panel settings.

• DNS records.

• External email accounts.

• CDN settings.

• External databases.

• Remote object storage.

• Server-level cron entries.

• Operating-system files.

• Provider-managed secrets.

• External service configuration.

Maintain separate records for hosting, DNS, email, CDN and other infrastructure required to rebuild the complete service.

Local development compatibility

The plugin can be evaluated in a local or staging WordPress environment when the normal requirements are met.

Some features may behave differently from production:

• Email delivery may be unavailable.

• Visitor IP addresses may be local or proxied.

• WP-Cron may not run without traffic.

• HTTPS may use a local certificate.

• Server-protection rules may differ.

• Disk and memory limits may be more generous.

• Backup paths may not match production.

• Login redirects may behave differently.

Testing in a local environment is useful, but it does not replace final controlled testing on the real hosting platform.

Installation readiness checklist

Before installing or activating PW Security and Backup, confirm:

• WordPress 5.8 or later is installed.

• PHP 7.4 or later is active.

• WordPress, plugins and themes are maintained.

• A current independent backup exists.

• WordPress administrator access is available.

• Hosting control-panel, FTP or SFTP access is available.

• The uploads directory is writable.

• PHP ZipArchive is enabled if backup features will be used.

• Sufficient free disk space is available.

• PHP memory is appropriate for the website size.

• Execution-time limits can support large operations.

• WP-Cron or a server cron operates correctly.

• WordPress email delivery has been tested.

• HTTPS is enabled.

• Other security plugins have been reviewed for overlapping controls.

• CDN and proxy settings provide the correct visitor IP information.

• Backup archives can be stored outside the hosting account.

Checks after activation

After activating the plugin:

1. Open the Security Center.
2. Review all displayed warnings.
3. Configure only the required features.
4. Confirm that the normal WordPress login still works.
5. Test the custom login path before ending the current session.
6. Review failed-login protection.
7. Confirm IP allowlist and blocklist entries.
8. Test email notifications.
9. Confirm scheduled-check settings.
10. Run a controlled file scan.
11. Review the File Scanner results manually.
12. Create an integrity baseline only after confirming the website is trusted.
13. Create a small test backup.
14. Download and inspect the test archive.
15. Confirm that the server backup location is protected.
16. Store an important recovery copy outside the website server.

Common compatibility questions

Does the plugin require WooCommerce?

No. PW Security and Backup works independently of WooCommerce.

It can also be used on a WooCommerce website, but large stores may require more server memory, disk space and execution time.

Does the plugin require a licence key?

No. The plugin is free and does not require a licence key, PW Feed account or Poyraz Web account for its main features.

Does the plugin require an external security service?

No. Its main scanning, integrity, logging and backup operations are performed within the website’s own WordPress and hosting environment.

Can the plugin work without ZipArchive?

Security features that do not depend on ZIP archives may remain available. Manual full-backup creation and archive-dependent recovery functions require PHP ZipArchive.

Can the plugin work on PHP 7.4?

Yes. PHP 7.4 is the minimum version.

A maintained PHP 8.x release is recommended when it is compatible with the complete WordPress installation.

Is PHP 8.2 supported?

PW Security and Backup is intended to operate on PHP 8.2 when WordPress, the active theme, installed plugins and hosting configuration are also compatible.

Important changes should still be tested before being applied to a live website.

Does the plugin support Nginx?

The plugin can operate in an Nginx-hosted WordPress environment. Nginx does not process .htaccess files, so the administrator or hosting provider must ensure that protected directories and backup archives cannot be accessed publicly.

Does the plugin work with Cloudflare or another CDN?

It can work behind a CDN or reverse proxy, but the original visitor IP configuration must be verified. Incorrect proxy handling can affect login records, IP bans and traffic information.

Can two security plugins be active at the same time?

They can sometimes operate together, but overlapping login, IP, CAPTCHA, firewall, scanning or backup features may conflict.

Each overlapping control should be reviewed and tested carefully.

Does the plugin create automatic backups?

No. Scheduled health and file-integrity checks do not create full backup archives. Full backups are initiated manually in the current version.

Does the plugin provide complete one-click website restoration?

No. The current administration interface supports selected-file comparison and recovery. Complete automatic restoration of all website files and the database is not provided through a one-click control.

Why does a backup fail even when the minimum requirements are met?

A backup can still fail because of insufficient disk space, memory restrictions, execution-time limits, file-permission problems, hosting security rules, very large files or an unavailable ZipArchive extension.

Why does a scheduled check run late?

WordPress WP-Cron normally depends on website activity. A low-traffic website or blocked cron request may delay a scheduled task.

A correctly configured hosting-level cron can provide more consistent execution.

Why are email notifications not received?

WordPress may be unable to deliver email reliably. Check the recipient address, spam folder, hosting mail restrictions, SMTP settings and email-domain configuration.

Why does the recorded IP address belong to a proxy?

A CDN, firewall, reverse proxy or load balancer may be forwarding requests to WordPress. The original visitor-IP configuration must be verified with the hosting or proxy provider.

Compatibility responsibility

PW Security and Backup is designed to operate across ordinary WordPress hosting environments that meet its requirements.

However, WordPress websites are built from many independent components. Compatibility can be influenced by:

• WordPress version.

• PHP version.

• Database software.

• Hosting limits.

• Web-server configuration.

• Theme code.

• Installed plugins.

• Caching systems.

• Security services.

• Proxy configuration.

• File permissions.

• Website size.

• Traffic volume.

• Custom development.

Website administrators should maintain an independent backup, test important changes and retain emergency access to the hosting environment.

No WordPress plugin can guarantee compatibility with every possible combination of server configuration, theme, plugin and custom code.

For installation and configuration instructions, visit the Documentation page. For common problems and practical solutions, visit the Support and Frequently Asked Questions pages.