Possible bug on profile last login section

[peiraisotta]

Hello there!

This contributor's profile https://profiles.wordpress.org/iwpresss/ shows the last login is November 2023, but they have translation contributions 1 month ago.

Thank you

[peiraisotta]

Similar, maybe same case: https://profiles.wordpress.org/mdmag/

Last login August 2023 but activity has been register 2 months ago

[peiraisotta]

Another similar case: https://profiles.wordpress.org/muhammad-rehman/ last login in Dec 2023 but recent activity on their wp profile

Committed [3068829] to Plugins SVN:
Create branch/tag for v1.2.5

4 days ago

[pkevan]

I think this is somewhat expected - since the field only logs when the user last logged in, not necessary when they used the account while being logged in.

The expiry for the logged in mechanism (cookie), is 1 year by default, so it makes me think that the method for tracking active usage shouldn't be this, or at least shouldn't be the only mechanism since it isn't accurate enough.

[pkevan]

The pattern I can see here, is that all account do not have 2FA enabled (which forces logging in more often). Not that this is currently required.

[dd32]

Noting, SVN doesn't bump the last-logged-in.

Translation dates could be off, as it might be when it was submitted vs when approved.

[pkevan]

Noting, SVN doesn't bump the last-logged-in.

Translation dates could be off, as it might be when it was submitted vs when approved.

Yeah - I was thinking of using the last_activity user meta to track users' last logged activity in a more accurate way, rather than break the logged in meta for this purpose.

Any reason not to? It doesn't look used when looking at my profile, but unsure if there is any history there.

[pkevan]

Index: wporg-profiles-activity-handler.php
===================================================================
--- wporg-profiles-activity-handler.php	(revision 13870)
+++ wporg-profiles-activity-handler.php	(working copy)
@@ -263,6 +263,8 @@
 					throw new Exception( $activity_id );
 				} elseif ( false === $activity_id || intval( $activity_id ) <= 0 ) {
 					throw new Exception( '-1 Unable to save activity' );
+				} else {
+					$this->maybe_update_last_activity();
 				}
 
 				$response = '1';
@@ -277,6 +279,36 @@
 		}
 
 		/**
+		 *
+		 * Adds/Updates user meta to track last activity.
+		 *
+		 */
+		public static function maybe_update_last_activity() {
+
+			$user = self::get_user( $_POST['user'] );
+			
+			if ( ! $user ) {
+				return;
+			}
+			
+			$user_activity_cache_key = 'wporg-user-activity-logger-' . $user->ID;
+
+			// Adds some caching to avoid unnecessary updates since we only store day.
+			$user_activity_cache = wp_cache_get( $user_activity_cache_key );
+
+			if ( $user_activity_cache ) {
+				return;
+			}
+
+			// Only store date since we aim to cache for a day.
+			update_user_meta( $user->ID, 'last_activity_tracker', date( 'Y-m-d 00:00:00' ) ); 
+			wp_cache_set( $user_activity_cache_key, '1', '', DAY_IN_SECONDS );
+
+			return;
+
+		}

Kind of hard to keep this in the right place, but above is my idea for tracking via handle_activity from https://meta.trac.wordpress.org/browser/sites/trunk/profiles.wordpress.org/public_html/wp-content/plugins/wporg-profiles-activity-handler/wporg-profiles-activity-handler.php

[dd32]

Yeah - I was thinking of using the last_activity user meta to track users' last logged activity in a more accurate way, rather than break the logged in meta for this purpose.

last_activity might be good for some purposes, but it won't be 100% relevant as lots of things don't cause a logged activity (such as... taking part in a slack discussion).

Additionally SVN / plugins activity is not a user activity item in BuddyPress, although we display such data in the activity feed, so won't bump it (Unless you generate the date on-the-fly).

[pkevan]

I was choosing not to use last_activity on purpose as it already existed (and didn't seem to be updating for me, despite many varying activities). The reason to have it slightly more accurate, as above, was to enable 5ftf program managers to see when something might have happened, as the only current method looks at logged_in which is less accurate.

[pkevan]

In https://meta.trac.wordpress.org/changeset/13881/ a new usermeta has been added to help with the inaccuracy of tracking last logged in, so going to close this issue.