wpwhitesecurity / wp-security-audit-log Goto Github PK

We need to update the text of Alert 1003 in the Enable/Disable alerts section to the following:

Login failed / non existing user

By default the Refresh Audit View option is set to automatic. Though it is impossible to switch if off, i.e. once you try and save the settings the option is reverted back to automatic.

Please also update the text of this setting with the below:

Option name: Refresh Audit Log Viewer
Option-value-1: Automatic — Refresh Audit Log Viewer as soon as there are new alerts.
Option-value-2: Manual — Refresh Audit Log Viewer only when the page is reloaded.

Excluded custom fields should be listed one under the other in the settings page. At the moment they are being listed one next to each other. Although this is the WordPress standard it is very difficult to find a particular one should there be a lot.

Is it possible to also sort them out in alphabetical order?

There's a few issues with WP-Security-Audit-Log when you have a larger audit table and the plugin tries to a do a few things. Queries like:

SELECT * FROM `wp_wsal_occurrences`
            WHERE alert_id = 1002 AND site_id = 1
                AND (created_on BETWEEN 1405296000 AND 1405382399)
                AND id IN (
                    SELECT occurrence_id as id
                    FROM `wp_wsal_metadata`
                    WHERE (name = "ClientIP" AND value = '\"66.221.34.63\"')
                       OR (name = "Username" AND value = '\"Dana41Zoajez\"')
                    GROUP BY occurrence_id
                    HAVING COUNT(*) = 2
                );

and simply:

SELECT * FROM wp_wsal_metadata WHERE occurrence_id = 18475

are both poorly indexed. In particular wp_wsal_metadata.name is a TEXT column type, where it could really be a varchar() and have an index it seems.

I've added these two indexes (below). It might be worth adding these to your standard distro:

ALTER TABLE wp_wsal_occurrences ADD INDEX `alert_site_created` (`site_id`, `alert_id`, `created_on`);
ALTER TABLE wp_wsal_metadata ADD INDEX (`occurrence_id`);

@carmelopreeostudios on a WP Engine install the Audit Log Viewer is not working, i.e. the plugin logs alerts and work normally though when users access the Audit Log Viewer they get a blank page.

WP Engine support said the following "an error 500 (trying to make the server do something that isn't allowed, essentially). I've traced it back to the Render() method for the AbstractClass."

One user gave us access to a staging website of his to test the installation. Will send you the credentials via email so we can test this and fix it for 1.5.2.

The plugin settings in the WordPress option table, such as "wsal-pruning-date" are not generated during install but only generated once the user accesses the plugin's settings the first time. Such settings should be created upon install, hence during an activation the plugin should:

1. Check if there are the settings specified already
2. If they are specified it should check that ALL settings are there. If any are missing they should be populated with the default values
3. If it finds no settings at all it should generate them with the default settings the plugin is shipped with.

@carmelopreeostudios when the plugin is generating alert 1002 the below is being reported in the debug.log:

 [18-Feb-2015 20:53:45 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in C:\wamp\htdocswp\wp-includes\functions.php on line 3495

Sending you the complete log file and stack trace via email.

It seems that the new settings table (wp_wsal_options) is being called during installation / activation before the table itself is created. In fact upon installing the plugin the following errors are reported in the debug log file:

 [05-Mar-2015 20:16:26 UTC] WordPress database error Table 'wpdb.wp_wsal_options' doesn't exist for query SELECT * FROM wp_wsal_options WHERE option_name = 'wsal-dev-options' made by activate_plugin, include_once('C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php'), WSAL_SensorManager->HookEvents, WSAL_Sensors_PhpErrors->HookEvents, WSAL_Settings->IsPhpErrorLoggingEnabled, WSAL_Settings->IsDevOptionEnabled, WpSecurityAuditLog->GetGlobalOption, WSAL_DB_Option->GetOptionValue, WSAL_DB_Option->GetNamedOption, WSAL_DB_ActiveRecord->Load

 [05-Mar-2015 20:16:26 UTC] WordPress database error Table 'wpdb.wp_wsal_options' doesn't exist for query SELECT * FROM wp_wsal_options WHERE option_name = 'wsal-version' made by activate_plugin, do_action('activate_wp-security-audit-log/wp-security-audit-log.php'), call_user_func_array, WpSecurityAuditLog->Install, WpSecurityAuditLog->GetOldVersion, WpSecurityAuditLog->GetGlobalOption, WSAL_DB_Option->GetOptionValue, WSAL_DB_Option->GetNamedOption, WSAL_DB_ActiveRecord->Load

As explained over email there are some specific scenarios where the IP address is not being populated in the alerts, instead "unkown" is shown.

Please advise what information you need from the users to allow us to troubleshoot this issue.

Since the database change in version 1.5 (created a new settings table for the plugin) the license activations of the premium addons listed below is not working.

It is not working as the licensing module should be writing to the settings table which now has been moved. I will send you an email with a test license so the issue can be reproduced and fixed for 1.5.1.

When I enable the hide option the following errors are generated in the debug log, even though the option is working:

 [18-Jan-2015 10:33:29 UTC] PHP Notice:  Undefined index: EnableProxyIpCapture in C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php on line 55

 [18-Jan-2015 10:33:29 UTC] PHP Stack trace:

 [18-Jan-2015 10:33:29 UTC] PHP   1. {main}() C:\wamp\htdocswp\wp-admin\admin.php:0

 [18-Jan-2015 10:33:29 UTC] PHP   2. do_action() C:\wamp\htdocswp\wp-admin\admin.php:212

 [18-Jan-2015 10:33:29 UTC] PHP   3. call_user_func_array() C:\wamp\htdocswp\wp-includes\plugin.php:496

 [18-Jan-2015 10:33:29 UTC] PHP   4. WSAL_ViewManager->RenderViewBody() C:\wamp\htdocswp\wp-includes\plugin.php:496

 [18-Jan-2015 10:33:29 UTC] PHP   5. WSAL_AbstractView->RenderContent() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:199

 [18-Jan-2015 10:33:29 UTC] PHP   6. WSAL_Views_Settings->Render() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\AbstractView.php:128

 [18-Jan-2015 10:33:29 UTC] PHP   7. WSAL_Views_Settings->Save() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php:86

 [18-Jan-2015 10:33:29 UTC] PHP Notice:  Undefined index: EnableIpFiltering in C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php on line 56

 [18-Jan-2015 10:33:29 UTC] PHP Stack trace:

 [18-Jan-2015 10:33:29 UTC] PHP   1. {main}() C:\wamp\htdocswp\wp-admin\admin.php:0

 [18-Jan-2015 10:33:29 UTC] PHP   2. do_action() C:\wamp\htdocswp\wp-admin\admin.php:212

 [18-Jan-2015 10:33:29 UTC] PHP   3. call_user_func_array() C:\wamp\htdocswp\wp-includes\plugin.php:496

 [18-Jan-2015 10:33:29 UTC] PHP   4. WSAL_ViewManager->RenderViewBody() C:\wamp\htdocswp\wp-includes\plugin.php:496

 [18-Jan-2015 10:33:29 UTC] PHP   5. WSAL_AbstractView->RenderContent() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:199

 [18-Jan-2015 10:33:29 UTC] PHP   6. WSAL_Views_Settings->Render() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\AbstractView.php:128

 [18-Jan-2015 10:33:29 UTC] PHP   7. WSAL_Views_Settings->Save() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php:86

Attached is also a screenshot of the error.

When I login to the website which has the Rublon plugin intsalled, Alert 1000 (Login) is not being generated. Below is an abstract from the PHP error log file:

PHP Fatal error:  Uncaught exception 'Exception' with message 'Alert with code "1000" has not be registered.' in /wp-content/plugins/wp-security-audit-log/classes/AlertManager.php:111
Stack trace:
#0 /wp-content/plugins/wp-security-audit-log/classes/AlertManager.php(108): WSAL_AlertManager->_CommitItem(1000, Array, NULL, false)
#1 /wp-content/plugins/wp-security-audit-log/classes/AlertManager.php(122): WSAL_AlertManager->_CommitItem(1000, Array, NULL)
#2 [internal function]: WSAL_AlertManager->_CommitPipeline('')
#3 /wp-includes/plugin.php(505): call_user_func_array(Array, Array)
#4 /wp-includes/load.php(613): do_action('shutdown')
#5 [internal function]: shutdown_action_hook()
#6 {main} thrown in /wp-content/plugins/wp-security-audit-log/classes/AlertManager.php on line 111

In multisite environment, the new Extension notification only shows up in the Audit Log viewer which is on the site (e.g. site1.wpwhitehats.com) and not the network based Audit Log viewer (wpwhitehats.com).

Upon installing the plugin a PHP Fatal error for alert code 5001 is always generated. As a matter of fact when the plugin itself is activated the alert "5001 plugin is activated" is not generated. I presume we can fix this by "improving" the order of when the sensors / alerts are registered prior to activating the plugin.

@carmelopreeostudios

It seems we left the debug logging enabled in the latest version of the plugin (1.5.1) - https://wordpress.org/support/topic/plugin-is-changing-error-log-location?replies=3

I double checked the code and it is true. Can we remove the logging from the master branch (no need to do a new branch just for this) so I can upload 1.5.2 with a fix?

Pruning is still not working and can confirm that the problem is related to the way the "pruning options" are being used.

In fact when one of the options is disabled, the pruning works fine. In this case it is easier to simply completely remove the option to limit number of alerts by number and leave only the option to limit the number of alerts by time.

@carmelopreeostudios When there are multiple plugins that need to be upgraded and they are upgraded all at once (plugins screen -> tick box next to each -> drop down menu "update") no alert is being generated.

In such case we should generate an alert for each upgrade.

The sorting options of the alerts in the Audit log viewer are not working. A user should be able to sort alerts by time / date, Alert ID, Username and IP address.

Scenario: user "admin" and role "administrator" are excluded.

When "admin" with administrator role changes the role of another user from administrator to author, the plugin still creates Alert 4002 (User role change) even though the user doing the change is excluded from monitoring.

This could be related to the fact that the author role is being used in the alert.

@markdelf @carmelopreeostudios

I tested the plugin hotfix (#51) and can confirm the below alerts are not working:

1. Content alerts (anything related to blog posts, pages and custom posts) are not working.
2. move widget between containers, alert 2045
3. move widget in same container, alert 2071
4. user deletes category, alert 2024
5. user creates category, alert 2023

The new Extension notification in the Audit Log viewer is working when doing a brand new install but it is not working upon upgrade.

I can confirm that the entry in the usermeta is not generated neither upon upgrade.

For more information please refer to this ticket:

https://wordpress.org/support/topic/syntax-error-d-not-replaced?replies=4#post-6188686

When someone accesses the below URL from a website it triggers a 1001 alert with unknown username, even though there never was a session:

website/wp-login.php?action=logout

More details in this ticket: https://wordpress.org/support/topic/too-many-records-with-1001-code?replies=2

As discussed yesterday we should bypass this by checking the User ID with wordpress prior to issuing the alert. If user ID is 0 do not issue such alert.

The error is:

 WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%d ORDER BY created_on ASC LIMIT  1470' at line 1 for query SELECT * FROM x_wsal_occurrences WHERE created_on < %d ORDER BY created_on ASC LIMIT  1470 made by do_action_ref_array, call_user_func_array, WpSecurityAuditLog->CleanUp, call_user_func, WSAL_Loggers_Database->CleanUp, WSAL_DB_OccurrenceQuery->Delete

More info in this ticket:

https://wordpress.org/support/topic/syntax-error-d-not-replaced?replies=6#post-6226629

Note: As highlighted in the ticket I am unable to reproduce any of the issues in our test scenarios hence if they click something then let's fix them, if not let's wait for the user to get back to us.

explaining scenario first:

Main network is installed on wpwhitehats.com
One of the sites on the network is site1.wpwhitehats.com

when a site1 user logs in to the site everything is ok. When the SUPER ADMiN (super admin typically has access to all the multisite network, including sub sites etc) logs in to the sub site (site1.wpwhitehats.com) because the super administrator does not have a specific role on that specific site, the role is being reported as unkown.

In multisite can we make a check and if the user is superadmin always report that role irrelevant of on which site he is logged in?

Related: https://app.asana.com/0/11607779860336/24418932343631

When the plugin is uninstalled, it should remove all the relevant tables as well as settings (wp-options), as clearly specified by the standard wordpress uninstallation page.

Site administrators cannot dismiss the new extension notification. If they the browser becomes unresponsive (in FF).

The plugin hotfix cannot be activated. Upon trying to activate it the following error is being generated:

 [18-Mar-2015 21:45:32 UTC] PHP Fatal error:  Call to a member function CurrentUserCan() on a non-object in C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php on line 7

 [18-Mar-2015 21:45:32 UTC] PHP Stack trace:

 [18-Mar-2015 21:45:32 UTC] PHP   1. {main}() C:\wamp\htdocswp\wp-admin\plugins.php:0

 [18-Mar-2015 21:45:32 UTC] PHP   2. activate_plugin() C:\wamp\htdocswp\wp-admin\plugins.php:40

 [18-Mar-2015 21:45:32 UTC] PHP   3. include_once() C:\wamp\htdocswp\wp-admin\includes\plugin.php:542

 [18-Mar-2015 21:45:32 UTC] PHP   4. WpSecurityAuditLog::GetInstance() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:583

 [18-Mar-2015 21:45:32 UTC] PHP   5. WpSecurityAuditLog->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:111

 [18-Mar-2015 21:45:32 UTC] PHP   6. WSAL_ViewManager->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:133

 [18-Mar-2015 21:45:32 UTC] PHP   7. WSAL_ViewManager->AddFromFile() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:20

 [18-Mar-2015 21:45:32 UTC] PHP   8. WSAL_ViewManager->AddFromClass() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:41

 [18-Mar-2015 21:45:32 UTC] PHP   9. WSAL_Views_Settings->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:49

 [18-Mar-2015 21:45:34 UTC] PHP Fatal error:  Call to a member function CurrentUserCan() on a non-object in C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php on line 7

 [18-Mar-2015 21:45:34 UTC] PHP Stack trace:

 [18-Mar-2015 21:45:34 UTC] PHP   1. {main}() C:\wamp\htdocswp\wp-admin\plugins.php:0

 [18-Mar-2015 21:45:34 UTC] PHP   2. plugin_sandbox_scrape() C:\wamp\htdocswp\wp-admin\plugins.php:153

 [18-Mar-2015 21:45:34 UTC] PHP   3. include() C:\wamp\htdocswp\wp-admin\plugins.php:151

 [18-Mar-2015 21:45:34 UTC] PHP   4. WpSecurityAuditLog::GetInstance() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:583

 [18-Mar-2015 21:45:34 UTC] PHP   5. WpSecurityAuditLog->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:111

 [18-Mar-2015 21:45:34 UTC] PHP   6. WSAL_ViewManager->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:133

 [18-Mar-2015 21:45:34 UTC] PHP   7. WSAL_ViewManager->AddFromFile() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:20

 [18-Mar-2015 21:45:34 UTC] PHP   8. WSAL_ViewManager->AddFromClass() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:41

 [18-Mar-2015 21:45:34 UTC] PHP   9. WSAL_Views_Settings->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:49

 [18-Mar-2015 21:45:34 UTC] PHP Fatal error:  Call to a member function CurrentUserCan() on a non-object in C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\Views\Settings.php on line 7

 [18-Mar-2015 21:45:34 UTC] PHP Stack trace:

 [18-Mar-2015 21:45:34 UTC] PHP   1. {main}() C:\wamp\htdocswp\wp-admin\plugins.php:0

 [18-Mar-2015 21:45:34 UTC] PHP   2. plugin_sandbox_scrape() C:\wamp\htdocswp\wp-admin\plugins.php:153

 [18-Mar-2015 21:45:34 UTC] PHP   3. include() C:\wamp\htdocswp\wp-admin\plugins.php:151

 [18-Mar-2015 21:45:34 UTC] PHP   4. WpSecurityAuditLog::GetInstance() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:583

 [18-Mar-2015 21:45:34 UTC] PHP   5. WpSecurityAuditLog->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:111

 [18-Mar-2015 21:45:34 UTC] PHP   6. WSAL_ViewManager->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\wp-security-audit-log.php:133

 [18-Mar-2015 21:45:34 UTC] PHP   7. WSAL_ViewManager->AddFromFile() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:20

 [18-Mar-2015 21:45:34 UTC] PHP   8. WSAL_ViewManager->AddFromClass() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:41

 [18-Mar-2015 21:45:34 UTC] PHP   9. WSAL_Views_Settings->__construct() C:\wamp\htdocswp\wp-content\plugins\wp-security-audit-log\classes\ViewManager.php:49

Upon activating the latest version of the plugin the following error is generated in debug.log:

 [18-Jan-2015 09:48:17 UTC] WordPress database error Duplicate key name 'site_alert_created' for query ALTER TABLE wp_wsal_occurrences ADD KEY site_alert_created (site_id,alert_id,created_on) made by activate_plugin, do_action('activate_wp-security-audit-log/wp-security-audit-log.php'), call_user_func_array, WpSecurityAuditLog->Install, WSAL_DB_ActiveRecord::InstallAll, WSAL_DB_ActiveRecord->Install, dbDelta

In a multisite installation the minimum width of the "site" column is too wide and the alerts look crammed, as per the highlighted screenshot.

We should have the width of the site column dynamic with the minimum set to very little.

I installed plugin easy digital downloads (https://wordpress.org/plugins/easy-digital-downloads/)

2 alerts were created (so far this is not an issue even though it could be fine tuned)

• 5010 plugin created table
• 5016 unknown component created table

Upon uninstalling the plugin, even though the table it creates is deleted by the plugin there were no alerts generated.

Notification Extension notice should only show up on the Audit Log page.

Branch 1.4.0:

If there are 10+ Alerts with code 1003 (failed logins for non existing users from a specific host), if there are failed logins for existing users from the same host the plugin is not generating Alert 1002. The logic should be as follows:

Plugin detects failed alert
Plugin checks username in failed login
If username exists it generates Alert 1002 and reports username
If username does not exist it generates Alert 1003

In case there are 10+ 1003 alerts the plugin should still keep check the usernames of failed logins from the same host. If the user is non existing, the plugin should ignore the request, as is now. Though if the username exists it should generate or update Alert 1002. If there are 10+ instances of Alert 1002 for that specific username and host then the request should be ignored.

The only situation where the plugin should ignore failed logins from a specific host when there are 10+ 1003 alerts and 10+ 1002 alerts for each existing username on WordPress.

@carmelopreeostudios as explained in the email; failed logins of non existing users from the same source are not being grouped, instead an alert 1002 is being generated for each failed login.

The source IP is not being reported when the Proxy option is switched on, even though the reverse proxy is forwarding the IP in the Forwarded_For header:

 X-Forwarded-For: 192.168.2.124:49297

Normal scenario: when user "admin" creates a new username "kypri" with the role of "author" the following alert is created:

ID: 4001
User: admin
message: Created a new user kypri with the role of administrator

Though if the "admin" user is excluded from monitoring, rather than no alerts the following alert is being reported:

ID: 4002
User: admin
message: Changed the role of user kypry from to administrator

In such case no alerts should be created. This issue is related to the previous 4002 issue because of the way WordPress works, hence most probably when #41 is fixed this will be fixed as well.

In a multisite environment alert 1003 is not "working correctly". This is what is happening:

Setup: 3 websites on a multisite:

site1.multiwp.com
site2.multiwp.com
site3.multiwp.com

There are a number failed logins for a non existing user from host 192.168.2.127 hence Alert 1003 is generated reporting the site name, as per the below screenshot:

If failed logins for a non existing user are generated from the same host but on a different site, e.g. site2.multiwp.com the date of the same Alert 1003 is being updated. In the case of multisite we need to keep track of failed logins specifically for each site on the network hence in the above case a new Alert 1003 should have been generated for site2.

Issue reported here: https://wordpress.org/support/topic/refresh-audit-view-refresh-audit-log-viewer?replies=2#post-6708853

In the plugin settings there are the following 2 options which have the same effect.

Refresh Audit View

Refresh Audit Log Viewer

The option Refresh Audit View should be remove as it is duplicate.

remove the [] from the Excluded Objects in the below message, hence the text should be:

"....from the Excluded Objects tab in..."

The new input fields in the settings, mainly:

Excluded Users
Excluded Roles
Excluded Custom Fields

Such behaviour can potentially lead to a lot of problems. In the case of Excluded Users and Excluded Roles we should ONLY allow existing roles and users. Therefore if the user enters a non existing user or role the following error should show up:

Specified User or Role does not exist.

It should only have an OK button and the user or role should not be added. If possible and does not require a lot of effort we should implement auto complete (there is auto complete in other extensions if I am not mistaken such as the search. Maybe we should check the code and reuse it or create common code to be used by all).

In case of Excluded Custom Fields we should only allow characters that are allowed in custom fields names. Right now I can add characters such as ^ etc. I am checking if there is an official list of characters. Will keep you posted.

Any idea from where to start troubleshooting this issue?

https://wordpress.org/support/topic/fatal-error-undefined-method-on-upgrade

Is it possible to log all E_CRITICAL notifications to php syslog()?

Per design Site administrators on a WordPress multisite should be able to see the audit log for their own site though the plugin menu (Audit Log) is not even being shown when for example the administrator of site 1 logs in.

I rolled back installations to version 1 and this problem persists, hence I presume it is related to some changes WordPress did. Can you please check?

More info on how multisite functionality should be:
http://www.wpwhitesecurity.com/wordpress-plugins/wp-security-audit-log-plugin-features-wordpress-multisite/

We have this particular case:

https://wordpress.org/support/topic/this-version-of-mysql-doesnt-yet-support?replies=1

What do you think about it? If I search for the error on Google there are a lot of results related to this and mostly seem to point out that the query can be rewritter.

What do you think?

More info here:

https://wordpress.org/support/topic/php-warning-invalid-argument-2

Can we look into this issue please?

When a 1.4 version of the plugin is upgraded to 1.5 on a multisite, the new options table is created, the 1.4 settings are deleted but not migrated to the new options table. E.g. I had the following options configured in wp_sitemeta table (the table where multisite settings are saved):

wsal-pruning-date 1 month
wsal-pruning-limit-e 1
wsal-pruning-limit 5000
wsal-plugin-viewers
wsal-plugin-editors
wsal-delete-data 1
wsal-dev-options

Considering most of them where default most probably there was no need to migrate them but it would be safer to migrate all wsal* options. Also the wsal-delete-data was not the default yet it was not migrated. After the upgrade there were only the following settings In the wp_wsal_options table:

wsal-pruning-date "1 month"
wsal-pruning-limit-e true
wsal-pruning-limit 5000

While replicating a site I've worked on for a guy from Seychelles, I've got this error in the wp-admin, in the plugin's dashboard widget:

PHP Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in \sys-path\wp-content\plugins\wp-security-audit-log\classes\DB\ActiveRecord.php on line 62

Then, when I went to check the wsal plugin page, I got the same error and no other content.

The line in question is this:

$sql .= $key . ' VARCHAR(' . intval($class::$$maxlenght) . ') NOT NULL,' . PHP_EOL;

@markdelf @carmelopreeostudios

It seems in version 1.5 there are several users which are having problems. While one of them reported that the options table was not created:

https://wordpress.org/support/topic/wp_wsal_options-not-created-with-plugin-update?replies=6

Another one is saying that none of the tables are being created:

https://wordpress.org/support/topic/missing-database-tables-1?replies=9

Another user reported that the options table was not created though he deactivated and activated the plugin again and the table was created.

Considering there are already 3 tickets related to this issue it seems this can be a "generic" problem. Let's created a debug version of the plugin where it creates its own logs (or something similar) and log everything that is happening during activation, especially the database activity. We need to identify why the table is not being created, maybe we are getting a timeout from the SQL or something similar.

Can you please create this debug version so I send it to the customers with the problem?

The German translator pointed out that the following are missing from the translating text. Can you please fix?

If I configure the pruning option to keep up to X number of alerts all alerts are being deleted. Problem reproducible at the moment on wpprohelp.com and can be reproduced on several other websites.

If you switch the pruning to "number of alerts" all alerts are deleted upon pruning. The pruning "by time" works out fine.

Here is also a support ticket which might be related:

https://wordpress.org/support/topic/cant-change-alerts-pruning-option?replies=2