Direction of Plugin System

[internet54]

Chris,

I'm seeing many posts here of many wants for plugins. I know that plugins can help both developers and end users at the same time, but what should the plugins be geared more towards?

Just asking because we have a lot of developers here that are downloading the software. I don't recall seeing many end users on the forums. So it kinda brings up a crossroads in my mind. Where does the plugin development need to go initially? To whom should it benefit more?

I'm sure it depends more on the plugin type, but I hope you understand my comments.

Thanks.

[internet54]

I just reread and want to give an example.

I saw a post about adding a Google map plugin. This is great.
However, should the plugin be developed more towards the developer, or dumbed down to the end user?
If for developers, more functional. If for end users, easy to use, less complicated = less functionality.

[ccagle8]

I agree that most of us are developers, but while we are the ones downloading and installing the software, the eventual end-user will still be less savvy than us in terms of web know-how.

How you word and develop the UI of your plugin should always be clear and concise anyway no matter who is the end-user...

[internet54]

I understand.

Currently GS is being embraced by developers, but will there be a push to market to the end user?

[ccagle8]

Maybe... but then again everything goes hand-in-hand: more developers = more end-users knowing, using and understanding GS

[crashfellow]

An issue i've just come across is that because the plugin system has not been built using classes, the plugins are now at a large risk of breaking eachother.

If you think that a user installs 10 plugins.

One of those plugins has:

getData();

Another plugin has

getData();

They cause issues as the previous function has 'been declaired' (it shows up in debug mode) now i'm assuming this could become a larger problem down the line. How can this issue be dealt with?

[crashfellow]

Sample error:

Fatal error: Cannot redeclare function_name() (previously declared in /Applications/MAMP/htdocs/jmhconsulting.com.au/plugins/simple-analytics.php:30) in /Applications/MAMP/htdocs/jmhconsulting.com.au/plugins/simple-blog.php on line 68

[Nijikokun]

a: apply your plugin name to the functions:

Code:

twitter_get_data(); and maps_get_data();

b:

Code:

if(!function_exists('<my function name>')){ <my function> }

c:

build it as a class, which is completely doable.

A is how I do functions on NinkoBB to prevent collisions from happening.

[Zegnåt]

apply your plugin name to the functions is how I do functions on NinkoBB to prevent collisions from happening.

Pretty close to what I’m doing in a current plugin I’m developing too. I choose to prefix the function names with zegnat-, if anyone is going to use that they probably did not use it accidentally.

[crashfellow]

I actually tried writing my plugin as a class, but was receiving errors when attempting to use the class methods in the hooks.