4

I want to add some inline help to the New mailing CiviMail. e.g. show a block on this page civicrm/a/#/mailing/12345

I've created my drupal block, set it to appear in the correct theme and set it to only display on this page: civicrm/a/#/mailing/*

However for some reason it won't show. I've backtracked and I'm able to get it to show up with this expression: civicrm/* but as soon as I add civicrm/a/* it doesn't work, just doesn't display

Any ideas about why this might be?

Thanks Peter

Improve this question

5 Answers 5

Reset to default
5

I think this may have something to do with the fragment identifier (#). This is typically used to link to a particular point within a page (an anchor). However, in this case I think it is being used by the JavaScript framework to indicate a particular page view. I guess that Drupal may not be able to process URLs like this.

Improve this answer
3
  • hey @William - have you had a chance to reproduce this? As the CiviCRM project is transitioning to AngularJS for all forms - we may need to rethink the # in its urls
    – KarinG - Semper IT
    May 18, 2016 at 13:33
  • @KarinG-SemperIT I haven't looked into this myself but it would be worth checking it out. Perhaps best to avoid the # if possible?
    – William Mortada
    May 18, 2016 at 14:34
  • I think you're correct - voted you up! And added a possible immediate workaround for Peter.
    – KarinG - Semper IT
    May 18, 2016 at 17:26
4

I think @William is correct - I just tried and I can't get a Block -> Visibility -> Pages -> Show block on specific pages -> Only the listed pages -> to show up on a #a URL (tried escaping the # - can't do it). civicrm/a* works - but then you'd be seeing it on all forms using AngularJS.

That's not good! Let's search JIRA CiviCRM for it - and if needed report it. I did have a client run into using #a on iOS/Safari - workaround at that time for to use Chrome - but this is a bigger issue.

Possible immediate workaround [I know not ideal] I suspect that you only have few people who can CiviMail -> put them into a Drupal Role of their own -> then:

  • use Region settings to only show this block to your staff in the CiviCRM theme
  • use visibility settings -> Roles -> Show block for specific roles
Improve this answer
3

Agree with Williams' description.

Other possible resolutions:

  1. Give some love and patience to planned updates for the form system. Right now, Angular pages are strictly SPA ("single-page architecture" -- "javascript handles the page routing") and they're not very hookable. Current plans for the next iteration provide more hookability and reduce the reliance on SPA. (Somewhat related: https://forum.civicrm.org/index.php?topic=36978.0 )
  2. Target the block at the base page civicrm/a. In the code for your block, use some Javascript to call setInterval() and periodically check window.location.hash; hide or display the desired block with $.hide() or $.show().
Improve this answer
3
  • Increase hookability for AngularJS forms: cool; yes I would love that! Ad 2: many Drupal blocks are not generated in code though - we must retain some way for Drupal blocks to be displayed via the Drupal Core -> structure -> blocks GUI - esp if we get to building public Contribution pages with AngularJS - b/c there you'd typically get all sorts of Drupal blocks added to such a CiviCRM page: like eg social media block; search block etc
    – KarinG - Semper IT
    May 18, 2016 at 23:06
  • Idle curiosity - any reason that the existing architecture of angular pages didn't include different urls? Would it be super difficult to just add in an extra path component after the /civicrm/a/ that is ignored by the angular code?
    – Alan Dixon
    May 19, 2016 at 14:25
  • That might work for some use-cases. FWIW, though, it would only display Drupal blocks that match the original path; when you navigate among different Angular routes (e.g. civicrm/a/#/abtest => civicrm/a/#/abtest/new => civicrm/a/#/abtest/1), that navigation is all client-side, so it would never ask Drupal to rerender the list of blocks.
    – Tim Otten
    May 19, 2016 at 21:55
1

Taking this in a slightly different direction - it reminds me that in general, CiviCRM urls are not very nice when it comes to Drupal, because Drupal doesn't like to pay attention to query strings. I wonder if there is a broader solution that also deals with this issue? I'd imagined that there's a simple Drupal hook that could so some rewriting in and out.

Improve this answer
0

I haven't tried this so don't know if it will work. But, I create URL aliases for my civicrm contribution pages so that when a user goes to those pages it's a nice pretty url instead of the long civicrm url. I wonder if creating a URL alias in Drupal and then using that alias as the URL for the Show only on this page would work?

Improve this answer
2
  • Unfortunately, that will not work - for the same reason (the # in the URL). Also for a new mailing screen - you can't URL alias that as unlike stationary contribution page URLs the id is generated as you create the new mailing: civicrm/a#/mailing/776 and then civicrm/a#/mailing/777 etc.
    – KarinG - Semper IT
    May 19, 2016 at 19:09
  • I didnt think about the id's changing. blah.
    – frTommy
    May 19, 2016 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.