Is it me or is it not possible to override the JForm Fields in the CMS folder?
My Content plugin uses:
JForm::addFieldPath( __DIR__ . '/fields' );
in the onContentPrepareForm
or onContentPrepareData
event. Now in my "fields" folder I have text.php, textarea.php, tag.php, editor.php & media.php.
The core JFormFieldText
& JFormFieldTextArea
fields reside in the "joomla/form/fields" folder, whereas the tag, editor & media core fields reside in the "cms/form/field" folder.
I have found that only the "libraries/joomla/form/fields" can be overridden whereas the libraries/cms/form/field ones cannot.
From my investigations into the JFormHelper
loader the cms class version already exists before it has a chance to load in the override.
I've even tried some earlier events in a system plugin like onAfterInitialise
& the __construct
to no avail!
Obviously I could use JForm::addFormPath()
to manually override an individual form but if I'm trying to catch all instances of a field without wanting to manually account for each form then I should just be able to use JForm::addFieldPath()
.
If it's helpful I can respond with an example plugin & custom field code for testing purposes.
Thoughts welcome :)
Hi,
Thanks for the tips & explanation, which from a development point of view does make sense. I'm also happy to use the JLoader::register()
logic that you have suggested. However I think my original scenario for overriding core fields is still valid.
Say for example I am building a plugin to extend the tag behaviour across the whole of the administrator. I can either:
Or
Unless I've missed a simpler method the shortfall is that I must personally know & account for every instance of a tag use (which could change) & then include separate forms for each (as they appear in different xml fieldset structures). Whereas the 1st method can rest safe in the knowledge that every tag that is included by Joomla/3rd Party extensions are automatically caught.
Furthermore, take a plugin developer who wants to add/override fields. He uses JForm::addFieldPath()
but for some reason it is only overriding some of the fields he needs. Surely he shouldn't have to navigate his way through the library to find out why some fields need including in a different fashion? (auto loading).
Isn't the whole point of JForm to make adding/overriding forms and fields as simple as possible? Moreover the location of fields in the Joomla 3 series has constantly been changing from joomla/form to cms/form which means developers must be active in checking which classes need auto loading and which can be added the 'JForm' way. Does that make sense?
Not in front of a computer, so I'm going from the top of my head.
First, the intent is to get the core API to always auto load so jimport() and other methods that manually include a file can go away. That would include the JForm functions to add fields to its internal lookups (the one for the XML files won't go away for obvious reasons).
As for your use case, in your plugin, you should be able to call $form->findField('tag') to find if a form has a tag field. Then using JForm's API, you could remove that field and add your extended field; you would need to manually bind the data again though if you remove it after data has been loaded.
Labels |
Added:
?
|
Thanks for explaining the direction the API is going in. I'll stick with the auto loading route then if that's where the library is heading.
The $form->findField()
would be really helpful except it's a protected method.
In case anyone ever finds this thread or is curious here's my code for auto loading all form fields inside the plugin's fields folder:
public function onContentPrepareForm( $form, $data )
{
if( !( $form instanceof JForm ) )
{
return false;
}//end if
$extension = '.php';
$files = JFolder::files( __DIR__ . '/fields', $extension, false, true );
foreach( $files as $file )
{
JLoader::register( 'JFormField' . JString::ucwords( basename( $file, $extension ) ), $file );
}//end foreach
return true;
}//end function
I was close just going off of memory. The getField
method is the public API for what I was thinking.
Yeah you were close! Although the $form->getField( $name, $group, $value )
doesn't search by field type which would have been useful. I've had a look through the JForm class but don't think there is a public method available for what we need at the moment.
Hi There,
Sorry, kind of a newbie in Joomla dev. I wanted also to override some fields under /libraries/cms/form/field/ like user.php and it is not working when I copied this file and put it in my com_component/models/fields/user.php. Why is that?
Overriding fields under /libraries/joomla/form/fields/ seems to fine.
I'm sorry, I wanted to override and not extend user.php just because I am using BS3 and redirected all view html to a theme folder so it can be overridden. I hate seeing a code that returns HTML with it like the default Joomla form fields, but I LOVE Joomla :D. There is no way to override the HTML, well can be done with JS but...
Anyways, @mbabker, is there a way to overrides those fields under cms?
Thanks!
@bassmanpaul @frogydiak for 3.5 there are some changes so the fields that return html can be customized through JLayouts. Take a look at: #5871, #5654 and #5655. Also you can make a PR if you think that another form field should use JLayout.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-01-28 13:20:58 |
Closed_By | ⇒ | brianteeman |
Closing at this time - see comment above
The autoloader is able to load the form field classes in the cms folder because the folder path matches the rules. The ones in the joomla folder do not, so they have to be explicitly loaded. You'll need to override those classes in the CMS folder by overloading their paths in the autoloader with a
JLoader::register()
call.With that said, unless you have a very strong reason for doing so, I'd suggest not overriding core form fields and instead extend those fields in your own custom fields to add in your extended features.