hacks -> plugins

hi,

everybody around here is complaining about upgrading, and installing hacks.

on the other hand, software like vbulletin literally LIVES by these hacks: they bring Ideas for the next versions of vB and also give webmaster the feeling they bought a deeply customizable software.

Well I think it's about time, the developers stop talking of "hacks" and should start refer to them as "plugins".

We need standartization like a plugin-libary in the controlpanel (where all hack shave to enlist themselves with version number if they want to appear profesional) and some install-routines. Also a documentation if the database model and the variables to help developers.

I know this is hard work to implement - but this in my eyes would be the key to ...ehm... simply rule the internet forum-software market.

think about it.

[chrispadfield]

This is what is uses at cgi-resources and it is a good idea but i think probably not appropriate here.

The reason is to have a decent plugin system you need to use hooks. Every time a certain action is done, the script looks in the plugin library for anything using that hook, if it find something it excecutes that code if not it dosent.

A very simple example for links SQL that uses this system is search logging. When someone comes and searches they get returned a list of links. There is a "hook" after searching which a plugin can use. So was born the search logger, it literally logs a search term into a table and is called by a hook.

Why won't this work for vbulletin

- the number of hooks needed would be ENERMOUS! There are far far more actions in vbulletin than in links SQL which has maybe 6 or 7 visitor paths.
- Efficiency. This is essential in vbulletin and a plugin system would add a lot of strain to the system.

So that is why i don't think plugins like this (using hooks) will work.

So what can you do?

An auto installation routine that searches the php files and installs the hack automatically is possible but hacks will conflict and it won't last long.

In the end the system we have at the moment, although not perfect, is the best you are going to get. Fortunatly the hack writers here write the most amazing documentation for their hacks, just look at Kier's, waynes, ed, etc... hacks they all have copious installation instructions and sometimes screenshots as well helping you install the hack - you can't ask for much more.

A plugin system would be nice but is impractical for this application (IMHO).

[Wayne Luke]

Actually after a brief look of code, you would only need to track 7 events for the major sections.

These events are:
InitSystem - Initialize the page in Global.php
Session - Verify or start a new session, get user info.
Templates - Building the global templates. (headinclude, header, footer, phpinclude)
InitPage- before you start parsing code for the actual page.
DisplayPage - code to be executed during the display of the page.
AfterPage - code to run after page is displayed.
ShutdownSystem - Very last thing to do.

The major sections would be:
Index page
Forumdisplay
Showthread
NewPosts
Calendar
User Control Panel
Private Messages

The API is in functions.php, it only needs to be documented. As do the global variables such as control panel options, $bbuserinfo, $session and the few global templates.

The function calls can be stored in the database (49 rows or thereabouts). The appropriate function can be eval'ed based upon section ids and location.

Some Cons:

1. If enabled it would add one more query to the rendering of each page to pull out the function identifiers in each section.
2. The system would also not fit every single scenario and complex features would most likely still require hacking.
3. A plugin development kit would have to be made to lesson the likelihood of errors killing the system.
4. Improved error handling within vBulletin itself would need to be created to handle errors passed back from plugins.