New release slow?

Well my host said there’s nothing at all wrong with their server and asked me to do a tracert to the site........ so I gave up. I guess a reinstall is about the only thing I can do from my end.

Quote from: shamblett at Sep 19, 2008, 01:26 PM

OK found my problem :-

The function _fetch_remote_file on line 271 of manager\media\rss\rss_fetch_inc sets up the Snoopy client class to get the news feeds.

The Snoopy class needs to be told that you are behind a proxy, I added these two lines to this function :-

$client->proxy_host = "cngateway";
$client->proxy_port = 8080;

Now it works fine.

OK, I believe this should be configurable from the system config settings page, or even better picked up from the browser configuration.

I can file a bug for this if you wish if you could point to your bug tracking tool.

Good catch shamblett, thanks a lot!

Can this be detected and modified at install time?

It can if you can query the browsers settings somehow(not really a front end guy here), other than that you can always ask.

However, if your in localhost only mode say with no internet connection, unlikely I know but failures do happen and you may be just testing ,it may be better to somehow log into the manager with this turned off, maybe a parameter to say ’dont bother with the RSS feeds’ in the URL. When I’m just testing stuff I’ve found that really don’t need to load this feed every time I log in to the manager

Quote from: shamblett at Sep 19, 2008, 01:26 PM

OK found my problem :-

The function _fetch_remote_file on line 271 of manager\media\rss\rss_fetch_inc sets up the Snoopy client class to get the news feeds.

The Snoopy class needs to be told that you are behind a proxy, I added these two lines to this function :-

$client->proxy_host = "cngateway";
$client->proxy_port = 8080;

Now it works fine.

OK, I believe this should be configurable from the system config settings page, or even better picked up from the browser configuration.

I can file a bug for this if you wish if you could point to your bug tracking tool.

Hi just wanted to let you know that this helped me solve my slow manager issues.
This is on a local deployment using xampp on windows XP.
In many cases I would not necessarily get the time out error but just had to wait for over 20 seconds to login in the manager and whenever I was changing settings. Sometimes I’d get the error:

[tt]Maximum execution time of 60 seconds exceeded in .....\manager\includes\config.inc.php on line 61[/tt]

Upgrading to 9.6.3 rc2 did not help.
Reading your post I realised this was probably due to the fact that I am behind a proxy that requires authentication and that when saving configuration settings the manager redirects to Site> Home

I went into tools > configuration > site and cleared both fields for RSS Feeds at the bottom and voila, sorted!

I guess this would be something to document somewhere. Something I should describe on the wiki?

Additional point: could saving the configuration in the manager not just redirect to the configuration page?

Yes, I’ve raised http://svn.modxcms.com/jira/browse/MODX-355 about this. Clearing the feeds is OK to get you going but you of course also lose the updates from MODx, security ones may be especially important. I believe we should be able to configure a proxy somewhere in the settings but please document your findings, doing this will probably help installations behind proxies for now.

Thanks shamblett. Any code suggestions will not go unappreciated on this front.

Yes, no probs with the code it’s just deciding where we do it, we could ask for the proxy to be specified during install and put the params in the site_settings table, this will allow manager login to work first time, we could just put these on the system settings pane in manager, but you have to log in first to set them of course, maybe on first login we could not read the feeds and bring this to the users attention. The prob with the installation fix is its even more questions to ask the user, another thing we could do is query the browser settings to pick up the proxy settings automatically but we would have to do it for all types of browser and I’m not sure how to do this.

This little quandary is the gist of the bug report. I’m open to any/all suggestions here.

Once we have the settings of course we need to update the core so that components that recognize proxy settings use them.

Most of the time, it should just work as is I’d think. So here’s what I’d suggest:

1) Add the proxy settings to the installer anyway just for grins

2) Add a config_check warning if they can’t be read and offer a link to open the config settings pane.

3) Be able to disable them completely with a single on/off setting ... also be able to change the proxy settings here, too, in the event you’re doing a server move, etc.

Yes OK, I think I favour the installation method, we could put another page in, possibly between the database page and the final check page called
’Proxy Settings’, explain what its for and have text entry boxes for machine name, port and auth method. we could put these in the site_settings table with an on/off setting to enable them or not so they can be viewed and changed as needed. Then its just a matter of updating the code to use them if enabled.

I think this is safer, the problem with the config check warning is you have to get that far before the warning is displayed, if the page load times out because it can’t get the RSS feeds you may not get there. I’ll have a look at doing this.