Joomla! Documentation - User contributions [en]

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:46:00Z

Twister65:

<noinclude><languages /></noinclude>
Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou module User Action Log, quand des actions de votre extension sont affichées.

En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constructeur de votre plugin actionlog devrait être réduit au strict minimum et ne pas faire des initialisations qui pourraient avoir un impact sur les performances. Si vous avez besoin de faire toute sorte d'initialisation lourde, essayer de la reporter au dernier moment possible, c'est-à-dire quand vous êtes sur le point de tracer une action.

Le plugin actionlog est destiné à "capturer" les actions de votre extension et de les enregistrer (tracer). La partie capture dépend entièrement de votre extension. L'idée est que chaque action intéressante qui a besoin d'être tracée doit déclencher un événement de plugin qui est géré par votre plugin actionlog et a pour effet de tracer ladite action dans la base de données.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/3/fr

2019-06-12T19:46:00Z

Twister65:

En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constructeur de votre plugin actionlog devrait être réduit au strict minimum et ne pas faire des initialisations qui pourraient avoir un impact sur les performances. Si vous avez besoin de faire toute sorte d'initialisation lourde, essayer de la reporter au dernier moment possible, c'est-à-dire quand vous êtes sur le point de tracer une action.

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:43:20Z

Twister65: Created page with "Le plugin actionlog est destiné à "capturer" les actions de votre extension et de les enregistrer (tracer). La partie capture dépend entièrement de votre extension. L'idé..."

<noinclude><languages /></noinclude>
Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou module User Action Log, quand des actions de votre extension sont affichées.

En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constructeur de votre plugin actionlog devrait être réduit au strict minimum et ne pas faire des initialisations qui pourraient avoir un impact sur les performances. Si vous avez besoin de faire toute sorte d'initialisation lourde, essayer de le reporter au dernier moment possible, c'est-à-dire quand vous êtes sur le point de tracer une action.

Le plugin actionlog est destiné à "capturer" les actions de votre extension et de les enregistrer (tracer). La partie capture dépend entièrement de votre extension. L'idée est que chaque action intéressante qui a besoin d'être tracée doit déclencher un événement de plugin qui est géré par votre plugin actionlog et a pour effet de tracer ladite action dans la base de données.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/4/fr

2019-06-12T19:43:19Z

Le plugin actionlog est destiné à "capturer" les actions de votre extension et de les enregistrer (tracer). La partie capture dépend entièrement de votre extension. L'idée est que chaque action intéressante qui a besoin d'être tracée doit déclencher un événement de plugin qui est géré par votre plugin actionlog et a pour effet de tracer ladite action dans la base de données.

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:32:07Z

Twister65: Created page with "En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constr..."

<noinclude><languages /></noinclude>
Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou module User Action Log, quand des actions de votre extension sont affichées.

En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constructeur de votre plugin actionlog devrait être réduit au strict minimum et ne pas faire des initialisations qui pourraient avoir un impact sur les performances. Si vous avez besoin de faire toute sorte d'initialisation lourde, essayer de le reporter au dernier moment possible, c'est-à-dire quand vous êtes sur le point de tracer une action.

The actionlog plugin is meant to "catch" your extension's actions and log them. The "catching" part depends entirely on your extension. The concept is that each interesting action that needs to be logged must trigger a plugin event which is handled by your actionlog plugin and has the effect of logging said action to the database.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/3/fr

2019-06-12T19:32:07Z

En tant que développeur, vous devriez être avisé que tous les plugins actionlog publiés sont chargés par le plugin système Joomla Action Log. Cela implique que le constructeur de votre plugin actionlog devrait être réduit au strict minimum et ne pas faire des initialisations qui pourraient avoir un impact sur les performances. Si vous avez besoin de faire toute sorte d'initialisation lourde, essayer de le reporter au dernier moment possible, c'est-à-dire quand vous êtes sur le point de tracer une action.

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:18:14Z

Twister65: Created page with "Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou..."

<noinclude><languages /></noinclude>
Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou module User Action Log, quand des actions de votre extension sont affichées.

As a developer, you should be aware that all published actionlog plugins are loaded by Joomla's Action Log system plugin on every page load. The implication to that is that the constructor of your actionlog plugin should be kept to a bare minimum and not do any initialization which could have a performance impact. If you need to perform any kind of heavy initialization try to defer it for the last possibly moment, i.e. when you are about to log an action.

The actionlog plugin is meant to "catch" your extension's actions and log them. The "catching" part depends entirely on your extension. The concept is that each interesting action that needs to be logged must trigger a plugin event which is handled by your actionlog plugin and has the effect of logging said action to the database.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/2/fr

2019-06-12T19:18:14Z

Veuillez prendre en considération que si votre plugin n'est pas dans le dossier actionlog, vous obtiendrez des chaînes de caractères non traduites dans le composant et / ou module User Action Log, quand des actions de votre extension sont affichées.

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:13:35Z

Twister65: Created page with "Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog."

<noinclude><languages /></noinclude>
Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

Please note that if your plugin is not in the actionlog folder you will get untranslated strings in the User Action Log component and / or module when actions of your extension are being displayed.

As a developer, you should be aware that all published actionlog plugins are loaded by Joomla's Action Log system plugin on every page load. The implication to that is that the constructor of your actionlog plugin should be kept to a bare minimum and not do any initialization which could have a performance impact. If you need to perform any kind of heavy initialization try to defer it for the last possibly moment, i.e. when you are about to log an action.

The actionlog plugin is meant to "catch" your extension's actions and log them. The "catching" part depends entirely on your extension. The concept is that each interesting action that needs to be logged must trigger a plugin event which is handled by your actionlog plugin and has the effect of logging said action to the database.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/1/fr

2019-06-12T19:13:35Z

Twister65: Created page with "Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog."

Joomla! 3.9 et plus permet aux extensions de tracer leurs actions dans User Action Log. Cela est possible en créant un plugin dans le dossier actionlog.

J3.x:Make your own Action Log Plugin/fr

2019-06-12T19:09:57Z

Twister65: Created page with "J3.x:Faites votre propre Plugin Action Log"

<noinclude><languages /></noinclude>
Joomla! 3.9 and later allows extensions to log their actions in the User Action Log. This is done by creating a plugin in the actionlog folder.

Please note that if your plugin is not in the actionlog folder you will get untranslated strings in the User Action Log component and / or module when actions of your extension are being displayed.

As a developer, you should be aware that all published actionlog plugins are loaded by Joomla's Action Log system plugin on every page load. The implication to that is that the constructor of your actionlog plugin should be kept to a bare minimum and not do any initialization which could have a performance impact. If you need to perform any kind of heavy initialization try to defer it for the last possibly moment, i.e. when you are about to log an action.

The actionlog plugin is meant to "catch" your extension's actions and log them. The "catching" part depends entirely on your extension. The concept is that each interesting action that needs to be logged must trigger a plugin event which is handled by your actionlog plugin and has the effect of logging said action to the database.

Joomla's MVC only triggers events on content preparation. If you want to see how you can handle those events for your component check the Joomla plugin in the actionlog folder.

For everything else it's advisable to use your own, custom plugin event names. Take extra care to not cause any naming conflicts. For example, a plugin event called <tt>onAfterInitialize</tt> is '''BAD''' because it clashes with Joomla's built-in event by the same name. '''DO NOT''' use generic plugin names such as <tt>onAfterSave</tt> because you are guaranteed to cause a conflict with another extension or Joomla itself. Remember that plugin event names are shared across all plugins in all plugin folders!

The best way to prevent naming clashes is using naming conventions like the following:

* For components, <tt>onComComponentControllerViewnameAfterorbeforeTask</tt> e.g. <tt>onComExampleControllerItemsAfterBrowse</tt> for <tt>option=com_example&view=items&task=browse</tt>
* For plugins, <tt>onPlgFolderPluginnameAction</tt> e.g. <tt>onPlgSystemFoobarBaz</tt> to log the "baz" action taken by a plugin named <tt>foobar</tt> in the system folder.

Modules, templates, and libraries are unlikely candidates for actions you might want to log but you can use a similar naming convention:

* For modules, <tt>onModSiteoradminModulenameAction</tt> e.g. <tt>onModSiteExampleFoo</tt> for a frontend (site) module <tt>mod_example</tt> taking action foo
* For libraries, <tt>onLibLibrarynameAction</tt> e.g. <tt>onLibExampleFoo</tt> for the <tt>lib_example</tt> library taking action foo
* For templates, <tt>onTplSiteoradminTemplatenameAction</tt> e.g. on <tt>TplSiteExampleFoo</tt> for a frontend template named example taking action foo

If you have a Model used in many of your component's controllers and you would rather log an action taken there you can use the naming convention <tt>onComComponentModelModelnameAfterorbeforeMethodname</tt> e.g. <tt>onComExampleModelItemsBeforeSave</tt> to log something that happens after calling the <tt>ExampleModelItems::save()</tt> method. Again, this convention is arbitrary and the only reason we recommend it is that you can have a 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.

Logging the actions requires going through a bit of code to perform sanity checks (e.g. correct Joomla version) and do the actual logging. Here is a prototype function you can use in your plugin:

<source lang="php">
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;
}

// 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
}
}
</source>

Here is an example plugin method performing user action logging:

<source lang="php">
/**
* 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->logUserAction($profile_title, 'COM_AKEEBA_LOGS_PROFILE_ADD', 'com_akeeba');
}
</source>

Note that the log title (the second argument to the method) is a translation key. It is defined similar to that:

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

The <tt>{title}</tt> variable is the <tt>$title</tt> parameter in our method. The other two variables are defined and processed by the User 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 this documentation page since neither <tt>JModelLegacy</tt> is available, nor will the Model name be <tt>ActionlogsModelActionlog</tt>.

<noinclude>
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:User Action Logs]]
</noinclude>

Translations:J3.x:Make your own Action Log Plugin/Page display title/fr

2019-06-12T19:09:56Z

Twister65: Created page with "J3.x:Faites votre propre Plugin Action Log"

J3.x:Faites votre propre Plugin Action Log

Selecting data using JDatabase/fr

2019-06-11T19:33:33Z

Twister65:

Translations:Selecting data using JDatabase/25/fr

2019-06-11T19:33:29Z

Twister65:

La méthode de jointure ci-dessus nous permet d'interroger les deux tables "content" et "users", en récupérant les articles avec leur auteur. Il y a aussi des méthodes pratiques pour les jointures:

Selecting data using JDatabase/fr

2019-06-11T19:32:39Z

Twister65:

Translations:Selecting data using JDatabase/25/fr

2019-06-11T19:32:35Z

Twister65:

La méthode de jointure ci-dessus nous permet d'interroger les deux tables "content" et "user", en récupérant les articles avec leur auteur. Il y a aussi des méthodes pratiques pour les jointures:

Selecting data using JDatabase/fr

2019-06-11T04:20:03Z

Twister65:

Translations:Selecting data using JDatabase/68/fr

2019-06-11T04:19:59Z

Twister65:

=== Résultats à une simple colonne ===

Selecting data using JDatabase/fr

2019-06-11T04:19:14Z

Twister65:

Translations:Selecting data using JDatabase/43/fr

2019-06-11T04:19:10Z

Twister65:

=== Résultats à une simple ligne ===

Selecting data using JDatabase/fr

2019-06-11T04:18:22Z

Twister65:

Translations:Selecting data using JDatabase/32/fr

2019-06-11T04:18:18Z

Twister65:

=== Résultat à valeur simple ===

Selecting data using JDatabase/fr

2019-06-10T19:59:57Z

Twister65:

Translations:Selecting data using JDatabase/68/fr

2019-06-10T19:59:53Z

Twister65:

=== Résultats à une seule colonne ===

Selecting data using JDatabase/fr

2019-06-10T19:59:07Z

Twister65:

Translations:Selecting data using JDatabase/32/fr

2019-06-10T19:59:03Z

Twister65:

=== Résultat à une seule valeur ===

Selecting data using JDatabase/fr

2019-06-10T19:57:19Z

Twister65:

Translations:Selecting data using JDatabase/43/fr

2019-06-10T19:57:14Z

Twister65:

=== Résultats à une seule ligne ===

Selecting data using JDatabase/fr

2019-06-10T19:55:40Z

Twister65:

Translations:Selecting data using JDatabase/134/fr

2019-06-10T19:55:36Z

Twister65:

ou quand vous souhaitez juste un seul champ d'une seule ligne de la table (ou un seul champ à partir de la première ligne retournée).

Selecting data using JDatabase/fr

2019-06-10T19:53:56Z

Twister65:

Translations:Selecting data using JDatabase/34/fr

2019-06-10T19:53:52Z

Twister65:

Utilisez '''loadResult()''' quand vous souhaitez juste une seule valeur de retour de votre requête de base de données.

Selecting data using JDatabase/fr

2019-06-10T19:53:23Z

Twister65:

Translations:Selecting data using JDatabase/32/fr

2019-06-10T19:53:19Z

Twister65:

=== Résultat à valeur seule ===

Selecting data using JDatabase/fr

2019-06-10T19:52:11Z

Twister65:

Translations:Selecting data using JDatabase/17/fr

2019-06-10T19:52:07Z

Twister65:

==Sélectionner des enregistrements d'une seule table==

Translations:Selecting data using JDatabase/139/fr

2019-06-10T19:48:40Z

Twister65: Created page with "Joomla CMS 3.8 API"

Joomla CMS 3.8 API

Translations:Selecting data using JDatabase/138/fr

2019-06-10T19:48:28Z

Twister65: Created page with "(Joomla! 3.3+)"

(Joomla! 3.3+)

Selecting data using JDatabase/fr

2019-06-10T19:48:27Z

Twister65: Created page with "Utiliser les méthodes d'union dans les requêtes de base de données"

Translations:Selecting data using JDatabase/137/fr

2019-06-10T19:48:23Z

Twister65: Created page with "Utiliser les méthodes d'union dans les requêtes de base de données"

Utiliser les méthodes d'union dans les requêtes de base de données

Selecting data using JDatabase/fr

2019-06-10T19:47:39Z

Twister65: Created page with "Insertion, mise à Jour et suppression de données à l'aide de JDatabase"

Translations:Selecting data using JDatabase/136/fr

2019-06-10T19:47:35Z

Twister65: Created page with "Insertion, mise à Jour et suppression de données à l'aide de JDatabase"

Insertion, mise à Jour et suppression de données à l'aide de JDatabase

Selecting data using JDatabase/fr

2019-06-10T19:47:15Z

Twister65: Created page with "A savoir: getNumRows() est seulement valide pour des déclarations comme SELECT ou SHOW qui retourne un véritable jeu de résultats. Si vous exécutez getNumRows() après loa..."

Translations:Selecting data using JDatabase/131/fr

2019-06-10T19:47:11Z

A savoir: getNumRows() est seulement valide pour des déclarations comme SELECT ou SHOW qui retourne un véritable jeu de résultats. Si vous exécutez getNumRows() après loadRowList() - ou n'importe quelle méthode d'extraction - vous obtiendrez un avertissement PHP.

Selecting data using JDatabase/fr

2019-06-10T19:42:09Z

Twister65:

Translations:Selecting data using JDatabase/130/fr

2019-06-10T19:42:05Z

Twister65:

retournera :

Selecting data using JDatabase/fr

2019-06-10T19:41:52Z

Twister65: Created page with "<tt>getNumRows()</tt> retournera le nombre de lignes résultantes trouvées par la dernière requête SELECT ou SHOW et en attente d'être lue. Pour obtenir un résultat à pa..."

Translations:Selecting data using JDatabase/129/fr

2019-06-10T19:41:48Z

<tt>getNumRows()</tt> retournera le nombre de lignes résultantes trouvées par la dernière requête SELECT ou SHOW et en attente d'être lue. Pour obtenir un résultat à partir de getNumRows(), vous devez l'exécuter après la requête et avant d'extraire tout résultat. Pour extraire le nombre de lignes affectées par une requête INSERT, UPDATE, REPLACE ou DELETE, utilisez getAffectedRows().

Selecting data using JDatabase/fr

2019-06-10T19:32:16Z

Twister65: Created page with "A savoir: Key doit être un nom de colonne valide de la table; il ne doit pas être un index ou une clé primaire. Mais s'il n'a pas de valeur unique vous ne pourrez pas extra..."

Translations:Selecting data using JDatabase/126/fr

2019-06-10T19:32:13Z

A savoir: Key doit être un nom de colonne valide de la table; il ne doit pas être un index ou une clé primaire. Mais s'il n'a pas de valeur unique vous ne pourrez pas extraire les résultats fidèlement.