-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to create custom FieldTypes, SettingTypes and RenderTypes without altering the UmbracoForms folder #13
Comments
Hiya @sussexrick, Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more. We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed). To open it this issue up again, you can write For example:
This will reopen the issue in the next few hours. Thanks, from your friendly Umbraco GitHub bot 🤖 🙂 |
@umbrabot still relevant The documentation still only describes putting views for custom field types inside the The location of custom views for setting types is not mentioned and I cannot see any mention of custom render types. |
I've noticed a similar issue to this when creating custom field types... during a project rebuild, any custom back office files are deleted due to the "ClearUmbracoFormsAssets" target in Umbraco.Forms.targets cleaning the entire App_Plugins\UmbracoForms directory. |
Just had a look at this - it is the case that a clean operation will remove the It looks like field type settings have always supported a full path to the view though, so you can specify a custom field type like this:
And so by storing any custom client-side files in a different folder within Do please let me know if you think we've overlooked something here though. |
@AndyButland Can you confirm that specifying the full path works for all three types? And can we get documentation updated with the recommended approach as it still says custom views go under App_Plugins/UmbracoForms? |
Hi @sussexrick - I've reviewed this morning and can confirm the following: Settings types These are the ones used to define the editor for a field type setting, e.g. the "Placeholder" value for the built-in "Short answer" field type. For these you can set a full path to a view file, so these can live outside of E.g.
Field types These are used when in the main area of the form designer to show a preview of how the field will look on the form. This is defined by overriding the
Render types These are used when viewing the entries for a form, to render out the field value. They are set by overriding the Here though a full path isn't supported - Forms is expecting just a name of a file here, and it's looking for it in I've tested a small update locally which will allow the following to work (and will PR and get this ready for the next releases):
Will also make sure the documentation is updated to reflect this. |
Also on a related note (although I appreciate may be a separate issue), custom form templates located in the Data/Templates directory are also cleared after a clean. |
Yes, noted @benjiew - am going to look also at modifying the "dotnet clean" target so we remove only the one we ship with. |
Observed using Umbraco 7.6.13 and Forms 6.0.8:
When creating a custom field type, the view for previewing the field in the back office has to go under
~\App_Plugins\UmbracoForms\BackOffice\Common\FieldTypes
.When creating a custom setting type, the view for the setting editor has to go under
~\App_Plugins\UmbracoForms\BackOffice\Common\SettingTypes
.When customising the display of a field in the entries viewer, the view has to go under
~\App_Plugins\UmbracoForms\BackOffice\Common\RenderTypes
.It would be better if these customisations could go under our own folder under
App_Plugins
or somewhere under~\Views\Partials\Forms
so that we don't have to modify the content of the Umbraco Forms plugin itself.The text was updated successfully, but these errors were encountered: