-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
Update casing on setting metadata for html_type = text #13048
Update casing on setting metadata for html_type = text #13048
Conversation
We have conventionally 'preferred' quick_form_type but we we not 'prefer' the more generic html_type. We are fixing the places where the casing is inconsistent to support this
(Standard links)
|
Does this signal a change in the metadata format? What would be the implication for extensions which have similar metadata?
|
@totten nothing if they aren't overriding our inbuilt setting form (which it technically not supported) but if we find that once the core ones are done there is pain around extensions we can support the casing variant with a deprecation notice |
I just checked the first of these & it doesn't extend but uses a variant on the civixero form - which I would think is most common https://github.com/agileware/au.com.agileware.civiquickbooks/blob/master/CRM/Civiquickbooks/Form/Settings.php |
Ditto the second on the list https://github.com/agiliway/com.agiliway.civicalendar/blob/master/CRM/Calendar/Form/Settings.php |
OK - com.cividesk.email.sparkpost DOES extend the core form - I think I will do a PR against it - will check the last handful |
com.giantrabbit.civimailchimp doesn't |
com.joineryhq.activityical/ uses the CIviXero code |
com.joineryhq.percentagepricesetfield uses CiviXero code |
com.osseed.eventcalendar does not extend core form |
com.webaccessglobal.simpledonate extends core |
"extend core form" ==> I'd expect most extend I'm still updating my copy of
|
@totten yes that is helpful - The Fuzion one is probably not really supported but I'll do PRs against them all once we get into rc mode & have all the parts merged |
(I think can feel some personal shame on the Fuzion one - but in my defence that was a LONG time ago) |
@totten do any extend CRM_Admin_Form_Preferences? |
Happily, nobody extends Also, I updated Honestly, I think cleanup like this PR is good, but I'd advocate for the settings system to have a little automatic cleanup/normalization (and maybe status-check/deprecation-notice) for backwards-compat. It's going to be hard to coordinate code updates and deployments with that many extensions (esp. considering that |
Interestingly I downloaded https://github.com/systopia/de.systopia.donrec & checked & the form seems fine (uses select fields not text which seem fine) but it does have unrelated enotices where it has accessed a core function it probably shouldn't. Anyway once the last core PRs are merged before the rc I will do some more digging on the extensions & some more comms |
@mattwire please take a look at the above - for those extensions that DO extend the settings form I intend to do a PR against them with an info.xml change to 5.8 & change the extends to CRM_Core_Form wtih a use SettingsTrait I also think we should consider keeping 'wrong cases' working in core with just a bit of deprecation notice noise - but I propose to get the current PRs merged first |
@eileenmcnaughton Confirmed that without this PR some of the settings forms are broken (eg directories/resource URLS). With this PR they are fixed. I have come across this inconsistency with case before and don't really see why the html_type needs to be case-sensitive at all, but at least if it is going to be then it should be consistent (ie. all lowercase) as that seems more logical to a developer (otherwise you run into issues with things like "TextArea" or "Textarea". This PR needs to be merged as currently core settings forms are broken. But I would like to see a follow-up PR that relaxes the case-sensitivity requirement (with a deprecation warning is fine). |
@mattwire thanks - merging. I agree with your comments - once these are merged we should update docs & then look at casing |
I've added #13062 to switch to deprecation notices |
I created a PR against Mosaico here veda-consulting-company/uk.co.vedaconsulting.mosaico#276 I won't look at the others until my settings updates are made here civicrm/civicrm-dev-docs#555 & the Generic form is merged here #13054 |
Of the above Upshot - mosaico is hte only one of the above that seems to need updating for recent changes. I logged an issue for that A few others will have e-notices - that may or may not have preceeded recent changes - they are basically the systopia & cividesk ones. I have logged tickets against at least one repo for each of those |
@eileenmcnaughton we have already been operating under the assumption that com.aghstrategies.smartystreets may not work with 4.7/5.x - the client we built it for ended up discontinuing the service well before they upgraded. My expectation is that it shouldn't take much to make it compatible, but it's so dependent upon UI specifics that it would need attention anyway. |
@agh1 good to know - thanks |
Overview
Fixes an unreleased regression
Before
notices on urls screen
After
notices fixed
Technical Details
We have conventionally 'preferred' quick_form_type but we we not 'prefer' the more generic html_type.
We are fixing the places where the casing is inconsistent to support this