Changing Theme Style (sub-theme) does not work for AJAX pages

English Language - Forum SuiteCRM Themes
1

Hello.

I am using SuiteCRM 7.11.15 and have noticed a problem when I go to “Profile” -> “Layout Options” and change the “Style” (e.g. from “Day” to “Night”). For pages that don’t use AJAX (e.g. /index.php?module=Home&action=index), the new style is used, but for AJAX pages (e.g. /index.php?action=ajaxui#ajaxUILoc=index.php%3Fmodule%3DAccounts%26action%3Dindex%26parentTab%3DMarketing) it isn’t.

When I look at the network activity, the request for “/index.php?action=ajaxui” returns “304 Not Modified”, meaning that the browser will display the cached version of the page, which links to the previous “style.css” file.

Looking at the code, in include/MVC/View/views/view.ajaxui.php, it runs

     $etag = $user->id . $user->getETagSeed("mainMenuETag");
    generateEtagHeader($etag);

which is in include/utils.php:

function generateETagHeader($etag)
{
    header('cache-control:');
    header('Expires: ');
    header('ETag: ' . $etag);
    header('Pragma:');
    if (isset($_SERVER['HTTP_IF_NONE_MATCH'])) {
        if ($etag == $_SERVER['HTTP_IF_NONE_MATCH']) {
            ob_clean();
            header('Status: 304 Not Modified');
            header('HTTP/1.0 304 Not Modified');
            die();
        }
    }
}

However, because changing the sub-theme does not change the “mainMenuETag”, this always sends back the “304 Not Modified”.

Note that this only happens if the website has a valid SSL certificate, otherwise the browser discards the Etags.

Is anyone else having this problem, and if so, this there a work-around (apart from clearing the browser cache whenever you change the sub-theme)?

Thanks,

Carl

2

Maybe one of the options from Admin / Repair? Not sure which, though.

3

Hello.

Thanks for the response. Even assuming that one of the repair options does fix it (and I haven’t seen anything in the code that suggests that it would), it isn’t really a solution, as most users would not have the option to run it.

Regards,

Carl

4

Yes, you’re right, I just meant my suggestion as a work-around.

Can you make a fix for this? You seem to understand what’s going on.

5

Hello.

I made the following change to modules/Users/User.php, function saveFormPreferences(), from

if (isset($_POST['subtheme'])) {
    $this->setPreference('subtheme', $_POST['subtheme'], 0, 'global');              
}

to

if (isset($_POST['subtheme'])) {
    if ($this->getPreference('subtheme')!==$_POST['subtheme']) {
        $this->setPreference('subtheme', $_POST['subtheme'], 0, 'global');
        $this->incrementEtag('mainMenuETag');
    }
}

Seemed to work for me.

Regards,

Carl

6

Cool. Do you want to propose a PR on Github for that change?

7

Thanks Carbar,

This is what I was looking for to fix a bug in a custom business segment program I built with dynamic subthemes.

The bug is gone

$sql =
      "SELECT contents
      FROM user_preferences
      WHERE category='global' AND assigned_user_id= '$userID'";
$result = $db->query($sql);
while ($row = $db->fetchByAssoc($result)) {
    $prefs = array();
    $newprefs = array();

    $prefs = unserialize(base64_decode($row['contents']));
    $subthemeValue = $prefs['subtheme'];
    $newsubtheme = $prefs['subtheme']= ($subt);
    $newprefs = $prefs;
 $newsubtheme2 = base64_encode(serialize($newprefs));
 $update =
        "UPDATE user_preferences
        SET contents = '{$newsubtheme2}'
        WHERE category='global' AND assigned_user_id= '$userID'";

 $db->query($update);

        $current_user->setPreference('subtheme', $subt, 0, 'global');
        $current_user->incrementEtag('mainMenuETag');
        $current_user->reloadPreferences();

in short, I have a global value stream dropdown in the header, that users can select what value stream to enter records ( based on security privs). Each value stream has a different subtheme and a custom logo in the top left. the program and tags all worked great but every time I selected a module from the header the subtheme changed back to the first subtheme when the user logged.

… all that to say - this fixed it :smiley: