PW Security and Backup support
Welcome to the PW Security and Backup support page.
This page explains how to request assistance, which information should be included in a support request and what precautions should be taken before sharing website or security-related details.
PW Security and Backup brings login protection, WordPress security hardening, suspicious-code scanning, SHA-256 file-integrity monitoring, manual full backups, selected-file recovery, live traffic monitoring, security analysis, notifications and activity logs together in one WordPress administration panel.
The plugin operates within your own WordPress installation and hosting environment. It does not require a licence key, remote security account or external scanning service. It does not send telemetry, scan results, traffic records, credentials or backup contents to PW Feed, Poyraz Web or another external service.
For this reason, support representatives cannot automatically view your website, plugin configuration, security findings, logs or backup archives. You must provide the relevant non-sensitive information when requesting assistance.
Before requesting support
Many WordPress problems can be identified more quickly by completing a few basic checks before opening a support request.
First, confirm that your website meets the plugin’s minimum requirements:
• WordPress 5.8 or later.
• PHP 7.4 or later.
• A writable WordPress uploads directory.
• Sufficient server storage for backup operations.
• PHP ZipArchive support for ZIP backup creation.
• A working WordPress email system for notifications.
• Administrator permission to configure the plugin.
A current PHP version and HTTPS connection are recommended for improved security, performance and compatibility.
Before reporting a problem, also complete the following checks where possible:
- Confirm that WordPress is working normally.
- Confirm that PW Security and Backup is active.
- Review the Security Center for warnings.
- Record the exact error message.
- Record the operation performed immediately before the problem occurred.
- Check whether WordPress, the active theme or another plugin was recently updated.
- Confirm that sufficient disk space is available.
- Review relevant WordPress and hosting error logs.
- Test whether the problem can be reproduced.
- Create a current backup before changing important settings.
Do not repeatedly run a failed backup, file-restoration or quarantine operation without first checking the reported error. Repeated attempts may consume server resources or make the original problem more difficult to investigate.
Topics covered by support
Support can provide guidance for the plugin’s documented features, including:
• Plugin installation and activation.
• Security Center information.
• Core Settings.
• Notification configuration.
• Scheduled health and integrity checks.
• Custom WordPress login paths.
• Standard login-address protection.
• Additional security-password configuration.
• Failed-login limits.
• Temporary IP bans.
• IP allowlists and blocklists.
• Question-and-answer verification.
• WordPress security-hardening profiles.
• Suspicious-code scanning.
• Ignored scan findings.
• File quarantine.
• SHA-256 file-integrity monitoring.
• Integrity baselines.
• Manual full backups.
• Backup archive downloads.
• Backup file comparisons.
• Selected-file recovery.
• Live traffic monitoring.
• Security Analysis reports.
• Security logs and CSV exports.
Support can explain how these features are intended to work and help identify common configuration, compatibility and server-related problems.
Matters outside standard plugin support
PW Security and Backup provides security, monitoring and recovery tools, but it does not replace every hosting, development or professional incident-response service.
Standard plugin support does not include:
• General WordPress website development.
• Repairing unrelated theme or plugin code.
• Hosting-account administration.
• Server migration.
• DNS or domain configuration.
• Complete malware removal services.
• Professional penetration testing.
• Legal or regulatory compliance advice.
• Complete website restoration performed on behalf of the administrator.
• Recovery of data that does not exist in an available backup.
• Repairing damaged hosting hardware or storage.
• Guaranteeing the security of a website.
• Guaranteeing compatibility with every WordPress plugin, theme, proxy or hosting configuration.
The current plugin does not provide automatic one-click restoration of the complete website and database. It provides manual full-backup creation, backup comparison and selected-file recovery.
Complete website or database restoration may require hosting backup tools, database-management software or professional technical assistance.
Information to include in a support request
A clear and complete request makes it easier to understand the problem.
Include the following non-sensitive information:
• WordPress version.
• PHP version.
• PW Security and Backup version.
• Website type, such as blog, business website or WooCommerce store.
• Name of the relevant plugin screen.
• Exact error message.
• Date and approximate time of the problem.
• Action performed before the problem appeared.
• Whether the problem occurs every time or intermittently.
• Whether WordPress, a theme or another plugin was recently updated.
• Whether the website uses a proxy, content delivery network or load balancer.
• Whether the problem continues after basic compatibility checks.
• Relevant screenshots with sensitive information removed.
Describe the expected result and the result you actually received.
For example, instead of writing “The backup does not work,” provide more useful information such as:
“After selecting Create Full Backup, the process stops at 42% and displays a ZipArchive error. The website uses WordPress 6.x and PHP 8.x. There is sufficient disk space, and the problem occurs every time.”
Do not estimate or rewrite the displayed error message from memory. Copy the exact message whenever possible.
Information that must never be shared publicly
Never include confidential access information in a public support request, screenshot, forum message or public file link.
Do not publicly share:
• WordPress administrator passwords.
• The additional security password.
• Hosting-control-panel credentials.
• FTP or SFTP credentials.
• Database usernames or passwords.
• SMTP passwords.
• Private keys.
• Secret API tokens.
• Authentication cookies.
• Complete wp-config.php contents.
• Complete backup archives.
• Unredacted security logs containing personal information.
• Customer or order information.
• Private IP allowlists.
• A secret custom login address when disclosure is unnecessary.
• Personally identifiable visitor information.
A full backup may contain the website database, user information, configuration values, email addresses, order records and other sensitive information. Do not attach a complete backup archive to an ordinary support request.
If a screenshot contains sensitive information, remove or cover that information before sharing it. Cropping an image may be safer than applying a transparent or reversible visual effect.
Installation or activation problems
If the plugin cannot be installed, confirm that the uploaded file is a valid WordPress plugin ZIP package.
Common installation problems may be caused by:
• Upload-size limits.
• Incomplete ZIP downloads.
• Incorrect directory structures.
• Insufficient file permissions.
• Hosting security restrictions.
• Unsupported PHP versions.
• Existing plugin directories with the same name.
If WordPress reports that the destination folder already exists, check whether an older or incomplete copy of the plugin remains in the /wp-content/plugins/ directory.
Do not delete the existing directory until its settings, custom changes and recovery implications have been reviewed. Create a backup before replacing plugin files manually.
If activation produces a fatal error, record the complete error and relevant file path. Hosting or WordPress debug logs may provide additional information, but remove passwords, database details and private paths before sharing them publicly.
Login-access problems
Custom login paths, standard-login restrictions, IP rules and additional security-password settings directly affect access to the WordPress administration area.
Before enabling these controls:
- Record the new login address securely.
- Keep the current administrator session open.
- Test the new address in a private browser window.
- Confirm that an authorised administrator can sign in.
- Keep hosting file-manager or FTP access available.
If the administration area becomes inaccessible, use the hosting file manager or FTP to rename the plugin directory temporarily.
Original directory:
/wp-content/plugins/pw-security-and-backup/
Example temporary name:
/wp-content/plugins/pw-security-and-backup-disabled/
WordPress will stop loading the plugin from its expected directory. After access is restored, investigate the relevant configuration before returning the directory to its original name and reactivating the plugin.
Do not leave the plugin disabled longer than necessary because its active protections and scheduled tasks will not operate while it is inactive.
Incorrect IP addresses
When a website uses a reverse proxy, content delivery network or load balancer, WordPress may receive the intermediary system’s address instead of the visitor’s original IP address.
This can affect:
• Failed-login records.
• Automatic IP bans.
• IP allowlists.
• IP blocklists.
• Live traffic records.
• Security logs.
Do not add an unfamiliar IP address to the blocklist until its source has been identified. It may belong to the website administrator, hosting provider, proxy, uptime service or another essential system.
Proxy-related IP configuration may require assistance from the hosting provider. Trusting unverified forwarded-IP headers can also create security risks.
Security-hardening problems
Security hardening changes the way certain WordPress or server functions operate. A restrictive setting may affect another plugin, theme, mobile application or external integration.
If a problem appears after applying a protection profile:
- Record which profile or rule was applied.
- Test the affected website function.
- Open Changes and Rollback.
- Reverse the relevant supported change when appropriate.
- Clear applicable website and server caches.
- Test the website again.
- Review whether an integration depends on the disabled function.
For example, XML-RPC protection may affect applications or services that use XML-RPC. REST API restrictions may affect a theme, plugin, headless application or external service.
Standard Protection is generally the most appropriate starting point for an ordinary WordPress website. Maximum Protection should be tested carefully before it is used on an important live website.
Suspicious-code scan questions
A File Scanner finding does not automatically prove that the website contains malware.
Legitimate themes, plugins and custom code may use functions or patterns that are also found in unsafe software. Each finding must be evaluated in context.
When requesting help with a scanner finding, provide:
• The risk level.
• The file path.
• The finding description.
• The relevant code line or a limited code excerpt.
• The source of the file, if known.
• The file’s modification date.
• Details of recent software updates.
Do not publish an entire private or commercial source-code file. Share only the minimum information required to understand the reported pattern.
Before deleting or quarantining a file, compare it with a clean original package from a trusted source. Quarantining an essential WordPress, theme or plugin file may cause a fatal error or disable website functionality.
If malicious code is confirmed, removing one reported file may not resolve the incident. The attacker’s entry point, affected accounts, other modified files, database content, scheduled tasks and server logs may also require investigation.
File-integrity questions
File Integrity compares the current website with a previously created trusted baseline.
Modified, new or deleted files do not automatically indicate an attack. Legitimate changes can result from:
• WordPress updates.
• Theme or plugin updates.
• Cache generation.
• Image optimisation.
• Backup operations.
• Approved development work.
• Hosting maintenance.
When requesting assistance, provide the reported change type, relevant file path and information about recent authorised changes.
Do not create a new baseline simply to remove unexplained warnings. Investigate unexpected changes first. Creating a new baseline before checking them may cause an unauthorised file to become part of the trusted reference.
A new baseline is appropriate only after the current website has been reviewed and accepted as clean and trusted.
Backup-creation problems
Full backup creation is manual in the current plugin version. Scheduled health and integrity checks do not create automatic backup archives.
Before starting a backup, confirm that:
• PHP ZipArchive is enabled.
• The uploads directory is writable.
• Sufficient free disk space is available.
• PHP memory and execution limits are adequate.
• The website is not running a major import or update.
• The browser page can remain open.
Common causes of backup failure include unavailable ZipArchive support, insufficient disk space, file-permission problems, server timeouts, memory limits and hosting security restrictions.
When reporting a backup problem, provide the displayed error, the approximate website size, available disk space and the stage at which the process stopped.
Do not attach the resulting backup archive to a public support request.
Important backups should be downloaded and stored securely outside the website’s hosting account. A backup stored only on the affected server may become unavailable during a hosting failure, account suspension, storage problem or serious compromise.
Selected-file recovery problems
Selected-file recovery replaces a current file with the corresponding version stored in a chosen backup.
Before using recovery, confirm that:
• The backup belongs to the current website.
• The required file exists in the backup.
• The backup contains the correct file version.
• The file is compatible with the current software version.
• A current recovery copy has been created.
• Hosting file-manager or FTP access is available.
Restoring an older plugin or theme file into a newer version may create compatibility or security problems.
The comparison screen may also identify current files that do not exist in the selected backup. This difference does not prove that the current file is malicious. It may have been created legitimately after the backup date.
Deletion is permanent and should be performed only after the file’s purpose has been confirmed.
Email-notification problems
PW Security and Backup uses the WordPress email system for enabled notifications.
Depending on the selected settings, notifications may be generated for events such as:
• File changes.
• Administrator logins.
• IP bans.
If notifications are not received:
- Confirm the configured recipient address.
- Check the spam or junk folder.
- Confirm that WordPress can send other email messages.
- Review hosting mail restrictions.
- Check the SMTP plugin configuration, if one is used.
- Review available WordPress and mail-delivery logs.
- Send a test email through an appropriate WordPress mail tool.
The plugin cannot guarantee delivery after a notification has been passed to the WordPress mail system. Delivery may be affected by hosting limits, SMTP authentication, DNS records, spam filters or recipient-server policies.
Never include an SMTP password in a public support request.
Scheduled checks running late
Scheduled health and file-integrity checks normally depend on WordPress WP-Cron.
WP-Cron is triggered by website activity. A scheduled event on a low-traffic website may therefore run later than its configured time.
Check whether:
• WP-Cron is disabled.
• The website receives regular visits.
• A caching or security system blocks cron requests.
• The hosting provider restricts background processes.
• A real server cron is configured correctly.
A hosting-level cron can provide more consistent execution when supported by the hosting provider.
Remember that scheduled health and integrity checks are separate from manual full-backup creation.
Live traffic and database growth
Live Traffic is disabled by default and should be enabled only when its information is needed.
Traffic recording may store request paths, IP addresses, HTTP methods, referrers and user-agent information inside the WordPress database.
On high-traffic websites, recording requests can increase database activity and storage use. If database growth becomes a concern:
• Review whether Live Traffic is still required.
• Clear unnecessary records from the plugin screen.
• Check log-retention settings.
• Review website traffic and bot activity.
• Confirm that scheduled maintenance tasks operate normally.
• Consult the hosting provider about database size or performance limits.
Before clearing records related to a security investigation, consider whether an authorised and protected copy should be preserved.
Plugin, theme or hosting conflicts
WordPress websites operate through many connected components. A problem visible inside PW Security and Backup may originate from another plugin, the active theme, server permissions, caching, a proxy or hosting restrictions.
Compatibility testing should be performed carefully, preferably in a staging environment.
A controlled test may include:
- Creating a current backup.
- Reproducing the problem.
- Recording the exact result.
- Temporarily disabling relevant caching.
- Testing with other security plugins disabled.
- Checking for overlapping login or IP rules.
- Testing with a standard WordPress theme when appropriate.
- Re-enabling each component after testing.
Do not disable essential security, payment or business functions on a live website without understanding the effects.
If the issue occurs only when another specific plugin is active, include that plugin’s name and version in the support request.
Problems after an update
After updating PW Security and Backup:
• Confirm that the plugin remains active.
• Open the Security Center.
• Review current warnings.
• Test the WordPress login process.
• Check notification settings.
• Confirm scheduled-check configuration.
• Review file-integrity results.
• Create a backup before making additional changes.
A normal update should preserve settings and stored information. Do not install an older plugin version over a newer version unless there is a specific recovery reason and the compatibility effects are understood.
If an update appears incomplete, do not repeatedly overwrite files without first checking the installed version, directory structure and WordPress error logs.
Urgent security incidents
A website may require urgent professional assistance when:
• Unknown administrator accounts appear.
• Malicious code is confirmed.
• Files return after being removed.
• Visitors are redirected to unknown websites.
• Search results display spam pages.
• Database content has been altered.
• Payment or customer information may have been exposed.
• The website distributes malicious downloads.
• The source of the compromise cannot be identified.
• The administrator cannot safely regain control.
During a serious incident:
- Preserve relevant evidence and logs.
- Change passwords from a trusted device.
- Review administrator accounts.
- Contact the hosting provider.
- Protect customer and user information.
- Avoid destroying evidence through uncontrolled file deletion.
- Use a verified clean backup only after understanding the compromise.
- Consider professional incident-response assistance.
PW Security and Backup can provide useful monitoring and recovery information, but a serious compromise may require server-level investigation beyond the plugin’s scope.
Privacy and local information
PW Security and Backup does not send telemetry, scanner findings, traffic records, login information, credentials or backup contents to PW Feed, Poyraz Web or another external service.
Depending on the enabled features, the local WordPress installation may store:
• IP addresses.
• WordPress usernames.
• Login-attempt information.
• Request paths.
• Referrers and user-agent information.
• Security events.
• File-integrity signatures.
• Scan findings.
• Quarantine records.
• Backup archives.
Website administrators are responsible for controlling access, selecting appropriate retention periods and following applicable privacy and data-protection requirements.
Support staff cannot automatically access this locally stored information.
Submitting an effective support request
Use a clear subject that identifies the affected feature.
Suitable examples include:
• Backup stops during ZIP creation.
• Custom login path returns a 404 response.
• File-integrity check does not complete.
• WordPress notification email is not delivered.
• Incorrect visitor IP appears in login records.
• Scanner reports a possible suspicious PHP file.
In the message, explain:
- What you attempted to do.
- What you expected to happen.
- What actually happened.
- The exact error displayed.
- Whether the issue can be reproduced.
- What troubleshooting steps have already been completed.
- Which recent website changes may be related.
One support request should focus on one clearly defined problem whenever possible. Separating unrelated issues helps prevent important information from being overlooked.
Support-request template
You can use the following structure when requesting assistance:
Plugin version:
WordPress version:
PHP version:
Website type:
Relevant plugin screen:
Problem summary:
Expected result:
Actual result:
Exact error message:
Steps required to reproduce the problem:
Recent WordPress, plugin, theme or server changes:
Troubleshooting already completed:
Proxy, CDN or load balancer in use:
Additional non-sensitive information:
Confirm that all passwords, credentials, personal information and private security details have been removed before submitting the request.
Using PW Security and Backup safely
PW Security and Backup is designed to make important WordPress security and recovery operations easier to understand and manage.
The most effective approach combines the plugin with:
• Secure and maintained hosting.
• Current WordPress, theme and plugin versions.
• Strong unique passwords.
• Multi-factor authentication where available.
• Carefully limited administrator access.
• Regular security reviews.
• Verified backups stored outside the website server.
• A tested emergency-recovery procedure.
• Professional assistance when a serious compromise is suspected.
For complete installation and configuration instructions, visit the Documentation page. For concise answers about individual features, limitations and common problems, visit the Frequently Asked Questions page.