Fix Drupal Base 'isFrontEndPage' Returns Wrong Value After Saving A Settings Page
Overview
This PR fixed the way civicrm tells a civicrm page from a non civicrm page.
However when a settings page such as Civicase settings (civicrm/admin/setting/case), Mailing settings (civicrm/admin/mail) and most of the setting pages are saved, the CRM_Utils_System_DrupalBase::isFrontEndPage
function reports that the civicrm/admin
page redirected to after a setting is saved is a frontend page which could have a significant impact on functions that rely on this. For example, the shoreditch theme relies on this function to know whether the shoreditch JS and CSS assets need to be included for a particular page. This wrong value makes the shoreditch theme not to be applied after saving the settings page and the page is not shoreditch themed and loses the styling. Refreshing the page a second time however fixes the issue but this glitch needs to be fixed.
Reproduction steps
- On a site with the shoreditch theme active, edit a settings page and click save. The user is directed to the Civicrm admin page with shoreditch styles not applied at all. Refreshing the page a second time however brings back the expected styling.
Current behaviour
Expected behaviour
Technical Details
In the Post Process function for the Admin Setting form class which is the base class for most settings page, this line clears the db cache including the civicrm_menu
table. When the form is redirected to a new page after saving, the civicrm initialization calls the civicrm_html_head
function which calls this line in the function https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/DrupalBase.php#L662
, because the menu table has been cleared, the $item
variable is empty and the given path is returned as a frontend page, as a result, necessary shoreditch styles are not added.
Solution will be to add call the form's menu rebuild function here to rebuild the menu table after it is cleared, same as is done for few of the forms e.g the URL setting form which is why the few forms that implement this does not have this issue.
Will put up a PR to fix this. Just documenting this here.