Module: Process Login History

[zoeck]

Looks like your $login_date variable is wrong.

Line 499 date_create($login_date) returns false (date_create: "Procedural style returns false on failure.")
That's why you can't use format on $date_diff ? 

[Roych]

  On 8/24/2022 at 6:11 AM, zoeck said:

Looks like your $login_date variable is wrong.

Line 499 date_create($login_date) returns false (date_create: "Procedural style returns false on failure.")
That's why you can't use format on $date_diff ? 

Expand  

Any idea how to fix this? Thank you ?

R

[flydev]

@Roych How did you changed the settings ? By hands or using the date picker ?

 

Anyway, you can check if a weird date got saved in the module tables in the database.

Open your database tool like `PHPMyAdmin` and check the following two tables :

• field_user_login_enabled_from
• field_user_login_enabled_until

The values should be something like :  2022-08-23 00:00:00

[Roych]

  On 8/24/2022 at 8:26 AM, flydev ?? said:

@Roych How did you changed the settings ? By hands or using the date picker ?

 

Anyway, you can check if a weird date got saved in the module tables in the database.

Open your database tool like `PHPMyAdmin` and check the following two tables :

• field_user_login_enabled_from
• field_user_login_enabled_until

The values should be something like :  2022-08-23 00:00:00

Expand  

I didn't change any settings yet, cause I couldn't acces the user settings yet. But I tried on those users that work, and the date is saved as you described above. 2022-08-24 00:00:00

[flydev]

Ok then, first make a backup of the database, just in case, and please show us the full `call trace` logs shown on the tracy error (below the first error screen panel), along the ProcessWire version and MySQL version.

You can also try to click on `Module Refresh` to see what happen.

---

I didn't saw in first instance that the error was from the module `ProcessLoginHistory`, there must be a heck between the two modules. Will check.

 

@Roych can you share the settings of `ProcessLoginHistory` and `ProcessLoginHistoryHooks` please ?

Edited August 24, 2022 by flydev ??
ProcessLoginHistory settings needed

[Roych]

  On 8/24/2022 at 8:40 AM, flydev ?? said:

can you share the settings of `ProcessLoginHistory` and `ProcessLoginHistoryHooks` please ?

Expand  

Sure:

I also tried module refresh with no luck. ?

R

[flydev]

Ok, then to fix the error, in `ProcessLoginHistory` date format setting, put :  Y-m-d H:i:s

Then ping @teppo ?

[Roych]

  On 8/24/2022 at 8:58 AM, flydev ?? said:

Ok, then to fix the error, in `ProcessLoginHistory` date format setting, put :  Y-m-d H:i:s

Expand  

Oh, yes it's working now. That simple, I thought I'ts gonna take a lot more to fix this with a lot more trouble. ? 

Thank you very much, really appreciated ?

R

[teppo]

Thanks @flydev ?? for identifying the error, and sorry @Roych for the inconvenience. This is now fixed in version 1.7.2 of Login History, display date format should no longer intervene with date difference calculations ?

[teppo]

A few new additions to this old module, available as of version 1.8.0 (session.txt import) and 1.9.0 (new API methods):

• There's an option in ProcessLoginHistoryHooks module config to import login history from session.txt. This can be useful when adding this module to a site with existing history, since ProcessWire (by default) collects data about successful/unsuccessful login attempts to said log file.
  • This option is intentionally hidden under collapsed "advanced" fieldset. It's not super well tested yet, could result in a very slow request in case there's a lot of data to import, and in case disk timezone is different than the one in database duplicate records may be created on first run.
• $this->modules->get('ProcessLoginHistoryHooks')->getUserLoginHistory($user, $start, $limit, $login_was_successful) returns login history data for provided ProcessWire User object. Default values are 0 for "start", 2 for "limit", and 1 for "login_was_successful", which means that by default this method will return latest successful login and the one before that. Return value is always an array; in case there are no results, an empty array is returned.
• $user->getLoginHistory($start, $limit, $login_was_successful) does the same as previous command for a specific User object. All arguments are optional. This method returns a single timestamp (when limit is 1, or an integer value is provided for the "start" argument and "limit" argument is omitted), an array of login history, or null in case there are no results. By default timestamps for last two successful logins are returned.

[RIC Developer]

@teppo  Great module and thanks for sharing it with everyone and keeping it going as well. Saved me some time from writing something much simpler. I really like the admin interface of it. 

I thought I would ask first, but I need the ability to disable the "remove" feature in the admin interface. I think this would be best handled and triggered by a config setting in the ProcessWire config file as opposed to a setting in the module myself. Logging in my use case is for audit purposes and should not be deleted by anyone that doesn't have direct db access. 

Any thoughts on this request?

Thanks. 

[teppo]

Hey @RIC Developer

Thanks for the suggestion, makes sense to me. Latest version (1.10.0) of the module has a specific setting for allowing/disabling removal of rows. Additionally settings (all of them) can be defined in site config, in which case they are no longer editable in module config:

$config->ProcessLoginHistory = [
    'allow_remove' => 0,
];

Note that there was already a separate (optional) login-history-remove permission: if this permission exists, it is required in order to remove rows. This was undocumented, but I've added a separate permissions section to the README.

[RIC Developer]

@teppo Your a rockstar sir! Thanks for the quick options on this. Where can I send you a beer? Cheers!

[matjazp]

@teppo I just opened an issue regarding deprecation warnings.

[adrian]

@teppo - I could have sworn this was already an option I'd seen, but can't find it now, so what do you think about having a LoginHistory tab (or fieldset on the Settings tab) on user pages?

[teppo]

@adrian, that should already be there, but it requires specific permissions: https://github.com/teppokoivula/ProcessLoginHistory/blob/b14b68286a4df41b2b7beb5ada6e38e90e81d2b1/ProcessLoginHistoryHooks.module#L235

[adrian]

Thanks @teppo - I knew I had seen it somewhere before :)

I have a very long Content tab and so didn't notice it at the bottom. Thanks!

[ceberlin]

When trying to run the cleanup im the HOOKS file, I get this error (PHP 8.3):
You can't specify target table 'process_login_history' for update in FROM clause

ChatGPT suggests this:

Problematic query:

$sql = "DELETE FROM " . self::TABLE_NAME . " WHERE login_timestamp <= 
       (SELECT login_timestamp FROM " . self::TABLE_NAME . " ORDER BY login_timestamp DESC LIMIT $max_rows, 1)";

MySQL does not allow modifying a table (DELETE) while reading from it in a subquery (SELECT from the same table). 

Use a Derived Table Modify the query to avoid directly reading from the same table:

$sql = "DELETE FROM " . self::TABLE_NAME . " 
        WHERE login_timestamp <= 
        (SELECT min_login_timestamp FROM 
            (SELECT login_timestamp AS min_login_timestamp 
             FROM " . self::TABLE_NAME . " 
             ORDER BY login_timestamp DESC LIMIT $max_rows, 1) AS temp_table)";

This forces MySQL to materialize the subquery result before executing the delete.

I changed that and the error is gone.

[teppo]

  On 2/22/2025 at 9:11 PM, ceberlin said:

When trying to run the cleanup im the HOOKS file, I get this error (PHP 8.3):
You can't specify target table 'process_login_history' for update in FROM clause

ChatGPT suggests this:

Expand  

Thanks, I’ll look into this soon. I’m using MariaDB almost exclusively, and it seems that this is not an issue there.

There seems to be one potential gotcha with the suggested solution: https://stackoverflow.com/questions/45494/mysql-error-1093-cant-specify-target-table-for-update-in-from-clause. Might be better to do two queries instead.