Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 993
    • Issues 993
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • Core
  • Issues
  • #2012

Closed
Open
Opened Sep 10, 2020 by eileen@eileen🎱Owner

Document impact of css / html buttons merged to 5.31 that may require action by integrators

(from @andrewhunt in chat) PR #18410 just merged to master that changes how nearly all buttons in CiviCRM are formed. The good news is that buttons will look better, be easier to theme, and be handled consistently with things we make look like buttons. The bad news is that you may need to update your extensions to accommodate the change. You can read more details in the PR and the two earlier ones it referred to (changes were originally to come in 5.29, but it got deferred to early in the 5.31 cycle so there's time for everyone to accommodate them).

The most important change is that <input type="submit"> and <input type="button">

are replaced with

<button type="submit"> and <button type="button"> across the board.

There are three main ways you may need to accommodate this:

Check your CSS-style selectors. If you have something like $("input#mybutton").click(), it won't work anymore. Same with .crm-button input --the elements themselves are the wrapper now, so all those <span class="crm-button"> elements are toast. To handle the old and new ways, you might look for specific IDs, classes, names, and/or types rather than just switching input to button.

Check how you add buttons. The helper CRM_Core_Form::addButtons() has been updated to work the new way, so if that's all you do, you're safe. However, if you do something like

PHP $form->addElement('submit', 'submit_button', ts('Submit'));

You'll want to replace it with something like

PHP

$form->addElement(
  'xbutton',
  'submit_button',
  ts('Submit'),
  [
    'type' => 'submit',
    'class' => 'crm-button',
  ]
);

In your template, you won't need to add a wrapper, but if you don't give the element the crm-button class, it won't look like the others. Please note that xbutton is not a typo. Quickform, in it's wisdom, uses button for creating elements. You must use xbutton to create an actual . Check how you identify the button that was clicked. The text on an button is the value attribute, and if that button was clicked, the button's name comes through on the submitted params. However, a element wraps around the button text and may have no value. If there's no value, you won't see a value for it in the params. Instead of looking for this, you might consider using $form->controller->getButtonName() to identify the button that was clicked. That said, core now gives most buttons a value of 1 because there were too many instances where the code looked for the value in the params.

E.g. of code to change

Screen_Shot_2020-09-11_at_10.48.04_AM

e.g of backward compatible code change Screen_Shot_2020-09-11_at_10.58.14_AM https://gitlab.com/physician-health-program-of-bc/saveandnewcopy/-/commit/441a165ea1debf15c335f291d3251aecc68dc5f2

Edited Sep 10, 2020 by eileen
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#2012