Disabling AjaxUI

[robert_sinclair]

Just a word of advice from those that have done it, have you seen any major side effects after disabling the AjaxUI? I’m afraid it will cause a lot of problems.

Unfortunately any sort of complex modification of the very top navigation header becomes very hard with this thing enabled, so I’m thinking of just disabling it altogether

[pgr]

I wouldn’t recommend disabling it, it’s been there for so long, and nobody is really testing SuiteCRM without AJAX… you wander off into uncharted territory.

I admit I am not very knowledgeable in this, but I believe you don’t need to turn off AJAX in order to use non-AJAX links. They can co-exist. So if you need custom stuff and don’t want to use AJAX, you just add non-AJAX links there, right?

[robert_sinclair]

Thank you for the reply. I’ll keep it in mind.

Problem is that with ajaxui enabled I can’t customize the header properly. It doesn’t read cookies and $_REQUEST in _headerModuleList.tpl and unfortunately it’s stalling the whole project, probably due to my lack of knowledge of JS, so I have no choice but to sail into the uncharted territory

[pgr]

What exactly are you trying to do in _headerModuleList.tpl?

If you work on the file that includes it you will probably have a better chance. That one is just a tpl, a Template. There is another PHP file loading it and constructing a page from it. That’s probably the best place to add JS stuff.

[robert_sinclair]

Hi

Thank you. More specifically I try to read the $_COOKIE that is set and also the value of $_REQUEST, it’s being invoked by the displayheader() function in sugarView class, but the problem is that it always displays the module as “home” no matter what page we’re on and I’m not able to read the $_COOKIE values. I’m sure it’s simple stuff for anyone that knows JS, I’m just very bad at it.

Guess I’ll be the guinea pig and if ever anything goes terribly wrong with AjaxUI disabled, I’ll report it here

[robert_sinclair]

so far so good, btw if anyone’s wondering where to disable it completely (don’t do this if you’re trying to disable it for specific modules), then you would do it inside the config.php file

and set the following to true like so:
‘disableAjaxUI’ => true,

P.S: loving the new forum format

[MadMart]

I personally don’t like the AJAX functionality. It feels like an SPA but it is still making full page requests in the background, it pulls the content area out of the response and updates the page with it.

SuiteCRM works in the exact same way with it turned off, and a few custom hand written modules I’ve come across don’t work with it switched on.

I’m currently looking for a way to programmically ban a module from using AJAX as it doesn’t appear in either the enabled or disabled list in the admin settings.

[MadMart]

I’ve found out how to do this after looking through the configureajax ui view.

in the config.php (or config_override.php)

look for the key ‘addAjaxBannedModules’.
this will be a list of modules that will show up in the disabled modules list.
you can add your own entries here.
It may even be better to do it this way, as I have over 200 entries for SecurityGroups alone

[pgr]

I’ve never - ever - disabled Ajax in order to get anything working in SuiteCRM.

Sometimes an error message comes up:

There was an error processing your request, please try again at a later time./ If this error persists, please have your administrator disable Ajax for this module.

… and, for me, this is a really unfortunate message as it is misleading, and I’ve never seen that the underlying problem was really something with the Ajax request. It’s always something else that is breaking the web request, it’s just that the web request happened to take the form of an Ajax request.

I am not saying that other people’s experiences aren’t real, I accept that if you had real problems and these problems went away by disabling Ajax, that might be a good option.

But I would always advise to try and look a bit deeper. If you understand what is going on with the view getting built, and what each request is doing, and making sure the correct parts of the view are getting returned, you should strive to keep Ajax enabled, it is saving you time and web bandwidth. This is surely relevant, at least if your installation is heavily used, with many users, etc.