What would you use the ID for?

To change the value(s) of a plugin, in particular the params, via my code.

As it stands at the moment I have to do another call to the DB to determine the id within my plugin to find the correct record to update in #__extensions.

In the sample of code pasted below that I am using at the moment, the first three lines would not be required if the id was available in the same way the other three values were set in the __construct.

public function updateParams($key, $value)
{
    $table = new  Extension(Factory::getDbo());
    $table->load(array('element' => $this->_name, 'type' => 'plugin', 'folder' => $this->_type));
    $data['extension_id'] = $table->extension_id;

    $this->params->set($key, $value);
    $data['params'] = $this->params->toString();

    $plugin_model = new PluginModel();
    $plugin_model->save($data);
}

$plugin = PluginHelper::getPlugin($type, $name);
echo $plugin->id;

should do

PluginHelper::getPlugin() has already been executed and the four columns retrieved, including extension_id, and the results passed to the __construct of CMSPluign but for some reason the id was not set in the same way the other three properties are set.

So the issue is not how to get the plugin id but for consistency and ease of use it should already be available and not require another call to getPlugin() or other methods.

Once _id is available then updating params looks a lot simpler.

        $this->params->set($key, $value);
        $plugin_model = new PluginModel();
        $plugin_model->save(array('extension_id' => $this->_id, 'params' => $this->params->toString()));

The same should also apply to the new column custom_data in the #__extensions table, it could or should be available in the same way params are now, in a _custom_data property, however I may log that as a separate issue or enhancement.

You can safe it in your own class when you need it. Just override the constructor.

We do not need this in our core plugins and when it is needed like in your case, you can always override plugin constructor to store data for your own usage as pointed out by @laoneo above. Therefore, I'm closing this issue.

This issue is/was opened to highlight a code quality or consistency concern and is not about asking for assistance on how to get the extension_id of the plugin.

In libraries/src/Plugin/PluginHelper.php within the Load() function, lines 251-315, four fields are retrieved from the Extension table including extension_id. When an instance of a Plugin is created the __construct processes the other three fields that were retrieved, the extension_id is not used.

It seems a bit like getting four new tyres(tires) for you car and they only put air in three of them and expect you put air in the fourth for no apparent reason other than that you can.

If the 'decision' is that extension_id is not to be made available at the start of their plugins then load() in libraries/src/Plugin/PluginHelper.php should be updated to remove the SQL for the retrieval of the extension_id field. However that would then be inconsistent with libraries/src/Component/ComponentHelper.php load() function and libraries/src/Helper/LibraryHelper.php function loadLibrary() that also retrieve the extension_id, I haven't looked to see if it used along with the other fields they retrieve.

In my opinion to close this issue then some lines of code should to be added or other lines of redundant code should be removed. For ease of use, less code code and a potentially repetitive call to the DB for a value already retrieved then making the extension_id available by default should be reconsidered.

If you disagree then leave this issue closed.

Yes. Look like extension_id is not used here and could be removed. However, we could not remove it now (at least until Joomla 6) because it would cause backward incompatible changes (in case some third party plugins like yours use it)

We also could not add _id property now as you suggested because:

• It is not needed (in core plugins)
• It could cause potential backward incompatible change. Imagine that we add this as a protected property, and someone add some property in his plugin as private, his plugin will be broken

So I will still keep the issue closed for now. If you still disagree, I will ask maintainers for final decision :).

@joomdonation , I don't really see the relevance that because the 'core' doesn't use it then it isn't a worthwhile thing to make available to the extension developer, I am sure there are plenty of functions and features available to developers that the core doesn't use.

If there was a potential collision with someone's own plugins use of id then it would actually support the argument for including it in the __construct and not leave it for extension developers to fill in the missing piece. If we could scan every plugin extending CMSPlugin for the use of getPlugin() to get the id/extension_id then we might have a better idea of how widespread its use is and therefore requirement might be.

There is also the more recent inclusion of the custom_data column in the #__extensions table that would further increase the need for id to be available to get and set values in the correct row for each plugin.

It looks to me that whenever the four fields were added to PluginHelper and CMSPlugin it was incomplete, one field got missed or left out on purpose, so if this isn't an issue then should I resubmit it as a new Feature?