I have discovered the way to add custom fields to the Student Application but I am trying to figure out a way to rename and hide/remove fields that are on the application that we do not need or use.
A few of these are: Citizenship Passport Number, United States National ID Card Number, United States Residency/Visa Type, United States Visa Expiry Date
Could I just hide them through CSS or since some of them are required would I then get an error message?
I would be open to using a form builder like jotform.com but I would much rather either build a Module for gibbon or use an override to change the existing form. I just want the changes to the form to be saved if we upgraded to a newer version of Gibbon.
If I wanted to rename Surname to Last name (for example) could I do it through a language file or whats the best way to do a simple rename?
Many of the application fields can be enabled/disabled in the User Admin > Application Form Settings page, always good to check there first. You’re right though, these particular fields aren’t in the settings. It doesn’t look like the ones you’ve listed are required, so CSS would likely work to hide them.
What you could do to ensure the changes aren’t overwritten is to place the CSS inside tags and add it to the Analytics section at the very bottom of System Settings. Anything in this box is added inside the <code class="CodeInline"><head> tag, so it’s a slightly-sneaky way of modifying the css without losing the changes from version to version. This isn’t a perfect or long-term solution. What we can do is add the citizenship fields you’ve mentioned to a feature-request for future versions (the current version in development is pretty far along, but we could add the request for v16).
You can rename something like Surname to Last name using options under Admin > System Admin > String Replacement. This lets you specify one string to replace with another without needing to edit the language files.
Thank you for the feedback. I really appreciate your help. I will try these things and get back to you.
I feel like what is missing for us is a type of form builder.
Obviously some of the core fields would always be required but they could be renamed perhaps with a “Form Builder” interface. Just a quick search came up with Vfront.org and formtools.org. - My request would be to have something like this added but I know this is a much larger request. I have a developer who may be able to help with this too…
At minimum it seems like all fields that are not necessary should be able to be unchecked (Turned off) and not shown on the form at all. Eventually the system should probably have a way to rename them. (for now we can do it as you suggested) Would this be feasible for v16?
I see you guys are kind of going in this direction with “Manage Custom Fields” but I feel like this interface and the existing fields may make more sense to be in one place where you can see the required fields, rename them and then add more.
I am creating a new Discussion about auto importing data
After digging a little more it is apparent that hiding some of these fields is going to be tricky to hide as these is no CSS class or ID attached to the TR…
I was able to hide the input field by specifying #languageThird {
display:none;
}
Then I had to do a String Replacement for “Second Language” and just put a space. This is definitely a hacky way to do things. It would make more sense if the code had class defined for each of the 's? Or ideally a checkbox for each field to hide it in the Admin section.
How else could I hide these and also how can I hide the required fields?
This is as close as I can get it using String Replacement and CSS display none for the input id/name.
Is my only recourse after this to simply hack the code? I am open to doing that but its going to have to be done each time we update I assume?
From what I know so far - My suggestion is 2 parts.
Part 1. Offer class names for each of the sections of the forms so we can easily hide individual fields.
Part 2. Offer overrides of any of the system files in the themes folder. This way when you update something it does not overwrite any patches like this created.
Example: inside /themes/MyTheme would be a /override folder and I could duplicated a system file into this directory and change it and then it would not get deleted when I updated. /override/modules/Students/applicationForm.php
(should I put these in feature request?)
Of course after an update we would still have to verify everything is working in our override but it would cut down on the work considerably.
I will keep digging for solutions but if you have anything that would help us hide these fields for now and then easily do it again next update that would be lovely thanks!