Module does not receive `his` settings. about advanced-sidebox HOT 17 CLOSED

No each individual sidebox receives its own individual settings, just using the same box multiple times on the same script overwrites the template variable and therefore all the side boxes of that type (in the same script) will look the same as the last side box of that type.

I am aware of this and have an idea in mind to make multiple sideboxes of the same type with different settings possible. For now side boxes of the same type on different scripts with different settings are displayed appropriately.

Will work on this.

from advanced-sidebox.

EDIT: When modules return content instead of eval()ing then it will be relatively easy to handle this.

from advanced-sidebox.

I know templates are overwritten because all instances of module provide the same template name
because module is just one and always provide the same initial data for every instance.

Your class could ofcourse add prefix behind the scene, (module instance number)
so it could be 1_mytemplate, 2_mytemplate ect, and each instance of the same module
would use his own template.

But this is not a good idea, because it would litter template set with countless same-template
with numbers or ids and instead of making things easy it would confuse user.

Most of normal users have hard time understanding how mybb templating works by itself,
bits, variables and all this. Adding multiple templates for every module instance
would make him even more confused. Not mention its just hard to juggle with it and not get lost.

I know about templates problem, thought about it and have better idea which i will introduce to you later.

For now lets forget about overwriting templates (just dont solve it, and dont think about how to solve it
yet to not influence your way of thinking by this).

Lets concentrate on small bit.

• Module give to class its settings.
• class store it (forget about templates)
• they are instantiated because when you have many modules of same type and change
  setting of each then these settings are preserved.
  If you set options somemodule xxxx = 1
  and in somemodule xxxx = 2 then it is stored for every instance.

What im asking is why if its stored - and can be changed in ACP , its not send to module ?

I can see it in online staff module.

Btw, online staff module in feature branch is not yet fixed, i will fix it, and push to feature,
and when it will be fixed - you can use it to test and see what i meant.

Give me a sec, ill fix it, push and give you an example.

from advanced-sidebox.

Ok, i changed Online Staff module to show you working proof of concept
which may solve fiew issues at once in a easy way.

(when i think about it, fixing just one small bug in core would implement all these ideas at once)

• we know there is problem that, the same module used multiple times overwrite own template.
  There are many ideas how to fix it.
  One idea may require complex juggling with templates, other adding prefixes to templates, ect.
  But what we would get at the end is increased complexity, increased count of trashy multiplied templates
  for the same module hard to distinguish, which one belongs to which instance of module,
  confusing user at the end about 'its complex and why so many templates'

Fear no more - the solution is here - template can be stored within module instance and its setting.
No need to click anywhere, no need to navigate through templates, no need to worry 'which one is this one'
Its just here - You click on published module and taadaa - settings and template all in one.

What it need to implement ? - nothing, It is allready implemented !

• bug where module not receive its settings.
  Proof of concept show you very good, that every instance of the same module (Online Staff)
  have its own settings, template, and everythin.
  You can edit separately settings for each published Online Staff instance, set different settings to each,
  you may even make completly different template for each one.

And here is bug - core store and operate perfectly on all these settings but send to module just whatever ?
When it send $settings to module it should iterate throught them.
When invoking staff_online_box_asb_build_template($settings) it should send what it have
first time - settings for first instance, next time for next instance, ect.
Currently it does not iterate through stored settings - it just sending whatever 💤

• evaling in module ? Its actually solved - Im doing it in proof of concept Online Staff module.

When you fix this bug, it would solve most of issues.
No need anymore to worry about templates and how to store them for each module,
how to distinguish which template is for which instance.
It give ability to use the same module multiple times as almost different module
while changing only its settings through ACP.

• Oh and btw, templates just does not exsist (are no more used because thetre within module settings)
  so arrays which contain templates can be simply removed as not used anymore. (simple huh ?)

Here it is -
I made a branch with proof of concept Online Staff module, where this module use all these
features and solutions i mentioned above.

Since its proof of concept, i dont want to push it to your feature branch.

You can make your own testing branch and pull my proof of concept branch
to your testing branch and test it. Or simply download it from my testing branch.
Anyway you want.

Just get it, publish Online Staff module 3 times so you have 3 instances of this module and see for yourself.
They keep settings and templates for each instance, Core just wont send these settings but sending whatever.
You'll understand everything when you see it

btw, when you will test it, you will see 10 administrators online or similar thing,
dont worry, its not a bug. Its my debug feature which multiply each staff member x10
to test 'module bits output for more users online'. I just forgot to disable it lol.

There is

//  ====----
    $staff_online_debug = true;     // dev mode. Multiply staff member x10 for bits test.
//  ====----

you just can change it to false if you want : P

Proof of concept branch with Online Staff module is here

...and good news - your awesome updating option works very well.
i just updated module files and new settings appear in allready published modules without installation.
Good work 🙋

from advanced-sidebox.

Wow that was quite a lot to process. I'm sure I will need to read it a few times to fully understand.

From a first read I have questions but ill just wait till I be home and let the code explain it to me and then if I still have questions I'll ask then.

And I am afraid you are missing something individual boxes are given unique settings (in the Sidebox_handler used_box_types stores each different box in each script by sidebox id so individual settings can be sent) the problems isn't that settings aren't sent but that the same template variable is used for each side box.

In the end I envision side boxes returning HTML string to the handler and then has the handler directly alter cached themes (instead of adding template variables to the cached theme and eval()ing)

from advanced-sidebox.

I'm sure I will need to read it a few times to fully understand.

Not really. This is why i gave you working proof of concept.
Instead of reading just add Online Staff plugin 2 or 3 times and pretend as you would be user and try to customise each one differently in ACP. (it works, you can do this)

You will see by yourself everything what i said without reading it - that everything is working and all issues are allready solved in design.
It works in ACP very well. However when you go to frontsite you will notice that although you customised them
differently, they act like one. But its not modules fault. They show exacly what they receive - settings of only one of them, not each own settings. (but you just customised them in ACP so why ?)

In the end I envision side boxes returning HTML string to the handler.

This would strip from modules ability to process own data and becoming a module - not a static template,
therefore would render all idea about modules unnecessary.
Modules point of exsistence is becoming complex php code and thus having ability to process it.
having his logic and related settings in ACP.
Its custom boxes point to be simple template without settings.
Thats why there are 2 types - php addons with its files, and custom boxes - without file.

Module variables which he process and use are local to its instance this is why its possible to display many modules of same type with something different.
When they would return html, and core would have to eval it - it would not work,
because core would eventually have variables only for last one to eval it,
which would make it impossible to display each one differently.

from advanced-sidebox.

It works in ACP very well. However when you go to frontsite you will notice that although you customised them
differently, they act like one. But its not modules fault. They show exacly what they receive - settings of only one of them, not each own settings. (but you just customised them in ACP so why ?)

Because each addon module has its own template variable (the last variable that you eval() in _build_template()) and when multiple side boxes using the same box type are used in the same script the same template variable ($whosonline for example) gets eval()'d by the first module-- then the second module overwrites the information in the template variable and therefore both boxes display identical content (always defaulting to the last module of that type because it was the last the edit that variable)

In the way I hope to have the plugin working modules would not change or be removed, but rather they would use PHP to produce HTML (just like they do now) and then instead of eval()ing global variables modules would eval() local variables and then return the result back to Sidebox_handler object.

from advanced-sidebox.

I think this is good thinking and looks like you have done your homework, but I am afraid that I don't quite agree
with your methods.

While I can see that this method can work, I feel that it is unnecessarily awkward and hard to understand and maintain. Actually, I plan to change the module's settings from $settings[0] etc to $settings['adv_sidebox_max_avatar'] so that it won't be so cryptic. Passing the templates to _build_template() makes a lot of sense, but why not seperate it completely from $settings and send $templates as well?

I will definitely take all this into consideration and I really appreciate your hard work. Cheers

@WildcardSearch

• I just showed here that
  its possible to display the same module type multiple times, while preserving separate templates and settings for its each instance, and displaying it to user as separate pages with everything which belongs to this instance (module) rite in place.

Simple as - click module name - edit its settings (all rite in place) and click save.

If you have better solution to achieve such functionality while maintaining the same level of intuitive and easy usage
from user point of view then i will look forward to see it.

• 'about hard to maintain and cryptic'.
  I agree, i was also curious what is $settings[0] send from core, especially it didnt even worked...

Closing as rejected and droping idea.

from advanced-sidebox.

Okay I made a little progress and now I understand why you were getting invalid results in your tests.

In adv_sidebox_classes.php I am using json_decode() for the settings but forgot to use the force array option. This was passing some values to modules as arrays and others as a StdClass object. So in many cases modules weren't receiving any viable settings. (So apologies I just kind of misunderstood what you were saying)

That has been rectified and I am taking steps now to ensure that the core can handle sideboxes with missing information (and repair them inline) to make everything more seamless. It would be nice if addon modules pretty much 'handled themselves' . . .

I will push a commit tonight after I stabilize and check everything, but as of right now upgrade is completely functional (I started testing from 1.0 and up) and everything is solved except for having multiple modules of the same type on the same script.

About templates:

While it initially sounded attractive to eliminate templates, it has occurred to me that admin might like the opportunity to make changes to the templates. So maybe instead of doing away with templates, lets create a templatesgroup and just get them out of Global Templates for now and we can revisit this idea at a later date.

We are getting closer 😄

from advanced-sidebox.

it has occurred to me that admin might like the opportunity to make changes to the templates. So maybe instead of doing away with templates

It occured to me that you perhaps never checked 'proof of concept' code...
No one said to get rid of templates, and no one said it require additional coding.

I proposed to move templates into module settings and i did it in proof of concept, which proved to be

• easy and intuitive to use,
• every instance of module may have his own settings,
• each instance of module may have his own differently customised 'per instance' template.
• no thousands templates in Global Templates group, nor limiting usability one template for all instances.

As you see on picture...

But this is your project not my, and i understand that you have your own design plans.
Sorry for interfering. I have allready closed this topic and will not follow this idea.
Please continue in accordance with your plans.

from advanced-sidebox.

No I saw your module and found it very informative and helpful.

I did miss the fact that users can edit the template on add/edit though sorry and thanks for pointing it out.

Perhaps the add-edit page should have an advanced tab for settings and templates?

Please don't think I am being dismissive of your ideas. I just want to be sure we explore all options and thanks to your idea of the feature branch we are not in a rush. 😄

Let me get home this evening and do some code comparison and push a small update and we can continue this conversation.

Cheers.

from advanced-sidebox.

Please don't think I am being dismissive of your ideas.

I dont think you are dismissive.
I understand and respect that everyone have his own ideas, plans and beliefs about what is good for them or not,.
thus, if you noticed, because of this i dont even try to change anything in core to not interfere with your design plans.
I concentrate only on module-end side, which as addon, is outside of core.

About missed things.
Metaphorically speaking - Lets pretend situation that i need bread.
You give me box with nice bread inside. I say 'thanks' and then continue talking about how much i need bread.
Then you tell me gently - 'hey look whats inside the box i just gave you'...
So i reply - 'Oh, Yes! cool.., Youre the best, thanks' and continue talking 'that will have to go buy some bread'...
What would you think ? ... That 'she have good manners and said thanks, but not even checked whats inside'

I gave you working addon which use

• instantiated per module templates,
• instantiated per module settings,
• intuitive interface.
• practically all issues solved without need of changing anything in core except one small bug,
  which i leave to you, because its within core where i dont want to interfere with your design.

What im thinking is, you just simply ignored everything, not installed it and not tried what it do.
I believe that you read fiew lines of code, but because its not obvious what it do from just looking at diff log,
without installing it, you simply missed everything and talked about 'attractivenes of eliminating templates'...
while no one ever mentioned about 'eliminating templates'.

So, i dont feel that you dismissed my idea. I think that you simply ignored me totally
because you have your ideas and plans and dont need help nor cooperation from anyone.

At the end what i can do is - reconcile with it and not push. I did...
It is not my intention to change your project in anyway, to something you wouldnt like by yourself.

I turned passive and looking forward with interest what will come out from it,
without pushing any ideas anymore and leaving everything to you.
My next moves will depend on how flexible interface you provide to addons.

from advanced-sidebox.

What im thinking is, you just simply ignored everything, not installed it and not tried what it do.

Wow. I feel that these assumptions are unfair and certainly untrue. Your code is installed on a test board and a live test forum and I have gone through the diff report thoroughly. As I have already stated I found much inspiration in your ideas and will surely incorporate some of them but in the end shouldn't we be trying to improve this plugin rather than worry about who got their way?

So, i dont feel that you dismissed my idea. I think that you simply ignored me totally
because you have your ideas and plans and dont need help nor cooperation from anyone.

Double-wow. I have never ignored any suggestions from anyone much less ignored a suggestion from someone who has presented their ideas in such a way as you have.

As developers we must separate our personal feelings from what is logically sound. I have enjoyed collaborating with you but I must say that this correspondence has deeply hurt me to know that you think so little of me and to think that you feel that I lied to you when I told you that I tested your work.

Frankly this is too personal for me and I would ask that in the future we leave our personal assumptions out of these technical discussions.

With respect as always.

from advanced-sidebox.

Your project took important place in my heart, perhaps because of this i tried too hard,
while i should be more passive. Thank you for bringing it into my attention. I will treasure it as valuable experience and will put more importance into separating personal feelings from technical discussions.

Im pleased by your assertivity level and ability to handle such missunderstandings by redirecting it onto the rite path,
which we all agree with and appreciate.

from advanced-sidebox.

I'm very relieved to hear you say that, but please allow me to apologize for the earlier misunderstanding. When I spoke of the 'attractiveness of eliminating templates' I was referring to replacing MyBB standard templates with custom individual templates not eliminating templates entirely. I misspoke and that could have lead you to believe I had not explored your changes thoroughly.

On another note I am trying very hard to complete a commit but I haven't quite gotten there. Maybe tomorrow evening.

Added option to have custom titles for sideboxes, fixed upgrade (completely), installed a lot of foolproof stuff so that if a side box has invalid properties (settings, templates) defaults are used.

Back to the discussion.

My reluctance to make the change you are suggesting stems from something you mentioned earlier about the average admin not really understanding templates and how they work. It is my fear that over-complicating the interface may be a turn-off to inexperienced users.

The original plan was to spend most of the time in making the plugin easier to use, but instead I have become sidetracked by feature requests and my desire to make the plugin better. We must bring the focus back to ease-of-use as soon as we have finished the 1.4 release.

For this reason I want to propose that we change nothing else about 1.4 other than fixing bugs or changing existing functionality if it doesn't work in a way that makes sense (I can be bad on the details). So what I am saying is we make 1.4 release group permissions, individual settings, auto module upgrade and your updated Online Staff add-on module and then take the rest of the ideas (template replacement and anything else that comes up that isn't a bug or something minor we can squeeze into 1.4) and start using them as a talk-point for 1.5

You have shown me that you are by far the most experienced when it comes to HTML and CSS . . . you have shown me that you can take constructive criticism and that you have a very logical mind and a wonderful eye for detail. I would like to see you take a larger part in things and not a smaller one.

Again, glad we are seeing eye-to-eye again.

from advanced-sidebox.

glad we are seeing eye-to-eye again.

Im glad about it too 🙋

I have become sidetracked by feature requests and my desire to make the plugin better

I undertand it very well and with this reason in mind, im skipping a lot of my reports
to conserve your spirit and not distract you from your 'fun of work',
making sure to bring your attention only to absolutely necessary things,
which are 'missing but required parts of allready implemented features'. (eg. Issue #26 )

(...) have a very logical mind (...)

Thank you for your kind words. Its not like i like digging in details, (well i do but thats another story haha)

This 'logical way of thinking came from (or rather is enforced by) long experience in my primary work
which is mainly developing applications for operating systems, (and whats coming with it, dealing with
its end-users desires, issues, habits ect).

Webmastering came later as additional attractive possibility of extending developed applications range
beyoud its main platform by utilising networking, server side processing and web technologies.

Designing application that is one piece in mind, yet at the same time, its components are scattered across
multiple asynchronous, unstable in communication and completly different systems, platforms,
with its local rules, native technologies, and intentional bad habits of users who cause additional destabilization,
to integity of system as a whole body, as you could notice - enforce my way of thinking (designing),
to discover possible problems by looking far ahead into direction where current design leads.
It give me chance to take appropriate actions and change direction while its still relatively easy,
without need of scraping whole project, nor triggering current users anger by enforcing 'whole system to restart',
which when considering application as 'distributed processing technology' may be impossible.
This is why i see it 'important'.

You allready noticed in another topic that i think in such terms, and i must say, that you made me feel very comfortable when suggested to 'watch here and now' instead of looking too much ahead. I like it very much.

I trust you then.

thanks to your idea of the feature branch we are not in a rush.

Aww, thank you, but its not like really my 'idea'.
I just had dillema because its not good manner on github to push onto someones master branch
which is commonly used as release and shouldnt be worked on.
So i worried if you have by any chance 'working' branch (which is commonly known as 'feature')

I want to propose that we change nothing else about 1.4 other than fixing bugs or changing existing functionality if it doesn't work in a way that makes sense (...)

As you wish.

from advanced-sidebox.

thanks to your idea of the feature branch we are not in a rush.

Aww, thank you, but its not like really my 'idea'.

😄 I know but until you suggested it I had never even thought of it. Actually without you I would never even have done it because I wasn't even sure how.

I have another 12 hour day but this evening I can almost be sure that I will get a to a point that I can test thoroughly and commit-- and then you can find all the bugs (haha You miss nothing 😄 )

from advanced-sidebox.