When rendering only a {field 23} tag, then I don't see the benefit to have such a plugin. It's faster to just add the value into the description of the article directly instead of creating a field, setting the value when editing an article and then using that field inside the article description.
With mustache we had looping and basic conditional functionality and this was the great benefit mostly people liked about it in DPFields.

When rendering only a {field 23} tag, then I don't see the benefit to have such a plugin. It's faster to just add the value into the description of the article directly instead of creating a field, setting the value when editing an article and then using that field inside the article description.

For a simple text field, I would agree. For a more complex field like the gallery, it's certainly not the case.

With mustache we had looping and basic conditional functionality and this was the great benefit mostly people liked about it in DPFields.

As I wrote we can expand that plugin to allow including of fieldgroups. Then you can include a group of fields, more or less what DPField does with the looping (if I understood it right). The conditionals can and should be done in the respective JLayout then if needed. Best would be if they are not needed at all, eg by using the render class.

Seems to me a good addition. +1 on fieldgroups.

tested on Picture-Gallery, works well and fine Enhancement.

But got Gallery 2 times: One by Field itself, one by {field id} in Articletext.

@franz-wohlkoenig Try changing the "Automatic Display" to "No" in the field. Then it should only appear once.

@Bakual thanks, works. PR is not for testing now?

@franz-wohlkoenig It's not ready to be merged, but can be tested and given feedback as you did.
There are some issues that need to be fixed first (eg the missing SQL files) and the fieldgroup option should be in as well. I'll try to do that today but can't promise :)

@Bakual give a go if ready for test.

@franz-wohlkoenig Go ?

Added support for fieldgroups: {fieldgroup 1} will render all fields for the group with the ID 1.
Added SQL files.

@Bakual {field *} and {fieldgroup *} works well (also both at same time in one Article).

@franz-wohlkoenig Can you add then a successful test please?

I have tested this item ✅ successfully on b808001

Would it be then also possible to support a {fields} tag? Or is {fieldgroup *} already doing that?

Would it be then also possible to support a {fields} tag? Or is {fieldgroup *} already doing that?

You mean to include all fields? Do you think there is a need for that which can't be solved by using fieldgroups already?
Currently there is no such functionality but I think it could be added. Best probably by using an asterix like {field *}, I'd rather not have yet another regex possibility (eg not {fields}) as it makes that part of the code more complex.

I have a similar plugin in my own extension which support following syntax:

{membershipplans ids="*"} => it will display all published plans in the article.
{membershipplans ids="cat-3"} => It will display all subscription plans from the category with ID = 3
{membershipplans ids="2,4,5"} => It will display all subscription plans with ID = 2, 4, OR 5.

Maybe it will be more flexible if we could support the same with this plugin, so:
{fields ids="*"} => it will display all fields.
{fields ids="fieldgroup-3"} => it will display all fields belong to group with ID = 3
{fields ids="2,4,5"} => It will display all fields with ID = 2, 4, OR 5.

(I am not sure if it is needed, just comment because I have plugin does similar things in my extension)

Or you could just make use of the generic parser already written for this purpose: #11702 ?

@chrisdavenport If it would be merged and I had an example in how to use it, then yes ?
So far, I found it much easier to use a one-liner with a rather simple regex.

I wouldn't use a coma-separated list. It makes the code more complicate for no reason. The user can either group the fields in a fieldsgroup or use multiple {field} tags to achieve the same.
Having support for a {field *} tag should be easy to implement without having to make the code much more complex.

I also like to keep the syntax similar to the one used in the "Load Module" plugin.

• Added support for {field *} ({fieldgroup *} also works, does exactly the same)
• {fieldgroup 0}` also works, it will show those fields without a group

On a sidenote, I had to add featured to the validateContext method. This enables fields also in the featured view.

With the groups and wildcards, it becomes very powerful. I'm just wondering if a different layout should be used then, eg fields/inline.php and field/inline.php. Like that the admin can distinguish between the fields rendered trough the display event and inline in the description?

You already can already decide if you want to use the fields.render layout (used by {fieldgroups}) or the field.render one (used by the single field {field} tag). You can also wrap it in your custom class and have specific CSS rules apply to it. So it's quite flexible already as it is.

In theory it could expanded for example with a second parameter in the tag (eg {field 2 otherlayout}) to change the layout to a different one, but lets run with what we have for now, there is no B/C implications if we add more features to it later one.

More importantely for me is having a editor button to create that tag. Similar to the one used for the loadmodule one. That is a higher priority for me at least ?