If you use a new plugintag loadmoduleid, you can imho get rid of the id: prefix since we expect an ID anyway (eg just {loadmoduleid 1234}). The prefix is needed if you use the existing plugintag loadmodule (eg {loadmodule id:1234}).

i hope that way is more clear

ideally the xtd-editor plugin will use this new method

I prefer this syntax too {loadmoduleid 1234} without id:.

When the id does not exist:

PHP Notice:  Undefined variable: name in \libraries\src\Helper\ModuleHelper.php on line 739
PHP Notice:  Trying to get property 'module' of non-object in \plugins\content\loadmodule\loadmodule.php on line 233

When id exists, here is the output:

<div class="custom"  >
	</div>

the syntax now is {loadmoduleid 1234} ie without id:
fixed the id not found issue
xtd-editor plugin is outside the scope of this pr

Not really out of scope as its the only complete way to answer the request in #19360

the module id is selectable from modal now

I still think you should not do SQL query in your new method getModuleById($id), and use $modules = static::load(); instead. See for example getModule().

Because 100 modules in article will produce 100 + 1 queries.

yes more clean now

Thanks a lot for doing this!

About inserting the module ID in the editor: You implemented it that selecting the title would write the old loadmodule to the editor, and selecting the ID would write the new loadmoduleid.

I think this is confusing and most users would not see that the ID is even clickable. I would prefer to replace the existing title insertion with the module insertion and not offer two choices here. It doesn't break anything, nor does it change existing markup, it just changes newly inserted markup to use the ID.

for me in the 3.8.x series cannot be replaced, in 3.9.x or 4.x it can be, but
I will leave this decision to the mantainers

Its a new feature not a bug fix so it would be in 3.9 anyway.

From !y perspective there is no b/c break. Thanks existing method will still render the module and the new replace!want method will do it in a better way that is more sustainable

in the modal when the title is selected the new syntax {loadmoduleid 12345} is written
the module id is no more selectable in modal to avoid confusion as requested
the old syntax {loadmodule mod_custom,Title} is still available only in article editing not in modal

Using the modal, the id is not included {loadmoduleid }.

i've missed the echo sorry 😅

I have tested this item ✅ successfully on 16ecfff

I have tested this item ✅ successfully on 16ecfff

Ready to Commit after two successful tests.

I have tested this item ✅ successfully on 16ecfff

Merged correctly to 3.9 via 1711cfb

Just arrived here as I needed to get modules by Id and wrote the method in JModuleHelper - I see it's on its way now :)

this isn't working
just upgraded to 3.9 and noticed this feature change however
when selecting module in article - {loadmoduleid 243} loads but then error displays & site is not visible
CALL TO UNDEFINED METHOD JOOMLA\CMS\HELPER\MODULEHELPER::GETMODULEBYID()

@rubygirlusa
I can't confirm your find.

Please try a re-update of 3.9.0 via Joomla! Update component (Upload & Update). It looks like your first one wasn't complete.

If the error persists open a new issue with step-by-step instructions to reproduce it.

reupdated 3.9.0 and still no change. Duplicating error is simple. Open Article, click MODULE (in editor), select module. {loadmoduleid 243} will then display correctly in the article in the admin area - once article is saved and viewed from front end - same error listed above(CALL TO UNDEFINED METHOD JOOMLA\CMS\HELPER\MODULEHELPER::GETMODULEBYID()) is displayed with 404 page.

@rubygirlusa please open a new Issue as Comments on a closed one didn't get much Notice.
Reporting Bugs.

@rubygirlusa it looks like you have overridden class ModuleHelper, by some extension,
that override should be removed or updated