Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-02T01:38:56.773Z
Answers.Text: Good sleuthing.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-01T23:32:58.980Z
Answers.LastActivityDate: 2016-09-02T01:09:21.923Z
Answers.LastEditDate: 2016-09-02T01:09:21.923Z
Answers.UserDisplayName: inteja
Body: <p>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.</p>
  
  <p>The issue produces no network or console errors in either Chrome dev tools or Firebug. Turning on all the debug &amp; 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.</p>
  
  <p>I've found a few reports of something like this but none were relevant or provided solutions that worked in my particular cases.</p>
  
  <p><a href="https://civicrm.stackexchange.com/questions/4197/ajax-problem-in-civicase-administer-case-types">AJAX problem in CiviCase - Administer Case Types</a></p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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&amp; ...:</p>
  
  <p><a href="https://i.sstatic.net/CCh6l.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/CCh6l.png" alt="civicrm case type network activity"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-01T11:04:44.953Z
Comments.Text: Try /civicrm/menu/rebuild?reset=1
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-01T11:23:16.677Z
Comments.Text: Thanks for the suggestion @Demerit but it didn't work.
Comments.UserDisplayName: inteja
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-01T11:36:24.127Z
Comments.Text: 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?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-01T22:09:40.480Z
Comments.Text: 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.
Comments.UserDisplayName: inteja
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-09-01T23:10:22.673Z
Comments.Text: Based on the 302, try clearing browser cache, or does that web server have a cache server in front of it that needs clearing?
Comments.UserDisplayName: Demerit
Tags: <civicase>
Title: Case Type page blank
ThreadText: # Case Type page blank
  
  (Asked by: username_0 on 2016-09-01)
  
  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](https://civicrm.stackexchange.com/questions/4197/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](https://i.sstatic.net/CCh6l.png)](https://i.sstatic.net/CCh6l.png)
  
  **Tags:** civicase
  
  > **Comments:**
  > **username_1**: Try /civicrm/menu/rebuild?reset=1  
  > **username_0**: Thanks for the suggestion @username_1 but it didn't work.  
  > **username_1**: 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?  
  > **username_0**: 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.  
  > **username_1**: Based on the 302, try clearing browser cache, or does that web server have a cache server in front of it that needs clearing?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-09-01. Score: 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.
  
  > **Comments:**
  > **username_1**: Good sleuthing.  
  
  ---
  
  