Should'nt this be reported at 3rd-Party (akeeba)?

@nikosdion can you have a look if this is a akeeba problem or core?

Perhaps a related PR? #22282
I closed it because lack of interest and because of "has conflicts".

Please note that the person who debugged that issue was @tampe125 and I believe he's the one who asked our user to file an issue in the Joomla repo. For further enquiries please message him, he has a much better idea of what's going on. I can only repeat what he told me two days ago.

The language strings do exist in Akeeba Backup's language files. The language files are not loaded by the User Actions module. They are loaded in the component though and it displays our user actions just fine. Therefore we believe that the problem is a bug in core code, not our code.

BTW, it'd be really great if you could write a short guide of how User Action Logs are supposed to be used by developers. We try to follow Joomla's example but there are inconsistencies and weirdness all around. We basically had to reverse engineer the intent of this feature and experiment by altering database data before we were fairly certain how it works.

I can't reproduce this issue.

@twister65 its the module not the component

Okay, I'm sorry. I can reproduce this issue in the control panel.

I can reproduce this issue. It is happening in the Action Logs - Latest administrator module. I have it published in the cpanel position on about 30 Joomla 3.9.4 websites. It has always been that way since the System - Akeeba Backup Log User Actions and System - Admin Tools Log User Actions plugins became available, and in each version of Akeeba components since.

When I view the administrator menu item User > User Actions Log there is no problem. The language variable displays instead of the constant.

I think @tampe125 accidentally misled me as to the nature of the problem. I just found the time to take a look at it myself. The problem is, indeed, in our software -- and a documentation issue in Joomla itself. Sorry for wasting everyone's time :(

The problem is that he's using a system plugin to record the user actions but the language strings are in the component's language strings. They won't be loaded automatically. Even if he had the strings in the system plugin that would still be a huge problem since the language strings wouldn't be loaded if someone unpublished the system plugin. This had me following the code to see what Joomla is doing.

The latest action logs module uses ActionlogsHelper::loadActionLogPluginsLanguage to load the language strings of all published and unpublished plugins in the actionlog plugin group. The actionlog plugins are loaded through the actionlog system plugin which makes them system-plugins-by-proxy and they work across all components. That's the bit that Davide missed and went with creating a system plugin in the first place.

Therefore the correct solution is converting our plugin into an actionlog one and moving the language strings there. I just tested that and it's working. Moreover, the language strings work fine even if the actionlog plugin is disabled (as they should). I don't know why the action logs component works but I'm not inclined to dive deeper. I found the problem and I'm fixing it, I don't want to know what accident led to the wrong language file being loaded and led to our releasing this ill-thought plugin...

For what it's worth, I see why a very talented BUTT less experienced developer than yours truly got confused. This will bring me to the documentation issue in a minute.

Joomla is using a system plugin to load the actionlog plugins which actually do the logging. This is not very clear neither to the end user nor the developer. In fact, it's misleading developers into believing user action logging takes place through system plugins, not actionlog plugins.

Looking at developer.joomla.org for Action Logs is useless. Searching the docs yields this cryptic page https://docs.joomla.org/J3.x:User_Action_Logs which is equally useless in anyone understanding what the heck is going on. I had to actually follow the code of the latest action logs module backwards to find where the language strings are coming from and then look for 'actionlog' in the code to see where the plugins are loaded to get a good idea of how the whole shebang works under the hood.

Yeah, I figured it out. It only took me 5' of reading the code and 13-odd years of experience with Joomla internals. Apparently, it's not something most developers will or can do. Maybe we need a good documentation page? I can't contribute one since I don't use the core MVC (meaning that what I'd write would be just as useless to developers as the current mess) but I can help anyone interested with a skeleton and proof-reading.

@nikosdion I can proofread if you like.

Do you have a simple component I could try to write action logs for? Otherwise I'd have to create Yet Another To-Do Component using the Joomla MVC framework first, then create the actions log -- but that sounds more like an invitation to an asylum than a solid plan.

Perhaps we can use https://github.com/joomla-extensions/boilerplate/tree/feature/list-edit as base. It should be installable and workable last time I checked, otherwise I may need to do some fixing.

Looking at my to-do list I don't think I have a realistic chance of helping with that beyond proof-reading someone else's work. Sorry :(

@mbabker:
Should an actionlog plugin extend to ActionLogPlugin ?
Can you help please, have you a developer guide ?

There is no developer's guide. I can tell you what we do. We derived that information by studying Joomla's code and experimenting.

You don't have to extend any other plugin BUT your plugin must be in the actionlog folder. Otherwise you'll get untranslated strings like I described above :( All activated actionlog plugins are loaded by Joomla's Action Log system plugin on every page load. That is to say, please don't add any heavy lifting in your plugin. Keep it lean and fast, especially its initialization. Therefore the plugin should contain only code to catch your component's actions and log them.

As to how you are going to catch your component's actions, that depends entirely on your component. Joomla's MVC only triggers events on content preparation. If you want to have some of your component's actions loggable you should trigger a plugin event in your controller. I recommend using the naming convention onComComponentControllerViewnameAfterorbeforeTask e.g. onComExampleControllerItemsAfterBrowse for option=com_example&view=items&task=browse. These are unlikely to cause naming clashes with other plugins. DO NOT use generic plugin names such as onAfterSave because you are guaranteed to screw something up. Remember that plugin event names are shared across all plugins of all extensions in all plugin folders.

If you have a model used in many of your extension's controllers and you would rather log an action taken there you can use the naming convention onComComponentModelModelnameAfterorbeforeMethodname e.g. onComExampleModelItemsBeforeSave to log something that happens after calling the ExampleModelItems::save() method. Again, this convention is arbitrary and the only reason I'm using it is that I have the more than reasonable expectation that it won't cause naming clashes. The more specific the event name is the less likely it is to have a conflict with core or third party code :)

In our extensions, built with FOF, we catch the events triggered by FOF (following the naming convention I described above, e.g. onComAkeebaControllerConfigurationAfterApply). In there, we add action log entries by calling a method like this:

public function logUserAction($title, $logText, $extension)
	{
		static $joomlaModelAdded = false;

		// User Actions Log is available only under Joomla 3.9+
		if (version_compare(JVERSION, '3.9', 'lt'))
		{
			return;
		}

		// Do not perform logging if we're under CLI. Even if we _could_ have a logged user in CLI, ActionlogsModelActionlog
		// model always uses JFactory to fetch the current user, fetching data from the session. This means that under the CLI
		// (where there is no session) such session is started, causing warnings because usually output was already started before
		if ($this->isCli())
		{
			return;
		}

		// Include required Joomla Model
		if (!$joomlaModelAdded)
		{
			\JModelLegacy::addIncludePath(JPATH_ROOT . '/administrator/components/com_actionlogs/models', 'ActionlogsModel');
			$joomlaModelAdded = true;
		}

		$user = $this->getUser();

		// No log for guest users
		if ($user->guest)
		{
			return;
		}

		$message = array(
			'title'    	  => $title,
			'username' 	  => $user->username,
			'accountlink' => 'index.php?option=com_users&task=user.edit&id=' . $user->id
		);

		/** @var \ActionlogsModelActionlog $model **/
		try
		{
			$model = \JModelLegacy::getInstance('Actionlog', 'ActionlogsModel');
			$model->addLog(array($message), $logText, $extension, $user->id);
		}
		catch (\Exception $e)
		{
			// Ignore any error
		}
	}

Example method from Akeeba Backup's action log plugin:

/**
	 * Logs the creation of a new backup profile
	 *
	 * @param \Akeeba\Backup\Admin\Controller\Profiles	$controller
	 * @param array										$data
	 * @param int										$id
	 */
	public function onComAkeebaControllerProfilesAfterApplySave($controller, $data, $id)
	{
		// If I have an ID in the request and it's the same of the model, I'm just editing a record
		if (isset($data['id']) && $data['id'] == $id)
		{
			return;
		}

		$profile_title = $data['description'];

		$this->container->platform->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
	}

Note that the log title is a translation key. It is defined similar to that:

COM_AKEEBA_LOGS_PROFILE_ADD="User <a href=\"{accountlink}\">{username}</a> created the backup profile {title}"

The {title} variable is the $title we logged in our method. The other two variables are defined and processed by the Action Logs module and component when rendering the user actions log.

Caveat: Since Joomla 4 has not yet integrated the Action Logs component and plugins the code above will not work on Joomla! 4. If / when Action Logs are ported to Joomla 4 we'll have to revisit it since neither JModelLegacy is available, nor will the Model name be ActionlogsModelActionlog.

I hope that helps!

@roland-d I guess my comment above is as good a developer's guide as anyone's gonna write. Do you want me to put it in the docs wiki? If so, tell me exactly where.

As you say above, the plugin must be placed in the Actionlog plugin folder.
Please, find the new actionlog akeeba plugin attached:
plg_actionlog_akeebabackup.zip

Thank you very much! So far, it looks like it's working properly.

Steve
ᐧ

On Sat, Apr 6, 2019 at 10:05 AM Olivier notifications@github.com wrote:

As you say above, the plugin must be placed in the Actionlog plugin
folder.
Please, find the new actionlog akeeba plugin attached:
plg_actionlog_akeebabackup.zip
https://github.com/joomla/joomla-cms/files/3050710/plg_actionlog_akeebabackup.zip

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#24049 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/At30piTTCupXiK4qJjpB3dq5ASXF2Idaks5veNPDgaJpZM4bXZ0y
.

--
"On the off chance that you’re not going to live forever, why not take a
chance at being happy now?" ~ Charlie Skinner (The Newsroom)

@nikosdion Thanks for the documentation

I would just create the doc anywhere on the wiki and then leave it to the doc team to move it to the correct place.

@twister65 I have already refactored that plugin. And Admin Tools' plugin. I also moved around the language strings and made sure that upon installing the new version the old system plugin will be uninstalled and the new actionlog plugin will be enabled (but only if the old system plugin was enabled). I just haven't had the time to release a new version for unrelated reasons.

@brianteeman I'll do that next week. I'll be driving the next two days.

I have created a documentation page at https://docs.joomla.org/Make-your-own-action-log-plugin

Thank you!!

so this can be closed now