Miscellaneous Hacks - vbPluginOrder

Keywords: plugin, order, hook

Description:
A simple but potentially very useful tool that allows you to set the order of execution for plugins within the same hook.

Features:

• Fully Phrased.
• Set the order of plugin execution within the same hook.

Install

1. Download the vbPluginOrder_1.2.zip file.
2. Unzip and upload the files in the upload directory to your forum root.
3. Import the product file in your admincp.
4. Set the order for your plugins if needed and desired.

Notes:
If you have Hellcat's real time page compressor installed it must be set as the first plugin in its hook after you activate plugin order.

Version 1.2

• Fixed bug causing plugin order not to run on some systems because of cookie settings

Version 1.1

• Fixed nasty sql bug where I forgot to use TABLE_PREFIX for one join. Causes a problem if you have a table prefix (obviously)

[Marco van Herwaarden]

Thanks for providing this solution for members with problems.

Although your solution works, the proper way to disable all plugins from outside the ACP, is to add the following line to yhe includes/config.php:

PHP Code:

define('DISABLE_HOOKS', true); 


[Boofo]

That's what I just posted above, sir.

[akanevsky]

Although I could see how this hack could be useful, I'd like to point out two things:
1. It would encourage a bunch of already-lazy coders to NOT care about making their hack in a way that would guarantee absense of conflicts with other hacks.
2. Instead of creating a new table and having to implement a whole new block of code, you should've added a displayorder column to the plugin table and used that.

[hambil]

Originally Posted by Logician

Warning:
This hack causes serious problems if your board has table prefixes. If it is installed in a board where tables are prefixed, the board start producing DB errors and it won't even allow you to access admin cp and disable product. So if you dont know what you are doing, you'll get stuck in a very bad position.

Problem & Fix:

This query in the pluggin is problematic:

PHP Code:

SELECT p.*, po.`order` FROM " . TABLE_PREFIX . "pluginorder AS po
JOIN plugin AS p ON(p.pluginid = po.pluginid)
ORDER BY p.hookname, po.order 


It should be:

PHP Code:

SELECT p.*, po.`order` FROM " . TABLE_PREFIX . "pluginorder AS po
LEFT JOIN " . TABLE_PREFIX . "plugin AS p ON(p.pluginid = po.pluginid)
ORDER BY p.hookname, po.order 


If you installed the hack and stuck with an DB error and you can't even access admin cp here is the fix for you:

Edit includes/init.php, find:

PHP Code:

if ($vbulletin->options['enablehooks'] OR defined('FORCE_HOOKS')) 


Before that add:

PHP Code:

$vbulletin->options['enablehooks'] = FALSE; 


Upload init.php.

This will cure DB error and now you can login to admin cp. Go to products and uninstall the product. Now delete the line you edit to init.php, reupload init.php and you are done.

@hambil : Sorry to post this into your thread and I appreciate your sharing your work with other vb members but I feel obligated to post this so that people won't get into trouble. It maybe a good idea to apply the fix I provided to your pluggin. Sorry again!

This was one of my first hacks. I thought I'd fixed the table prefix issue in this - not sure how it crept back in. Anyway, thanks for pointing out. Perhaps a PM next time?

Edit: In fact I know I did - it's in the description of version 1.1. Somehow version 1.0 got reuploaded.

[hambil]

Originally Posted by Psionic Vision

Although I could see how this hack could be useful, I'd like to point out two things:
1. It would encourage a bunch of already-lazy coders to NOT care about making their hack in a way that would guarantee absense of conflicts with other hacks.

That's silly. You can't possible predict what conflicts your hack might have with other hacks. And this isn't just for conflicts. What if you simply want to re-order things on forum home, for example?

2. Instead of creating a new table and having to implement a whole new block of code, you should've added a displayorder column to the plugin table and used that.

That's your opinion. I prefer not to modify vb core tables if I can help it. The new table is indexed and performance is not an issue.

[akanevsky]

You can't possible predict what conflicts your hack might have with other hacks.

True, you cannot predict. But you can avoid altering vBulletin core with your hacks, which is what many coders do, and which is what leads to problems.

What if you simply want to re-order things on forum home, for example?

Last time I checked, to re-order things in the front end, you edit the templates. Templates, in their turn, do not have hooks so they have nothing to do with ordering.

That's your opinion. I prefer not to modify vb core tables if I can help it. The new table is indexed and performance is not an issue.

That's not just my opinion, it's a fact. "JOIN" always requires more from the server than a straightforward "SELECT FROM". However, it was only a suggestion. You're the boss of your hack, so you may or may not follow it, depending on what you want...

[hambil]

Originally Posted by Psionic Vision

True, you cannot predict. But you can avoid altering vBulletin core with your hacks, which is what many coders do, and which is what leads to problems.

Don't like my hack, don't find it useful, don't install it. Fine with me. I don't know why you feel you have to come in here and say so though. I created this hack because people requested, so obviously not all feel as you do. When did we start going into others hacks and publicly criticizing them?

Last time I checked, to re-order things in the front end, you edit the templates. Templates, in their turn, do not have hooks so they have nothing to do with ordering.

And then when you upgrade you have to re-edit all those templates.

That's not just my opinion, it's a fact. "JOIN" always requires more from the server than a straightforward "SELECT FROM". However, it was only a suggestion. You're the boss of your hack, so you may or may not follow it, depending on what you want...

It is most certainly an opinion, not a 'fact'. The cost of a proper join is nearly non-existant, especially compared to the design and maintainence benifits. It's called a relational database because it's designed for related tables, not flat tables.

[hambil]

I removed the old 1.0 zip and reuploaded the 1.1. zip. That should take care of the table_prefix problem.

[akanevsky]

Don't like my hack, don't find it useful, don't install it. Fine with me. I don't know why you feel you have to come in here and say so though. I created this hack because people requested, so obviously not all feel as you do. When did we start going into others hacks and publicly criticizing them?

To ensure that you aren't going to be criticized, don't release hacks.
Just to point out, however, I did say that I find how this hack could be useful.

And then when you upgrade you have to re-edit all those templates.

That, once again, has nothing to do with plugins.

It is most certainly an opinion, not a 'fact'. The cost of a proper join is nearly non-existant, especially compared to the design and maintainence benifits. It's called a relational database because it's designed for related tables, not flat tables.

I am not going to argue about it, I am just going to say that in my opinion, creating an extra field for just one table is a waste.

[hambil]

Originally Posted by Psionic Vision

I am only giving you suggestions. If you don't like people giving you suggestions, let everyone know publicly to rid yourself of it. Thanks for understanding.

Sorry if I over-reacted. I'm always open to suggestions.

I am not going to argue about it, I am just going to say that in my opinion, creating an extra field for just one table is a waste.

So noted