Forums

Slow page load times for users logged in to dashboard

Permalink
ProEvents creates links with absolute addresses that cause slow down for off site users who are logged in to the dashboard.
Calls to packages/proevents/elements/header_menu/proevents/view.js and view.css are addressed using the server's IP address rather than the URL of the website. The result is off site users who are logged in to the website experience a wait of 15s - 2m+ depending on the timeout settings on their browser.
This effects every page load.

The developer ChadStrat says 'the API call for those header nav items are actually generated by the core, not the package. So if this is truly the bog down of your site, then you will want to contact the core team on this issue. '
 
mnakalay replied on at Permalink Reply
mnakalay
Hello,

I am a bit surprised by what you're saying. Concrete5 is definitely responsible for adding js and css files to the header or footer depending on what's asked. It does it with relative paths though, not with absolute paths.
Also it certainly doesn't use the server's IP address.

On the other hand Chad is one of the most respected developers of this community so he wouldn't make stuff up like that.

Would you have a link to the site where that happens so we could have a look?
Emloo replied on at Permalink Reply
Thanks for getting back to me. The URL is:http://www.heckgrammar.co.uk/online/...

If you look at the Calendar Events block on right you should be able to see that there is a broken image link next to where it says get iCal link. This shows the URL formation that the block is generating for the dashboard navigation item. I would rather not provide log in details for the Dashboard on this public forum, but if you want to log in to it I can provide them via PM.
mnakalay replied on at Permalink Reply
mnakalay
From what I can see, your base url seems to be set to that ip address so that's a concrete5 setting that needs changing. If you're not sure how to that you can PM me your login details if you want
Emloo replied on at Permalink Reply
I have set the BASE_URL previously which caused a redirect loop, so currently there is no setting for the BASE_URL at the moment in site.php. Is there another place I should be setting the base URL?
mnakalay replied on at Permalink Reply
mnakalay
it looks like something is wrong in your site. Like if a setting somewhere was throwing things up. The only reason Concrete5 would use that IP address as the base url is if it was defined that way somewhere. You have to find where. Maybe in the database in the config table or maybe somewhere else.

You might also want to check your htaccess
Emloo replied on at Permalink Reply
I have checked the .htaccess files and searched the database, there is nothing in the Config table in the database. The only place that the string appears is in the logs. Searching for the string within files in the website directory only returns the backup SQL files.

Would Concrete5 be picking it up from somewhere else?
mnakalay replied on at Permalink Reply
mnakalay
The code in Concrete5 defiining the value of BASE_URL is
if (!defined('BASE_URL')) { 
   21     if(isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on')) {
   22:       define('BASE_URL', 'https://' . $_SERVER['HTTP_HOST']);
   23     } else {
   24:       define('BASE_URL', 'http://' . $_SERVER['HTTP_HOST']);
   25     }
   26  }

I did a little research and $_SERVER['HTTP_HOST'] should return the domain name if there's one or the IP address if no domain name. In your case it is only returning the IP address.

I did a little research and it seems you might have to contact your host and look into it as it might be a server's configuration problem.

I found those 2 links that you might find useful
http://stackoverflow.com/questions/2883868/retrieve-domain-name-ins...
https://www.drupal.org/node/1943772...
Emloo replied on at Permalink Reply
Ah well, that could be a feature rather than a bug. There is already a server on our domain with the URL as its name which is running the old website as well as hosting essential things in sub directories, so I could not use the URL as the server name.

Strange that the ProEvents and ProNews blocks are the only ones effected by the issue. All other components show a relative address.

I will have to wait for the time when moving the Concrete5 site over to the named server is possible to be rid of this issue by the sound of it.
mnakalay replied on at Permalink Reply
mnakalay
it's not so strange actually. Because proEvent is using some icons that are in its own package folder, usually that calls for an absolute path. I think there are ways around it though.
Emloo replied on at Permalink Reply
OK, I'll have a look into that. Thanks for your help!