Plugins open source

[Teg]

I think it would be a good idea to either require plugins to be open source or have some of the admins build open source plugins as a learning base for users who wish to learn to make them. I'm having a hard time wrapping my head around building them and I do know JS. Just a thought.

[Brian]

Hi, Teg.

For the most part plugins utilize Javascript in a completely standard way. When you add items to the user interface their respective variables are populated in the sidebar of the Components tab when you're building the plugin, after which you can insert them into the Javascript component of your plugin using the Insert button.

The only part that's a bit different from writing a normal script is the use of plugin keys. The most basic application of keys is to set their values or get their values. They work similar to standard Javascript variables, only you can dynamically save over their value and reference it on any page the item the key is tied to is accessible on. The basic functions used to write to keys and to get their values can be found here: support.proboards.com/thread/433198/all-plugin-keys

Jordan made a couple videos a while back detailing the basic construction of a plugin which can be found here: support.proboards.com/thread/433706/video-plugin-tutorial

[Azy]

Definitely DEFINITELY Echoing Amanda's plea for OS plugins. Here's my take on it (TL;DR I don't like plugins)

Plugins are brilliant (when they work), they provide enhanced functionality to a forum that would otherwise require lots of additional coding in JavaScript or Jquery, or might not be possible at all. But plugins are these mysterious black boxes filled with magic that we plug into our forums, and they work. But we don't know how they work. We don't know what they're doing back there, and ultimately we have to place our trust in these plugins, and the authors that code them, and hope that nothing bad happens.
On more than one occasion, I've gone to a forum (A proboards forum, I may well add) and have received an ad popup which takes me to a different site. A redirect, if you will.
No, not the ad redirects of "that" episode, this is different, this happens on my PC, with an ad blocker enabled. Also going back on the site doesn't re-launch the ad, so it's very difficult to reproduce.
Is it really the plugin doing this, or something else nefarious? Who can say?! The source code is hidden from us, we can't debug it ourselves, we don't know how it works or why. Ultimately we can't learn from this. So you need to make sure the author is still active and still providing support (and I've seen cases here before where an author has stopped supporting a plugin, leaving people up in arms), you need to make sure the author is reputable, and woe betide anyone who tries to install a plugin on anything other than a fresh default theme. Woe indeed.

If the plugin was open source, we could put it in our forum, and if it goes tits-up, as these things are wont to do, we debugger it ourselves. Instead of one person, one author, providing support, we have LOTS of people, all working together. We can take a simple plug in, have a look at the source code and LEARN from it! is there reference material online anywhere on how to build Proboards plugins? If there is, I haven't come across it. What better way to learn a thing than to poke around under the hood. Learning by doing. It's how I learnt 99% of what I know today, by the way.

Learn by doing, learn by experimenting, make plugins accessible to the masses.
We are truly in the Information Age, and Proboards is a fantastic fantastic resource for learning many aspects of web design and programming. Let's make it even more fantastic-er.

Thanks for reading! (this was longer than even I expected!)

Chris
~x~

[Brian]

Nov 9, 2015 12:57:59 GMT -8 Azy said:

On more than one occasion, I've gone to a forum (A proboards forum, I may well add) and have received an ad popup which takes me to a different site. A redirect, if you will.
No, not the ad redirects of "that" episode, this is different, this happens on my PC, with an ad blocker enabled. Also going back on the site doesn't re-launch the ad, so it's very difficult to reproduce.

In that particular case wouldn't that be the responsibility of the staff on that forum to debug rather than yourself?

Apart from cases where a user can input a URL to an image or another external object plugins submitted to the library are forbidden from having external dependencies, so no plugins you install from the library should contain anything such as an embedded script on an expired domain that triggers a redirect.

Nov 9, 2015 12:57:59 GMT -8 Azy said:

Is it really the plugin doing this, or something else nefarious? Who can say?! The source code is hidden from us, we can't debug it ourselves, we don't know how it works or why. Ultimately we can't learn from this. So you need to make sure the author is still active and still providing support (and I've seen cases here before where an author has stopped supporting a plugin, leaving people up in arms), you need to make sure the author is reputable, and woe betide anyone who tries to install a plugin on anything other than a fresh default theme. Woe indeed.

Assuming you know how to debug Javascript you should also know that it's a client-side programming language, meaning that none of the source Javascript can be hidden from you. In order for a browser to run Javascript it has to be embedded on the page somewhere. Regardless of the build restrictions put in place by an author the Javascript that makes the plugin run is accessible when accessing the plugin's JS file found in the source.

There's a really easy solution to determine whether or not a plugin is causing a problem similar to the redirect problem that you described: temporarily disabling the plugin. If the problem goes away you've pretty much nailed the culprit.

It's actually not that difficult to build a theme that doesn't sacrifice the HTML that produces the default theme. You just need to add on to it rather than removing critical parts of its foundation (not to mention doing the latter also runs the risk of breaking the default ProBoards Javascript as I've seen time after time, so it's not just plugins you have to worry about). There is literally no way for plugin authors to account for every single possible forum layout which is why they're built upon the default layout to ensure compatibility with the vast majority of forums on our service.

Plugins are submitted to the library on a voluntary basis. If an author is no longer available to provide support for their plugin there's not really much we can do about that. Like, I can't demand that Peter dedicate more of his time to something he created in his free time without any sort of compensation and then threaten retribution if he doesn't come through. That's not how any of that works. He's not contracted to us in any way and certainly not obligated to maintain support.

Nov 9, 2015 12:57:59 GMT -8 Azy said:

If the plugin was open source, we could put it in our forum, and if it goes tits-up, as these things are wont to do, we debugger it ourselves. Instead of one person, one author, providing support, we have LOTS of people, all working together. We can take a simple plug in, have a look at the source code and LEARN from it! is there reference material online anywhere on how to build Proboards plugins? If there is, I haven't come across it. What better way to learn a thing than to poke around under the hood. Learning by doing. It's how I learnt 99% of what I know today, by the way.

Plugins are built using HTML, CSS, and Javascript. Assuming you're proficient in all three of those languages you should have no problem creating a plugin if you understand the concept of how each of those languages works.

For ProBoards-specific stuff we have the Javascript API which documents publicly available functions: www.proboards.com/developer/js

I understand that what you're likely looking for is a "start to finish" guide that explains everything there is to know about plugin creation. The fact of the matter is that a plugin is only a container for the three aforementioned languages with a user interface section where whoever uses your plugin can populate your plugin's Javascript variables with their own data. If you don't know each language used to build the plugin you'll hit a wall almost immediately because the majority of plugin creation involves the coding aspect, not the creation of the user interface. The majority of authors who have released plugins on the library go into the Build page possessing prerequisite knowledge of the languages necessary to build what they need.

It's one thing to document the interface of the plugin Build page, but how far should the reference material reach? There's only so much that can be covered without actually having to teach the underlying languages that produce the plugin in the process of teaching the interface. There are already several notable sites that do just that as those languages are not specific to ProBoards alone.

[mmhmm]

I'd think this might be a problem if the plug-in writer didn't want his/her coding to be open source. Some don't mind, but others do. Since they wrote the code, I'd think they'd have a say in making it open source. Just my thoughts on the issue, though.