I’m getting a PHP warning:

Undefined array key "_user_id" in /home/sites/1a/4/44afcb079c/staging_html/wp-content/plugins/simple-history/inc/class-wp-rest-events-controller.php on line 743'

Think this relates to new line added in Changeset 3171877 (release 5.0.2). Unlike all the other nearby accesses to $context[‘_user_id’], this new one does not include “?? null”.

We’ve been having a little problem with some plugin updates lately (files missing, .maintenance mode file left in place). I know this isn’t likely related to Simple History at all, but just wondering what the problem could be. This is on multiple servers and sites, with the plugin in question seemingly being random.

Simple history is recording the events as:
Update plugin “null” from version x.xx to null

There’s a link to the changelog, but the plugin name and version are not being reported.

Hi,
The database space used by Simple History has grown up to 250 + mb and I would need to reduce it.
I read this > simple_history_contexts 258.5 mb.

The clear log option from the settings does not seem working nor the 60 days auto clearance. This is what I see after clearing the log.

Is it ok if I empty manually the DB simple_history_contexts from my SQL?

Thank you,
Marco

• This topic was modified 1 week, 4 days ago by mark8181.

The time shown on the log is exactly two hours behind my computer time which, as I’m on London UK time, is set to GMT summer time. Can this be adjusted?

Logins are tracked but logouts are not tracked. What could cause this?

I am getting “Your search did not match any history events.” if I try to view the Simple History logs.

If i check the console, the following fetch request fails:

https://www.mydomain.at/de/api/simple-history/v1/events?page=1&per_page=20&_fields%5B0%5D=id&_fields%5B1%5D=logger&_fields%5B2%5D=date&_fields%5B3%5D=date_gmt&_fields%5B4%5D=message&_fields%5B5%5D=message_html&_fields%5B6%5D=message_key&_fields%5B7%5D=details_data&_fields%5B8%5D=details_html&_fields%5B9%5D=loglevel&_fields%5B10%5D=occasions_id&_fields%5B11%5D=subsequent_occasions_count&_fields%5B12%5D=initiator&_fields%5B13%5D=initiator_data&_fields%5B14%5D=ip_addresses&_fields%5B15%5D=via&_fields%5B16%5D=permalink&dates=lastdays%3A30&_locale=user
[Error] Failed to load resource: the server responded with a status of 500 () (events, line 0)

Checking the WordPress debug log, it seems that it may be a compatibility issue with WPML:

[03-Oct-2024 08:27:38 UTC] PHP Fatal error: Uncaught Error: Call to a member function filter_translation_status() on null in /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/sitepress-multilingual-cms/addons/wpml-page-builders/classes/Shared/tm/class-wpml-tm-page-builders.php:228
Stack trace:
#0 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/sitepress-multilingual-cms/addons/wpml-page-builders/classes/Shared/tm/class-wpml-tm-page-builders-hooks.php(87): WPML_TM_Page_Builders->link_to_translation_filter('...', 7129, '...', '...')
#1 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp-hook.php(324): WPML_TM_Page_Builders_Hooks->link_to_translation_filter('...', 7129, '...', '...')
#2 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/plugin.php(205): WP_Hook->apply_filters('...', Array)
#3 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/sitepress-multilingual-cms/classes/url-handling/wpml-url-filters.class.php(149): apply_filters('...', '...', 7129, '...', '...')
#4 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp-hook.php(324): WPML_URL_Filters->get_edit_post_link('...', 7129, '...')
#5 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/plugin.php(205): WP_Hook->apply_filters('...', Array)
#6 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/link-template.php(1499): apply_filters('...', '...', 7129, '...')
#7 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/simple-history/loggers/class-post-logger.php(1065): get_edit_post_link(Object(WP_Post))
#8 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/simple-history/inc/class-simple-history.php(681): Simple_History\Loggers\Post_Logger->get_log_row_plain_text_output(Object(stdClass))
#9 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/simple-history/inc/class-wp-rest-events-controller.php(692): Simple_History\Simple_History->get_log_row_plain_text_output(Object(stdClass))
#10 /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/simple-history/inc/class-wp-rest-events-controller.php(626): Simple_History\WP_REST_Events_Controller->prepare_item_for_response(Object(stdClass), Object(WP_REST_Request))
#11 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/rest-api/class-wp-rest-server.php(1230): Simple_History\WP_REST_Events_Controller->get_items(Object(WP_REST_Request))
#12 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/rest-api/class-wp-rest-server.php(1063): WP_REST_Server->respond_to_request(Object(WP_REST_Request), '...', Array, NULL)
#13 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/rest-api/class-wp-rest-server.php(439): WP_REST_Server->dispatch(Object(WP_REST_Request))
#14 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/rest-api.php(420): WP_REST_Server->serve_request('...')
#15 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp-hook.php(324): rest_api_loaded(Object(WP))
#16 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters('', Array)
#17 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/plugin.php(565): WP_Hook->do_action(Array)
#18 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp.php(418): do_action_ref_array('...', Array)
#19 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/class-wp.php(813): WP->parse_request('')
#20 /data/sites/web/b31q9sy1myrdbxio/www/wp-includes/functions.php(1336): WP->main('')
#21 /data/sites/web/b31q9sy1myrdbxio/www/wp-blog-header.php(16): wp()
#22 /data/sites/web/b31q9sy1myrdbxio/www/index.php(17): require('...')
#23 {main}
thrown in /data/sites/web/b31q9sy1myrdbxio/www/wp-content/plugins/sitepress-multilingual-cms/addons/wpml-page-builders/classes/Shared/tm/class-wpml-tm-page-builders.php on line 228

The plugin worked previously, so this bug must have been introduced with 5.0 or 5.0.1, I am not sure because I have not checked the logs recently.

Let me know if you need more info.

WordPress 6.6.2
PHP 8.2
WPML 2.1.0?
Simple History 5.0.1

• This topic was modified 2 weeks, 5 days ago by fr3ino.

I was recently hacked where a user was able to gain access to my account, but I only allow access through a dedicated IP in the WordPress admin.

Here is the IP address:
2.37.214.199

I also allow only one session and I did not see this IP address in my log history as an attempt to log into WordPress. How is this possible?

Hi,

After updating to 5.0.1 history log shows UserNames (which are generated as random strings). Previously it showed FirstName LastName (or rather the Display Name), so we were able to identify users by that value.

Reverting to 4.17.0 brings Display Name again.

To be honest it would be helpful to be able to choose what user info is being shown (including ACFs).

Best

Jack

Simply History has been reporting thousands of failed login attempts using a variety of both legitimate usernames and random ones. However, none of our internal tools, such as server access logs, are showing these failed login attempts.

Could you please assist or provide guidance on the following:

1. How does the Simply History plugin track failed login attempts? Is there a way to validate or cross-check this data with server logs?
2. Is it possible that these failed login attempts are being logged by the plugin but not reflected in other logs? If so, why might this be happening?
3. Can you suggest any additional steps or tools we can use to investigate and track down the source of these login attempts more thoroughly?

Any assistance you can provide in helping us track down and understand these login attempts would be greatly appreciated.

Thank you for your time and support.

Hello, I am interested in the add-ons. I don’t see any information about usage on multiple websites. Is one license enough to use on multiple websites?

Hi there,

Great update function wise.

However, the new link color in the dashboard widget throws me off a little bit.

Instead of using the WordPress default #2271b1, all Simple History related links suddenly refer to the wp-admin-theme-color variable, which is #3858e9 in my case.

Could you please revert this irritating but purely cosmetic change?

I’m using Elementor and their Hello theme if that’s important.

So after I updated this plugin it stopped working completely. Can someone tell me how I can roll back the the previous version?

Thanks!

The display of event context items which are an arrays seems to have got worse in release 5.0.0.

In 5.0.0. value display of a two element array is as follows:

"{\n    \"0\": {},\n    \"-2\": {}\n}"

Whereas in 4.17.0 it was:

{
    "0": {},
    "-2": {}
}

The older version seems more readable to me.

At the dashboard I get: Your search did not match any history events. The search input field is empty

If a enter an argument – like user – it shows the corresponding events

If I rolle back to 4.17.0 everything works correctly

Hello,

In history, I have a lot of events : Updated journal “http_api_debug”.
I don’t understand because I have 3 sites and these events only appear on one of them.
I noticed that for this site, the Simply History plugin has a download link in the list of installed extensions.

Thanks for your help.
Pierre

The following was logged during the upgrade:

[22-Aug-2024 16:54:53 UTC] auditor:event=upgrader_process_complete_plugin {“action”:”update”,”type”:”plugin”,”bulk”:true,”plugin”:”simple-history/index.php”,”blog_id”:1,”event”:”upgrader_process_complete_plugin”,”current_user_id”:6,”remote_addr”:”130.xx.xxx.xxx”}
[22-Aug-2024 16:54:53 UTC] PHP Notice: Function Simple_History\Services\Dropins_Loader::load_dropins was called incorrectly. A dropin was not found. Classname was "Simple_History\Dropins\Debug_Dropin”. Please see Debugging in WordPress for more information. (This message was added in version 4.0.) in /nas/content/live/s1commauto/wp-includes/functions.php on line 6078

Looks important, but I don’t know. This was an upgrade to 4.17.0 from 4.10.0.

Thanks,

Alex

Seems that the plugin caputured page edits once and then after that it just says other pages was updated. I was hoping to be able to see every edit like this https://simple-history.com/wp-content/uploads/sites/3/2014/11/about-us-post-updated-diff-showing.png

Basically what my SEO team is editing

I think this was logging before, but not anymore..

Can anyone confirm please?

I’m continuing to tune my site for what options get autoloaded/read for every page load.

Unlike other options “simple_history_detective_mode_enabled” doesn’t appear to have a default value set in wp_options. As a result it does not get autoloaded and get_option for it always causes a call to the database.

I can workaround this by going to settings, turning it on, saving, turning it off, saving. That causes the option to be created. And I can see from Query Monitor that I no longer get the extra database calls after this.

I wonder whether the code should be creating the default option somewhere else, as appears to be the case for all other options.

Hi there,

We have s site that can get large amounts of users logging in at once 300/400.

We noticed some users show in simple history as logging in 10-20 times over 1-2 minutes. When we have checked with a few users they have said they only logged in once and didn’t have any issues.

Have you seen anything like this, or have any ideas why this could happen?

Thanks
Nik

I’m trying to reduce the time spent executing “wp_load_alloptions”. And in the process I noticed that one of the largest autoloaded options on my system is “SimplePluginLogger_plugin_info_before_update”.

Looking at the code I think the intention was that this option should only exist for the a short duration

* Saves info about all installed plugins to an option.
* When we are done logging then we remove the option.

But the call to “remove_saved_versions” which deletes the option has been commented out:

// Clear our transient after an update is done
// Removed because something probably changed in core and this was fired earlier than it used to be
// add_action( 'delete_site_transient_update_plugins', array( $this, "remove_saved_versions" ) );

Three suggestions:

• Uncomment the add_action – so it is deleted as originally intended
• Change the “update_option” in “save_versions_before_update” to have third parameter autoload=false
• Use a transient rather than an option so it gets deleted automatically after some expiry period

While the main Simple History listing is working as expected, I am experiencing problems with the “Last Modified” column on the Pages edit listing (/wp-admin/edit.php?post_type=page).

The date and time are correct, but instead of displaying the name of the last person who edited the page (an author) this column is displaying the person (an administrator) who edited the page previously.

Simple History main listing and WordPress page revisions feature display the correct name.

It almost seems like the “Last Modified” column is ignoring the author changes in preference for the previous administrator.

Hey, can you confirm if the database size of the wp simple history plugin would contribute to exceeding the max_questions limit on server level?

Our hosting has max_questions of around 7 lakhs per hour and our devs say because of the huge database size the site is facing resource issues. Is that true?

my understanding is that size of the database table has nothing to do with the issue described as it would totally depend on how many queries has been executed during that time.

If you can let us know how this plugin exactly works when someone make changes and if the older database we have in server would contribute to resource issues.

thanks! ??

How to avoid the records of my own activity as a sole administrator?, those that appear as “You”

If it is about applying a code, guide me as best as possible how and where to apply it.

Thanks!

Impressed that no one has ever asked this here.

Does it work perfectly? What are the limitations?

Hello, since a few days when I try to visit the plugin website, I always get “Error establishing a database connection”. What’s going on?

Hello,

Is it possible to get Select2 updated to a version higher than 4.0.8 which has an XSS vulnerability?

The plugin recently failed a Pen Test on my website due to this and I’d prefer to get an updated version instead of having to replace the plugin.

Thanks in Advance,
Donal

Hi

I am getting error in WordPress plugin when accessing my dashboard. Here is email I recieved by WordPress.

Howdy!

WordPress has a built-in feature that detects when a plugin or theme causes a fatal error on your site, and notifies you with this automated email.

In this case, WordPress caught an error with one of your plugins, Simple History.

First, visit your website (https://mysite.com/) and check for any visible issues. Next, visit the page where the error was caught (https://mysite.com/wp-admin/) and check for any visible issues.

Please contact your host for assistance with investigating this issue further.

If your site appears broken and you can’t access your dashboard normally, WordPress now has a special “recovery mode”. This lets you safely login to your dashboard and investigate further.


To keep your site safe, this link will expire in 1 day. Don’t worry about that, though: a new link will be emailed to you if the error occurs again after it expires.

When seeking help with this issue, you may be asked for some of the following information:
WordPress version 6.5.3
Active theme: customtheme (version )
Current plugin: Simple History (version 4.16.0) PHP version 8.2.19

Error Details
=============
An error of type E_ERROR was caused in line 403 of the file /nas/content/live/mysite/wp-content/plugins/simple-history/inc/class-log-query.php. Error message: Uncaught Exception: Error when performing query: Table ‘wp_dbname.wp_simple_history’ doesn’t exist in /nas/content/live/mysite/wp-content/plugins/simple-history/inc/class-log-query.php:403
Stack trace:
#0 /nas/content/live/mysite/wp-content/plugins/simple-history/inc/class-log-query.php(68): Simple_History\Log_Query->query_overview_mysql(Array)
#1 /nas/content/live/mysite/wp-content/plugins/simple-history/inc/class-log-query.php(44): Simple_History\Log_Query->query_overview(Array)
#2 /nas/content/live/mysite/wp-content/plugins/simple-history/dropins/class-quick-stats.php(28): Simple_History\Log_Query->query(Array)
#3 /nas/content/live/mysite/wp-includes/class-wp-hook.php(324): Simple_History\Dropins\Quick_Stats->output_quick_stats(Object(Simple_History\Services\Dashboard_Widget))
#4 /nas/content/live/mysite/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(”, Array)
#5 /nas/content/live/mysite/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#6 /nas/content/live/mysite/wp-content/plugins/simple-history/inc/services/class-dashboard-widget.php(64): do_action(‘simple_history/…’, Object(Simple_History\Services\Dashboard_Widget))
#7 /nas/content/live/mysite/wp-admin/includes/template.php(1456): Simple_History\Services\Dashboard_Widget->dashboard_widget_output(”, Array)
#8 /nas/content/live/mysite/wp-admin/includes/dashboard.php(271): do_meta_boxes(Object(WP_Screen), ‘normal’, ”)
#9 /nas/content/live/mysite/wp-admin/index.php(204): wp_dashboard()
#10 {main}
  thrown

• This topic was modified 3 months, 1 week ago by Steven Stern (sterndata). Reason: formatting

Noticed that Simple History not showing on Dashboard, but activity is being recorded and accessible in plugin itself. It used to be there, not sure when it disappeared.

Hi there!

I use a RSS-URL to fetch infos into my email-client.
https://my.domian/?simple_history_get_rss=1&rss_secret=abc123
That works fine!

Now I’d like to restrict it to a more severe loglevel, I try this:
https://my.domian/?simple_history_get_rss=1&rss_secret=abc123&loglevel=warning

Since I didn’t find any documentation about this, may I ask whether this will work?

Thanks in advance!