org.civicrm.bootstrapcivicrm required or not

[petednz]

https://github.com/veda-consulting/uk.co.vedaconsulting.mosaico/blob/master/info.xml has

org.civicrm.bootstrapcivicrm

but no mention elsewhere until i spot it at civicrm/a/#/status

Bootstrap required

Mosaico uses Bootstrap CSS. Please install the extension "org.civicrm.bootstrapcivicrm".

if so , do you mean https://github.com/civicrm/civihr/tree/staging/org.civicrm.bootstrapcivicrm

[petednz]

Version 1.0-beta1 on civi 4.7.14

[totten]

Yup, that's the correct extension.

[petednz]

so this should be in documentation somehow?

[petednz]

oh and flexmailer too now. at least flexmailer is packaged as an extension. if i understand (unlikely but ..) bootstrapcivicrm is not packaged as a standalone extension and thus some instructions would be helpful for those who don't understand how to grab it as an extension eg as a zip

[deepak-srivastava]

@totten,

Agree with @petednz. Dependencies should be well documented specially when its not a distributed one.

Ideally for end user we would expect mosaico extension build to be all in one package. Shouldn't extension build take care of these dependencies?

Other concerns are like - if there are changes in these dependency extensions, where do they get submitted.

[xurizaemon]

Can we help / how can we help get these extensions available as separate repos?

Currently Pete's discouraged from testing Mosaico and BootstrapCiviCRM because the process for installing seems like it would involve installing all of CiviHR. If the required components could be grabbed separately, we'd have at least one more integrator and probably a few more sites testing that functionality. Let us know how we can best help with this 👍

One idea is for us to split the existing civihr repo into separate extension repos; another might be to document the process for installing all of civihr and only enabling the Mosaico or Bootstrap components; another might be to provide canned links from the CiviHR or Mosaico READMEs to zipped copies of components you want people testing.

[veda-consulting]

@xurizaemon that would be amazing, I have the same concern as the maintainer of the extension. The reliance on CiviHR will mean hugely reduced take up so splitting is the only option. Unfortunately we don't have the bandwidth to carry this out, we're not HR maintainers as such so would be great if someone could step up and take that on.

[totten]

Short answer: I share the frustration about the Bootstrap component being in the CiviHR repo. This is something I've been working on recently.

Long answer: The Compucorp devs been pretty focused on CiviHR and haven't had time to split it out, so I've worked on this a few days now. It's slightly more challenging than you'd expect -- imho, we have an impedance mismatch between the developer workflows in the designer/Bootstrap/SCSS/NodeJS community and the workflows in Civi/Drupal/WordPress/PHP community. (Relevant high-level rambling)

On a concrete level, suppose you're writing a UI for CiviHR, Mosaico, CiviVolunteer, or somesuch. 95% of the UI is based on the Bootstrap styleguide, but the last 5% involves some new/special widget. You and I might say, "Screw it, that's just 5% of the UI, the cost-benefit of perfecting that widget sucks, so let's do something simple and live with weird padding in one place." The CiviHR crew, however, tends to be more exacting about layouts -- they'd rather dig into the Bootstrap SCSS ("variables" and "mixins") and use those to define their custom UI elements more precisely. Physically, this shows up when an extension (like bootstrapcivihr or styleguide or contactsummary) has its own SCSS files which reference other extensions (like @import "../../../org.civicrm.bootstrapcivicrm/scss/bootstrap/overrides/mixins/*";).

The near-term problem: if you move to another git repo, then the path references break and you can't build the SCSS files anymore. In my first two attempts to resolve this, I got my ass kicked by node-sass/gulp subtleties, but I think the third design from last night is going to get around those.

The long-term problem: the cross-extension references are a bit too precise, making it hard to mix/match different themes with different functional extensions, and my gut says the only real solution is to have an SCSS compiler available at install-time (i.e. scssphp or node-sass would become a hard dependency).

[xurizaemon]

Hmm ... OK. I think we're open to doing some legwork on this, but it seems like I won't help by jumping into it just yet.

Might be able to suggest an approach if you can show why bootstrapcivihr needs the mixins from bootstrapcivicrm. I'd expect the "interface" between the two to be -

• bootstrapcivihr uses class names from bootstrapcivicrm
• bootstrapcivihr then adds classes with overrides only

Concrete examples might help me if you got 'em.

[xurizaemon]

that extension (bootstrapcivicrm) is now in its own repository https://github.com/civicrm/org.civicrm.shoreditch

• https://chat.civicrm.org/civicrm/pl/65fpsxabfibdfdr6sh6qg9pfir

[petednz]

i think this can be closed. info.xml has been updated to require shoreditch instead

[deepak-srivastava]

thanks @xurizaemon, @petednz and @totten.