Answers.Body: <p>The fix was to manually delete the templates_c directory.  Apparently, there were directories that the Debug mode delete method was not able to delete.  Some of those directories just happened to be the ones that contained the corrupted joomla.tpl compiled template and possibly other corrupted compiled templates were involved.  Also, there seemed to be an issue with Smarty overwriting the compiled template when I changed the normal/uncompiled joomla.tpl code.  Everything works now.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-08T17:22:55.393Z
Answers.Text: I'm seeing this issue on a couple of live sites one Wordpress and one Drupal, but both are on hardened Debian 7 OS. Deleting templates_c/* does resolve the issue, but does not fix the root cause. Can you confirm if this is still happening? We really need to find the root cause if possible. The owner and group are www-data with rwxrwx--- or 770 permissions (directories have X). The system umask is 0022. We may need a new question requesting the root cause?
Answers.UserDisplayName: Darren
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-08T17:29:18.883Z
Answers.Text: Newly created folders have 751 and new template files have 644 (owner and group are www-data).
Answers.UserDisplayName: Darren
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-05T20:16:55.857Z
Answers.Text: If you try to delete the templates_c directory with Debug command, you most likely will need 755 permissions on templates_c directory.  I believe Smarty recommends 755 on templates_c so that Smarty functions correctly.  Some times hardening makes automated tasks like updating impossible without manually doing it.
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-01T20:35:34.057Z
Answers.LastActivityDate: 2017-09-01T20:35:34.057Z
Answers.UserDisplayName: ermSO
Answers.Body: <p>That's a headscratcher for sure.  Here are some things to try:</p>
  
  <ul>
  <li>Review the log at <a href="https://civicrm.stackexchange.com/questions/15931/where-are-the-configandlog-and-templates-c-directories">ConfigAndLog</a> just after you load the Profiles page.</li>
  <li>I've seen this happen when your Resource URLs and directories aren't set properly.  Check both: <strong>Administer » System Settings » Resource URLS</strong> and <strong>Administer » System Settings » Directories</strong>.</li>
  <li>Check the HTML to see which div is missing compared to the demo site.  Knowing that will help someone who wants to look in the source code.</li>
  <li>You said you cleared caches - I assume that include removing <code>templates_c</code>.  If not, please delete that. Also check the permissions on <code>templates_c</code> to make sure this isn't a permission error on the compiled template.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-09T21:44:23.600Z
Answers.Text: Your answer has opened some new ways to look at this.  What should the permissions be on templates_c?  In Resources and Directories, I just have the standard short codes in place.  Should they be set to something specific?  If so, where is the best place to set them?  The div is <div id="crm-main-content-wrapper">
                                
                                              </div>  It is there, but it is empty.
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-10T15:59:49.537Z
Answers.Text: I'm surprised that crm-main-content-wrapper is empty but there's nothing in the ConfigAndLog log?  It's not important what the resources and directories values are, so long as they match (on Resource URL/path).  templates_c just needs to be writable by the web server user (usually www-data on Debian/Ubuntu derivatives, httpd on Red Hat and derivatives). If it's NOT writable, that will show up in ConfigAndLog logs.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-28T21:52:42.140Z
Answers.Text: There is nothing in the ConfigAndLog files.  I am pretty sure that the Resource URLs and Directories are set correctly because the rest of the site works.  The templates_c directory appears to be accessible because other files are being written there.  Where would I go to start looking in the code or HTML?  Because there are not any errors in the ConfigAndLog files, could this be a database issue (like something not set correctly) and then whatever query returns empty?
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-29T01:01:31.253Z
Answers.Text: Possible, but if so that's a bug - SOMETHING should show up.  To go looking in the code/HTML, I would turn on Debugging/Error Handling, then load the page, appending `&smartyDebug=1` to the URL.  You should get a list of PHP variables that were passed to the Smarty template.  Compare that to a working site (e.g. http://dmaster.demo.civicrm.org/civicrm/admin/uf/group?reset=1&smartyDebug=1).  It's likely that variables aren't getting populated.  Based on that, you can look at the files `templates/CRM/UF/Page/Group.tpl` and `CRM/UF/Page/Group.php`.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-29T15:37:09.090Z
Answers.Text: I did the Smarty comparision with the following site:  http://joomla.demo.civicrm.org/  To my untrained eye, the only variable that was suspiciously different was {config}.  In the demo site, the {config} starts out with CRM_Core_Config Object (117) and then list a bunch of info.  In my site, {config} is CRM_Core_Config Object (0) and lists nothing.  Is that an issue?
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-29T17:29:39.380Z
Answers.Text: It is!  I'm not sure how that's possible.  CRM_Core_Config should be populated at the very earliest stages of CiviCRM's page load.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-29T21:22:16.307Z
Answers.Text: How is templates/CRM/UF/Page/Group.tpl called?  My research led me to templates/CRM/common/joomla.tpl as being the main template.  However, my debug statements are not logged in the ConfigAndLog files, so I think another main template must be used.
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-30T18:31:43.943Z
Answers.Text: I also have noticed that my {$config} equals CRM_Core_Config Object (0) on other pages as well.  The other pages work however.
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-08T17:24:34.310Z
Answers.Text: The answer was to delete the files, but this is not a root cause fix. see comments to answer below. Seeing this on multiple sites, different CMS but same Debian based platform, all with seemingly correct permissions.
Answers.UserDisplayName: Darren
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-09T16:55:11.090Z
Answers.LastActivityDate: 2017-08-09T16:55:11.090Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>When I go to CiviCRM >> Administer CiviCRM >> Profiles it is blank.  How do I correct this?  </p>
  
  <p>I am running CivCRM 4.7.22 on Joomla 3.6.4.  I have cleared caches and rebuilt the menu.  There are no javascript errors in console.  I can add profiles when I edit contribution pages.  I can edit and create profiles when setting up contribution pages.  I need to go to CiviCRM >> Administer CiviCRM >> Profiles because according to my research that is where the settings are to add reCaptcha to profiles.</p>
  
  <p>UPDATE:  There are not any errors (404 or otherwise) in the Network tab of the browser dev tools.  Below is an image of what I mean by blank.
  <a href="https://i.sstatic.net/8Mqqb.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8Mqqb.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-09T05:19:50.190Z
Comments.Text: Could you please post a screenshot in case there's a clue?  "Blank" can meet a few different things.  Also, is there anything in the ConfigAndLog?  What about 404s in the Network tab of your browser's dev tools (F12)?
Comments.UserDisplayName: Jon G - Megaphone Tech
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-09T10:30:28.497Z
Comments.Text: I'm using Wordpress so Joomla may be different but Profiles in my case is under Administer>Customize Date & Screens>Profiles.  There you should see User-defind profiles and Reserved Profiles.  That is unless you've customised your navigation menu.
Comments.UserDisplayName: peterb
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-08T17:31:30.603Z
Comments.Text: Seeing this on live sites running Drupal and Wordpress. Debain OS, latest versions of Civi and CMS. No errors. Certain pages are blank. delete templates_c/* and it works again... until the next time. permissions on new folders are 751 and 644 for files. owner and group is www-data... May need to re-frame this as a new question.
Comments.UserDisplayName: Darren
Tags: <profile><joomla><administer>
Title: CiviCRM >> Administer CiviCRM >> Profiles is blank
ThreadText: # CiviCRM >> Administer CiviCRM >> Profiles is blank
  
  (Asked by: username_0 on 2017-08-09)
  
  When I go to CiviCRM >> Administer CiviCRM >> Profiles it is blank. How do I correct this?
  
  I am running CivCRM 4.7.22 on Joomla 3.6.4. I have cleared caches and rebuilt the menu. There are no javascript errors in console. I can add profiles when I edit contribution pages. I can edit and create profiles when setting up contribution pages. I need to go to CiviCRM >> Administer CiviCRM >> Profiles because according to my research that is where the settings are to add reCaptcha to profiles.
  
  UPDATE: There are not any errors (404 or otherwise) in the Network tab of the browser dev tools. Below is an image of what I mean by blank.
  [![enter image description here](https://i.sstatic.net/8Mqqb.png)](https://i.sstatic.net/8Mqqb.png)
  
  **Tags:** profile, joomla, administer
  
  > **Comments:**
  > **username_1**: Could you please post a screenshot in case there's a clue?  "Blank" can meet a few different things.  Also, is there anything in the ConfigAndLog?  What about 404s in the Network tab of your browser's dev tools (F12)?  
  > **username_2**: I'm using Wordpress so Joomla may be different but Profiles in my case is under Administer>Customize Date & Screens>Profiles.  There you should see User-defind profiles and Reserved Profiles.  That is unless you've customised your navigation menu.  
  > **username_3**: Seeing this on live sites running Drupal and Wordpress. Debain OS, latest versions of Civi and CMS. No errors. Certain pages are blank. delete templates_c/* and it works again... until the next time. permissions on new folders are 751 and 644 for files. owner and group is www-data... May need to re-frame this as a new question.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2017-09-01. Score: 0 | Accepted answer
  
  The fix was to manually delete the templates\_c directory. Apparently, there were directories that the Debug mode delete method was not able to delete. Some of those directories just happened to be the ones that contained the corrupted joomla.tpl compiled template and possibly other corrupted compiled templates were involved. Also, there seemed to be an issue with Smarty overwriting the compiled template when I changed the normal/uncompiled joomla.tpl code. Everything works now.
  
  > **Comments:**
  > **username_3**: I'm seeing this issue on a couple of live sites one Wordpress and one Drupal, but both are on hardened Debian 7 OS. Deleting templates_c/* does resolve the issue, but does not fix the root cause. Can you confirm if this is still happening? We really need to find the root cause if possible. The owner and group are www-data with rwxrwx--- or 770 permissions (directories have X). The system umask is 0022. We may need a new question requesting the root cause?  
  > **username_3**: Newly created folders have 751 and new template files have 644 (owner and group are www-data).  
  > **username_0**: If you try to delete the templates_c directory with Debug command, you most likely will need 755 permissions on templates_c directory.  I believe Smarty recommends 755 on templates_c so that Smarty functions correctly.  Some times hardening makes automated tasks like updating impossible without manually doing it.  
  
  ---
  
  ### Answer by username_1 on 2017-08-09. Score: 0
  
  That's a headscratcher for sure. Here are some things to try:
  
  * Review the log at [ConfigAndLog](https://civicrm.stackexchange.com/questions/15931/where-are-the-configandlog-and-templates-c-directories) just after you load the Profiles page.
  * I've seen this happen when your Resource URLs and directories aren't set properly. Check both: **Administer » System Settings » Resource URLS** and **Administer » System Settings » Directories**.
  * Check the HTML to see which div is missing compared to the demo site. Knowing that will help someone who wants to look in the source code.
  * You said you cleared caches - I assume that include removing `templates_c`. If not, please delete that. Also check the permissions on `templates_c` to make sure this isn't a permission error on the compiled template.
  
  > **Comments:**
  > **username_0**: Your answer has opened some new ways to look at this.  What should the permissions be on templates_c?  In Resources and Directories, I just have the standard short codes in place.  Should they be set to something specific?  If so, where is the best place to set them?  The div is <div id="crm-main-content-wrapper">                                                                            </div>  It is there, but it is empty.  
  > **username_1**: I'm surprised that crm-main-content-wrapper is empty but there's nothing in the ConfigAndLog log?  It's not important what the resources and directories values are, so long as they match (on Resource URL/path).  templates_c just needs to be writable by the web server user (usually www-data on Debian/Ubuntu derivatives, httpd on Red Hat and derivatives). If it's NOT writable, that will show up in ConfigAndLog logs.  
  > **username_0**: There is nothing in the ConfigAndLog files.  I am pretty sure that the Resource URLs and Directories are set correctly because the rest of the site works.  The templates_c directory appears to be accessible because other files are being written there.  Where would I go to start looking in the code or HTML?  Because there are not any errors in the ConfigAndLog files, could this be a database issue (like something not set correctly) and then whatever query returns empty?  
  > **username_1**: Possible, but if so that's a bug - SOMETHING should show up.  To go looking in the code/HTML, I would turn on Debugging/Error Handling, then load the page, appending `&smartyDebug=1` to the URL.  You should get a list of PHP variables that were passed to the Smarty template.  Compare that to a working site (e.g. http://dmaster.demo.civicrm.org/civicrm/admin/uf/group?reset=1&smartyDebug=1).  It's likely that variables aren't getting populated.  Based on that, you can look at the files `templates/CRM/UF/Page/Group.tpl` and `CRM/UF/Page/Group.php`.  
  > **username_0**: I did the Smarty comparision with the following site:  http://joomla.demo.civicrm.org/  To my untrained eye, the only variable that was suspiciously different was {config}.  In the demo site, the {config} starts out with CRM_Core_Config Object (117) and then list a bunch of info.  In my site, {config} is CRM_Core_Config Object (0) and lists nothing.  Is that an issue?  
  > **username_1**: It is!  I'm not sure how that's possible.  CRM_Core_Config should be populated at the very earliest stages of CiviCRM's page load.  
  > **username_0**: How is templates/CRM/UF/Page/Group.tpl called?  My research led me to templates/CRM/common/joomla.tpl as being the main template.  However, my debug statements are not logged in the ConfigAndLog files, so I think another main template must be used.  
  > **username_0**: I also have noticed that my {$config} equals CRM_Core_Config Object (0) on other pages as well.  The other pages work however.  
  > **username_3**: The answer was to delete the files, but this is not a root cause fix. see comments to answer below. Seeing this on multiple sites, different CMS but same Debian based platform, all with seemingly correct permissions.  
  
  ---
  
  