I don't see how unused dashboard widgets could affect this. You've said the problem is not page generation, but in the browser (Opera, FF, IE). Did you try profiling the code in Firebug? Did you check processor/memory usage on your browser computer? Did you incremently turn off different javascripts (starting with TinyMCE if you're using that plugin)?

I agree totally! I don't see how it could possibly have had anything to do with it. But apparently, killing those widgets = faster all round. Load times have decreased for single pages from around ~6 seconds to 3-5 seconds. The topbar isn't as jerky even on profiles fairly heavy on widgets (although it is still slightly jerky ... strangely, I think it's the messageboard plugin causing it - jerkiness vanishes when that widget is removed). But it's extremely minor compared to what was happening before.

TinyMCE is turned off; yes, And I've used Firebug to profile the code; the only issue it finds is in jquery. Which came with elgg, and is thus also present on my test server ... where I couldn't reproduce the profile issue. It's a bit confusing and strange, to be honest. :/

Memory is not an issue on my browsing machine. I have 8 gigabytes of RAM (obviously, running a 64bit OS).

I'm not getting how the redundant widgets were causing it, either, but it seems to have helped enormously all the same.

Okay. Had a backup of the database, so did some edits to make it fit the test server, imported it, and did some digging around.

This time, I managed to reproduce it. Two things appear to have combined. First, the redundant dashboard widgets. Second, a plugin: profile_up. When there were few widgets on site, profiles were fast and fine. Add a lot... and it slows down. Turn off profile_up, it's fine both ways.

On the upside, most of my users are pretty lazy and hadn't actually bothered to change from the default widgets I had set up. Problem is 100% fixed on the production server now, and on top of that, they're all now playing around with the widgets, at last.

I couldn't find the issue before in Firebug, though, which is strange to say the least.

I don't see how unused dashboard widgets could affect this. You've said the problem is not page generation, but in the browser (Opera, FF, IE). Did you try profiling the code in Firebug? Did you check processor/memory usage on your browser computer? Did you incremently turn off different javascripts (starting with TinyMCE if you're using that plugin)?

I agree totally! I don't see how it could possibly have had anything to do with it. But apparently, killing those widgets = faster all round. Load times have decreased for single pages from around ~6 seconds to 3-5 seconds. The topbar isn't as jerky even on profiles fairly heavy on widgets (although it is still slightly jerky ... strangely, I think it's the messageboard plugin causing it - jerkiness vanishes when that widget is removed). But it's extremely minor compared to what was happening before.

TinyMCE is turned off; yes, And I've used Firebug to profile the code; the only issue it finds is in jquery. Which came with elgg, and is thus also present on my test server ... where I couldn't reproduce the profile issue. It's a bit confusing and strange, to be honest. :/

Memory is not an issue on my browsing machine. I have 8 gigabytes of RAM (obviously, running a 64bit OS).

I'm not getting how the redundant widgets were causing it, either, but it seems to have helped enormously all the same.

Okay. Had a backup of the database, so did some edits to make it fit the test server, imported it, and did some digging around.

This time, I managed to reproduce it. Two things appear to have combined. First, the redundant dashboard widgets. Second, a plugin: profile_up. When there were few widgets on site, profiles were fast and fine. Add a lot... and it slows down. Turn off profile_up, it's fine both ways.

On the upside, most of my users are pretty lazy and hadn't actually bothered to change from the default widgets I had set up. Problem is 100% fixed on the production server now, and on top of that, they're all now playing around with the widgets, at last.

I couldn't find the issue before in Firebug, though, which is strange to say the least.

I don't see how unused dashboard widgets could affect this. You've said the problem is not page generation, but in the browser (Opera, FF, IE). Did you try profiling the code in Firebug? Did you check processor/memory usage on your browser computer? Did you incremently turn off different javascripts (starting with TinyMCE if you're using that plugin)?

I agree totally! I don't see how it could possibly have had anything to do with it. But apparently, killing those widgets = faster all round. Load times have decreased for single pages from around ~6 seconds to 3-5 seconds. The topbar isn't as jerky even on profiles fairly heavy on widgets (although it is still slightly jerky ... strangely, I think it's the messageboard plugin causing it - jerkiness vanishes when that widget is removed). But it's extremely minor compared to what was happening before.

TinyMCE is turned off; yes, And I've used Firebug to profile the code; the only issue it finds is in jquery. Which came with elgg, and is thus also present on my test server ... where I couldn't reproduce the profile issue. It's a bit confusing and strange, to be honest. :/

Memory is not an issue on my browsing machine. I have 8 gigabytes of RAM (obviously, running a 64bit OS).

I'm not getting how the redundant widgets were causing it, either, but it seems to have helped enormously all the same.

Okay. Had a backup of the database, so did some edits to make it fit the test server, imported it, and did some digging around.

This time, I managed to reproduce it. Two things appear to have combined. First, the redundant dashboard widgets. Second, a plugin: profile_up. When there were few widgets on site, profiles were fast and fine. Add a lot... and it slows down. Turn off profile_up, it's fine both ways.

On the upside, most of my users are pretty lazy and hadn't actually bothered to change from the default widgets I had set up. Problem is 100% fixed on the production server now, and on top of that, they're all now playing around with the widgets, at last.

I couldn't find the issue before in Firebug, though, which is strange to say the least.

Access control is stored in the database. The group has access and the individual forum topic has an access level. You'd have to determine what those are set at to determine one is going to the river and the other isn't.

It's possible that the river item access is set only on creation (changing the access on a forum topic might not change the access of the river item).

Cash, before I install your upgrade, every login user can see member-only topics. and now I got different result in two groups with same setting.

for example:

group A and group B are both closed, post a member-only topic the both two groups.

and the result is: every login-user can see the group A topic, the group B topic is hidden for not member.

After install your new upgrade, the new group is ok. I want to know if I can edit the database via phpmyadmin to change the old groups access right?

Hi Kevin,

Here's the procedure to make plugin settings go wild, if you can't replicate, i'll do a video to make it easier.

You need 4 plugins:

logrotate
event_calendar
izap_videos
siteaccess

Procedure is as follows:

1) Change the frequency parameter in logrotate and save.
2) Change anything in event_calendar
3) By now, Izap_videos lost its settings
4) change anything in izap_videos and save
5) After saving Izap, Site Access looses its settings (walled garden listing for example)

So this makes it even worse, because there is a chain damage effect.

The GUID Tool shows these elements:

[GUID:2554] ElggPlugin plugin izap_videos
by Uddhava dasa 5 minutes ago [Export Delete]

[GUID:2553] ElggPlugin plugin event_calendar
by Uddhava dasa 5 minutes ago [Export Delete]

[GUID:2552] ElggPlugin plugin logrotate

Then, after everything is lost, you can delete the izap_videos in the GUID tool , and your siteaccess settings are recovered (and izap settings lost again).

Regards,
Uddhava

@Uddhava dasa

I believe that I identified the problem above. There is a bug in Elgg 1.5 that causes Elgg to fail to manage plugin settings properly if you have more than 10 plugins installed. Curverider has already fixed the problem in SVN. If you don't want to wait for the next release, I suggested a fix myself above.

Ah Kevin ! Thanks for the help. It was a really weird bug to find.