[For 1.6] Advanced Sidebox 2.1.1

[mike537]

Glad this plugin has now been updated and more user friendly, excellent plugin and works brilliant on 1.6.9 version of MyBB.

So easy to use and customise, well done Wildcard for all your hard work

[Wildcard]

You're welcome.

Thank you for the kind words.

[bizzarela]

Hi awesome plugin you have here, one question. it is option to show sidebox in specific forum and post only??

[Wildcard]

That feature has been requested but we are still looking for the right way to implement it. Look for it to be added in a future version.

Thank you for your kind words.

[bizzarela]

That feature has been requested but we are still looking for the right way to implement it. Look for it to be added in a future version.

Thank you for your kind words.

Thanks for answer

[Wildcard]

No problem.

[avril]

Maybe we can give the admin control over which user groups show on Staff Online box so that custom groups can be added? (Just an idea)

Its completly independent from 'groups' now. - User may be in any group, including any of custom ones.

What is taken into consideration to recognize certain user as 'staff member' is his privilages.
He should have at least one of the following - become admin,
have privilages to moderate or access moderator panel,
or possibly even have no any special privilages but just become marked as 'staff member'
within ACP options 'show as staff member' (he will be shown then as 'other staff member')
No groups are involved here at all. Well, it inherits 'name styling' from groups, but thats all

All this and more is allready available starting from Advanced Sidebox 1.3.6 and up.

And as for the other proposed change I am not sure i understand the need completely but if Avril can help me to understand exactly what is beig asked for we will certainly give it a shot.

Um, im not really sure which feature its about, but if its the one about 'show boxes in certain
forum only or even certain posts' then it was more like 'loud thoughts' than a 'feature proposition'.
The meaning of this was 'not clear' because it was an idea with direct relation to XThreads in mind.
And XThreads by itself is 'not clear to understand'. Perhaps because its not really a plugin.
Its rather kind of powerful development tool in a form of plugin.

[Wildcard]

Its completly independent from 'groups' now. - User may be in any group, including any of custom ones.

[...]

All this and more is allready available starting from Advanced Sidebox 1.3.6 and up.

Just had a close look and I think you have done a wonderful job.

Thanks.

if its the one about 'show boxes in certain forum only or even certain posts' then it was more like 'loud thoughts' than a 'feature proposition'.

I thought it sounded interesting. I have never used XThreads but perhaps I am missing out . . . will give it a look this weekend.

As to ASB, I am trying to wrap my head around the best way to handle all these feature requests. It is my desire to separate the modules even further from the plugin, if that makes any sense. What I hope to achieve would be sideboxes that have settings rather than modules that have settings which transfer to the sideboxes created by that module.

I think core settings for sideboxes should include usergroup and theme (as standard for all types) and add forum ID as an optional default setting for sideboxes used in forumdisplay.php and TID options to sideboxes that are used in showthread.php

The problem I am having is that it doesn't make any sense to provide FID permissions to a sidebox that appears in index.php-- so fine, if a box isn't shown on forum then we hide that option, but what happens when boxes are set to appear of multiple scripts? How would a sidebox that was enabled for only 1 FID be handled when viewed on Index?

The first thought I have would be to only allow the box to be limited to certain FID's if it is only shown on forumdisplay (and likewise for showthread and TID restrictions), but wouldn't that make the interface a bit clunky and hard to decipher?

Just thinking out loud here . . .

[avril]

I could write here a lot of answers but after thinking about possibilities, features, solutions ect,
it all come to one thing which is path which must be finished first to answer these questions.

The thing is - continue to work on core, separate modules from it and expose to them easy to use,
foolproof expandable interface.

---

but wouldn't that make the interface a bit clunky and hard to decipher?
Just thinking out loud here . . .

<thinking out loud>
...aww, you just fall into common trap, in which every developer end up in sometime,
looking for most complex possible answer, because the simple answers are hardest for us

First - as i said, modules must be separated and have his own options. (look above)

...When its done, and modules dont add options to core options list (like they do now)
but instead have his own options pages, then you could continue reading.

(core point of view)
- core simply calls module to get his contents,
- module return 'false' instead of 'box contents' which meant 'nah, ignore me and dont display now'
- core ignores it and display only modules which returned contents.

(module point of view)
It have option in his option page (which is not even concern of core what it do)
and its simple textbox with comma separated tid's or fid's where it want to be displayed.
- module check if current tid, fid, is in his list and return contents or false.

...This not only not expose any interface on core side, but also not require any processing
from core itself.

I have never used XThreads but perhaps I am missing out ... will give it a look this weekend.

Dont do this XThreads is powerful and addicting thing and kind of a 'development tool'.
You may fall in love and forget about your projects.

[Wolfseye]

I hope you guys also add usergroup permissions for block view, and not just Forum or Thread permissions.