1

This is super strange. We've tried the latest CiviCRM 4.7.10 clean installed on BOTH the latest Wordpress AND Drupal 7.50 and in both installations, going to Administer > CiviCase > Case Types results in a BLANK page titled simply "CiviCRM" (not "Case Types" as you'd expect) with the surrounding CiviCRM blocks, header and menu. This Case Types page seems to be the only one affected.

The issue produces no network or console errors in either Chrome dev tools or Firebug. Turning on all the debug & backtrace options of CiviCRM and Drupal devel also results in zero reported errors, but the Case Types page refuses to work. I've also tried disabling all browser extensions in case one was injecting HTML and screwing things up.

I've found a few reports of something like this but none were relevant or provided solutions that worked in my particular cases.

AJAX problem in CiviCase - Administer Case Types

EDIT: When I install exactly the same codebase on my local dev environment then the Civi Case Type page works as expected, so it's possibly an incompatibility with the remote server software but still very strange that I'm not seeing any error messages anywhere.

EDIT 2: PHP and MySQL are newer on the remote server than on my local. Also, the only difference I can see in the installations between my local and the remote server are that in my local I used a single database for both civi and drupal, whereas on the remote I used separate databases. But I'm not sure how that would make any difference.

EDIT 3: Compared network activity between non-working remote and working local and discovered this difference - the remote server is responding with 302 instead of 200 for the query rest?entity=CaseType& ...:

civicrm case type network activity

Improve this question
5
  • Try /civicrm/menu/rebuild?reset=1
    – Demerit
    Commented Sep 1, 2016 at 11:04
  • Thanks for the suggestion @Demerit but it didn't work.
    – inteja
    Commented Sep 1, 2016 at 11:23
  • I'm assuming there's nothing in either the civi or web server logs. If there is nothing, then are you able to trace the program flow, e.g. with xdebug?
    – Demerit
    Commented Sep 1, 2016 at 11:36
  • I've checked all the available apache and php logs. Turned on all debug and error reporting options of Drupal and CiviCRM, used Drupal's devel module with backtrace error reporting, used Firefox and Chrome dev tools etc. Haven't tried xdebug as have no experience with that, but as I said the same codebase is working fine locally with a single DB whereas the remote with 2 DBs isn't, so although it's a long-shot I might try installing with 1 DB remotely to see if that makes a difference.
    – inteja
    Commented Sep 1, 2016 at 22:09
  • Based on the 302, try clearing browser cache, or does that web server have a cache server in front of it that needs clearing?
    – Demerit
    Commented Sep 1, 2016 at 23:10

1 Answer 1

Reset to default
1

Seems like apache mod_security was the culprit. I deactivated it temporarilly and CiviCRM Case Types page works just fine. Now I need to find out exactly what rules are causing the issue.

EDIT: In my case I added the IDs for REQUEST-42-APPLICATION-ATTACK-SQLI to the ModSecurity whitelist and the issue disappeared. I realise this is probably not ideal - it would be better to write an exception rule just for civi queries, but that's beyond my current knowledge.

I think the CiviCRM dev or docs team needs to look into this as likely more people will have this type of server configuration by default.

Improve this answer
1
  • Good sleuthing.
    – Demerit
    Commented Sep 2, 2016 at 1:38

Your Answer

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

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