joomla/Component-Builder
39
25
Fork 11
Code Issues 75 Pull Requests Projects 4 Wiki Activity

[BUG]: wrong class FormField in custom type #1231

New Issue
Open
opened 2025-07-05 10:36:02 +00:00 by antonbag · 4 comments
antonbag commented 2025-07-05 10:36:02 +00:00
Copy Link

What Happened?

When I compile a Custom Field, the class who extends FormField is wrong.
JCB writes use Joomla\CMS\Form\Field\FormField; but the right class is use Joomla\CMS\Form\FormField;
That only happens with a customized custom type Field. The default custom field is ok.

Steps to reproduce the Bug

  1. Create or duplicate a custom Fieldtype.
  2. Add a field type_phpa_1 with, i.e: protected function getInput(){ $html = parent::getInput(); }
  3. Create a field with this type, and add to any admin view
  4. Compile and check the code...

Which Joomla version are you compiling in?

5.3.1

Which PHP version are you compiling in?

8.1

Which Joomla versions are you targeting?

5

Which PHP version are you targeting?

8.1

Which Web server is JCB running on?

Apache/2.4.58 (Ubuntu)

Which Relational Database is JCB running on?

10.11.13-MariaDB-0ubuntu0.24.04.1

Which OS is JCB running on?

kde neon

Which JCB version are you using?

5.1.1

Where in JCB did this issue occur?

Compilation of a component

On which browsers did you encounter the issue?

Chrome

Additional Comments

No response

### What Happened? When I compile a Custom Field, the class who extends FormField is wrong. JCB writes **use Joomla\CMS\Form\Field\FormField;** but the right class is **use Joomla\CMS\Form\FormField;** That only happens with a customized custom type Field. The default custom field is ok. ### Steps to reproduce the Bug 1. Create or duplicate a custom Fieldtype. 2. Add a field type_phpa_1 with, i.e: `protected function getInput(){ $html = parent::getInput(); }` 1. Create a field with this type, and add to any admin view 2. Compile and check the code... ### Which Joomla version are you compiling in? 5.3.1 ### Which PHP version are you compiling in? 8.1 ### Which Joomla versions are you targeting? 5 ### Which PHP version are you targeting? 8.1 ### Which Web server is JCB running on? Apache/2.4.58 (Ubuntu) ### Which Relational Database is JCB running on? 10.11.13-MariaDB-0ubuntu0.24.04.1 ### Which OS is JCB running on? kde neon ### Which JCB version are you using? 5.1.1 ### Where in JCB did this issue occur? Compilation of a component ### On which browsers did you encounter the issue? Chrome ### Additional Comments _No response_
antonbag added the
Bug
 label 2025-07-05 10:36:02 +00:00
antonbag commented 2025-07-05 11:01:00 +00:00
Author
Copy Link

That happens if the extend is "list". With CheckboxesField works fine.

That happens if the extend is "list". With CheckboxesField works fine.
Llewellyn commented 2025-07-05 14:31:13 +00:00
Owner
Copy Link

Thank you for reporting this issue.

I must admit, it's a bit difficult to immediately identify the root cause, simply because I'm not entirely sure of the exact steps and environment in which this is occurring. To help us move forward efficiently, I'd like to request a bit more information from you.

1. Browser Warning

First, please note that we do not recommend using Chrome when working with JCB—particularly during compilation. We've observed that Chrome behaves unpredictably by aggressively caching things in ways that seem to interfere with server-side processes. We're not sure how or why, but it appears to somehow interfere with the extensions workflow on the server side. Because of this, I highly recommend switching to Firefox or LibreWolf, which do not exhibit this behavior and tend to work reliably during compilation.

2. Understanding the Custom Field Setup

When you mention that you're creating a custom field list and that the use statement is incorrect (use Joomla\CMS\Form\Field\FormField; instead of use Joomla\CMS\Form\FormField;), this is certainly unexpected behavior. However, we are currently using several custom fields—including list fields—and are not encountering this error. That does not mean we don't believe you; it simply means there may be a subtle difference in your setup or process that we need to identify.

To that end, could you please share the following?

  • A screenshot of your custom field definition in JCB.
  • A screenshot or code sample of the field type's PHP configuration (type_phpa_1), especially showing the extends and any overrides.
  • A clear indication of whether this is a new installation of JCB 5.1.1 or an upgrade from an older version.

3. Field Type Resets After Upgrade

If this is an upgraded installation, we strongly recommend resetting all the field types. Many field types were improved in recent versions. To do this:

  1. Go to the Field Types view in JCB.
  2. Select all field types.
  3. Click “Reset” to restore them to their updated definitions.

This ensures that all core fixes are properly applied in your local setup.

4. Field Type Behavior

You mentioned that this only happens when the field is of type list, but that it works correctly when using CheckboxesField. That's helpful to know. Again, seeing your actual custom code (especially in the type_phpa_1 section) will assist us in replicating the problem more accurately.

5. Understanding Edge Cases

As you know, JCB is highly flexible and allows for many creative use cases. This also means that edge cases are numerous and sometimes unpredictable. Without a more concrete view into your specific configuration, it's hard to provide a reliable fix.

Please feel free to share screenshots or code examples here, or even a short screencast if you prefer. The more specific and visual your example, the faster we can trace and solve the issue.

Looking forward to your feedback and more details so we can resolve this.

Thank you for reporting this issue. I must admit, it's a bit difficult to immediately identify the root cause, simply because I'm not entirely sure of the exact steps and environment in which this is occurring. To help us move forward efficiently, I'd like to request a bit more information from you. ### 1. **Browser Warning** First, please note that we **do not recommend using Chrome** when working with JCB—particularly during compilation. We've observed that Chrome behaves unpredictably by aggressively caching things in ways that seem to interfere with server-side processes. We're not sure how or why, but it appears to somehow interfere with the extensions workflow on the server side. Because of this, I highly recommend switching to **Firefox or LibreWolf**, which do not exhibit this behavior and tend to work reliably during compilation. ### 2. **Understanding the Custom Field Setup** When you mention that you're creating a custom field list and that the `use` statement is incorrect (`use Joomla\CMS\Form\Field\FormField;` instead of `use Joomla\CMS\Form\FormField;`), this is certainly unexpected behavior. However, we are currently using several custom fields—including list fields—and are not encountering this error. That does **not** mean we don't believe you; it simply means there may be a subtle difference in your setup or process that we need to identify. To that end, could you please share the following? * A **screenshot** of your custom field definition in JCB. * A screenshot or code sample of the **field type's PHP configuration** (`type_phpa_1`), especially showing the `extends` and any overrides. * A clear indication of whether this is a **new installation** of JCB 5.1.1 or an **upgrade from an older version**. ### 3. **Field Type Resets After Upgrade** If this is an **upgraded installation**, we strongly recommend resetting all the field types. Many field types were improved in recent versions. To do this: 1. Go to the Field Types view in JCB. 2. Select all field types. 3. Click “Reset” to restore them to their updated definitions. This ensures that all core fixes are properly applied in your local setup. ### 4. **Field Type Behavior** You mentioned that this only happens when the field is of type `list`, but that it works correctly when using `CheckboxesField`. That's helpful to know. Again, seeing your actual custom code (especially in the `type_phpa_1` section) will assist us in replicating the problem more accurately. ### 5. **Understanding Edge Cases** As you know, JCB is highly flexible and allows for many creative use cases. This also means that edge cases are numerous and sometimes unpredictable. Without a more concrete view into your specific configuration, it's hard to provide a reliable fix. Please feel free to share screenshots or code examples here, or even a short screencast if you prefer. The more specific and visual your example, the faster we can trace and solve the issue. Looking forward to your feedback and more details so we can resolve this.
antonbag commented 2025-07-05 15:44:30 +00:00
Author
Copy Link

Thank you for your super fast response! (and your super cool softare).

wow! Thank you!! I had a lot of problems with chrome. With FF works better!

Its a new installation (new JCB 5.1.1 over new J5.3.1).

I have prepared screenshots reproducing the bug:

  1. Create a customFieldType variant (named Custom@jtadv) with an extra field to add the getInput() method (CustomizedCustomFieldType.jpeg)
  2. Create a customField using the Custom@jtadv type Field (Named: customTest) (CustomizedCustomFieldType.jpeg). This first try extends as list
    3)Add the field to an admin view, compile and install. The result code uses the wrong Joomla\CMS\Form\Field\FormField (Custom_extend_list_Code.png)
    4)If I change the extends parameter from list to checkbox, the result code is fine (Custom_extend_checkbox_Code.png) because CheckboxField is within the Field folder in Joomla sctructure.

Thank you for your work!
I hope this contributes to get the best JCB ever! :)

Thank you for your super fast response! (and your super cool softare). wow! Thank you!! I had a lot of problems with chrome. With FF works better! Its a new installation (new JCB 5.1.1 over new J5.3.1). I have prepared screenshots reproducing the bug: 1) Create a customFieldType variant (named _Custom@jtadv_) with an extra field to add the getInput() method (CustomizedCustomFieldType.jpeg) 2) Create a customField using the _Custom@jtadv_ type Field (Named: customTest) (CustomizedCustomFieldType.jpeg). This first try extends as _list_ 3)Add the field to an admin view, compile and install. The result code uses the wrong Joomla\CMS\Form\Field\FormField (Custom_extend_list_Code.png) 4)If I change the extends parameter from list to checkbox, the result code is fine (Custom_extend_checkbox_Code.png) because CheckboxField is within the _Field_ folder in Joomla sctructure. Thank you for your work! I hope this contributes to get the best JCB ever! :)
CustomizedCustomFieldType.jpeg
791 KiB
CustomizedCustomFieldType.jpeg
791 KiB
Custom_extend_list_Code.png
72 KiB
Custom_extend_checkbox_Code.png
49 KiB
CustomizedCustomFieldType.jpeg CustomizedCustomFieldType.jpeg Custom_extend_list_Code.png Custom_extend_checkbox_Code.png
Llewellyn commented 2025-07-06 10:41:39 +00:00
Owner
Copy Link

We really appreciate the feedback and exploration!

Just to clarify the current best practice: we strongly recommend using the default "custom" field type in JCB for most use cases — especially when your goal is to extend list-type fields with values fetched from the database or when you want something beyond a radio box, but still within Joomla's supported framework.

This field type is simply called custom in the JCB Field Types list (internally it uses the GUID dd2e1f4b-f5db-45e8-85fa-efd27bae7b6a, typically with an ID of 6), and it's built precisely to allow flexible list-based input — with the ability to extend and adapt it without needing to go deep into overrides or templates.

Then there is the ModalSelect option for Joomla 5+ also very powerful as a list selection of another set of values from another table.

On the other hand, the "custom custom@ field" you're attempting to build is really designed for edge cases — scenarios where Joomla's core field types fall short. It requires a deeper understanding of the field rendering framework, template overrides, and the Joomla form system.

We do have a working template for this "custom custom" field here:
🔗 FORM_CUSTOM_FIELD.php (template)

As you'll see from the template, it's highly customized and overrides nearly every layer of the default field behavior. This makes it powerful, but also harder to get right without replicating quite a few setup pieces. You're welcome to explore that if you want to dive in, and feel free to emulate one of the predefined custom field types to see how it's done.

For now, I'd recommend sticking with the default custom field, or the new ModalSelect. It should cover most use cases well and let you proceed without complexity. Check out the Demo component use of these field types.

You're welcome to leave this issue open — I'll try to circle back when time allows and explore further solutions to possibly improve how JCB handles advanced custom fields like this out of the box.

Thanks again for engaging with the project!

We really appreciate the feedback and exploration! Just to clarify the current best practice: **we strongly recommend using the default "custom" field type** in JCB for most use cases — especially when your goal is to extend list-type fields with values fetched from the database or when you want something beyond a radio box, but still within Joomla's supported framework. This field type is simply called `custom` in the JCB Field Types list (internally it uses the GUID `dd2e1f4b-f5db-45e8-85fa-efd27bae7b6a`, typically with an ID of 6), and it's built precisely to allow flexible list-based input — with the ability to extend and adapt it without needing to go deep into overrides or templates. Then there is the ModalSelect option for Joomla 5+ also very powerful as a list selection of another set of values from another table. On the other hand, the "custom custom@ field" you're attempting to build is really designed for **edge cases** — scenarios where Joomla's core field types fall short. It requires a **deeper understanding** of the field rendering framework, template overrides, and the Joomla form system. We do have a working template for this "custom custom" field here: 🔗 [FORM\_CUSTOM\_FIELD.php (template)](https://git.vdm.dev/joomla/Component-Builder/src/branch/5.x/admin/compiler/joomla_4/FORM_CUSTOM_FIELD.php) As you'll see from the template, it's highly customized and overrides nearly every layer of the default field behavior. This makes it powerful, but also harder to get right without replicating quite a few setup pieces. You're welcome to explore that if you want to dive in, and feel free to emulate one of the predefined custom field types to see how it's done. For now, I'd recommend sticking with the default `custom` field, or the new `ModalSelect`. It should cover most use cases well and let you proceed without complexity. Check out the **Demo** component use of these field types. You're welcome to leave this issue open — I'll try to circle back when time allows and explore further solutions to possibly improve how JCB handles advanced custom fields like this out of the box. Thanks again for engaging with the project!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Beta
Issues related to the a beta release
Bug
Documentation
enhancement
help wanted
invalid
joomla
Joomla related changes
question
URGENT
wontfix
No Label
Bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aamigo Lemuel Llewellyn Malachi Roline vistamedia Martin Martin Kopp aB0t Robot ro-ot root TLWebdesign Tom van der Laan
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: joomla/Component-Builder#1231
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?