vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vB5 Programming Discussions (https://vborg.vbsupport.ru/forumdisplay.php?f=263)
-   -   API Extensions (The New Plugin/Hook System) Question (https://vborg.vbsupport.ru/showthread.php?t=295669)

vbresults 03-02-2013 11:48 AM

API Extensions (The New Plugin/Hook System) Question
 
How can we intercept the methods we're extending, instead of having our extension methods invoke after the parent methods?

I.e.
PHP Code:

class Myplugin_Api_User extends vB_Api_Extensions {
    function 
save(...) {
        
// This executes after vB_Api_User::save does, meaning we can't change the output of the parent function directly...
        
echo 'Foo';
    }


Also how do I extend classes outside the vB Extensions Api folder, like controllers?

ForumsMods 03-02-2013 01:55 PM

Both are not possible for the moment.

vbresults 03-02-2013 09:08 PM

Quote:

Originally Posted by ForumsMods (Post 2407382)
Both are not possible for the moment.

... then how are we supposed to make mods without butchering the core software and making it difficult to install a mod?

ForumsMods 03-02-2013 09:28 PM

Well, for the moment, you need to find a way (workaround) to do what you want.

Maybe you can extend another method that is called before save() finishes.
Maybe, you can create another controller to do what you want.

If you explain what you want to do, we will able to be more help.

Limitations to modifying vB5
  • You cannot run any extension method before its main API counterpart.
  • You cannot stop or change core API calls (for example those that make database updates).
  • You cannot alter or hook into existing database queries.
  • You cannot extend library functions.
  • You cannot extend or hook into any frontend functions.
  • You cannot access the actual API variables ($this->xxx)
  • You can't extend any API call that was called by instanceInternal()
  • Cannot hook into [most] ACP functionality.

If you have any others, please post them

vbresults 03-02-2013 10:41 PM

Quote:

Originally Posted by ForumsMods (Post 2407450)
  • You cannot run any extension method before its main API counterpart.
  • You cannot stop or change core API calls (for example those that make database updates).
  • You cannot alter or hook into existing database queries.
  • You cannot extend library functions.
  • You cannot extend or hook into any frontend functions.
  • You cannot access the actual API variables ($this->xxx)
  • You can't extend any API call that was called by instanceInternal()
  • Cannot hook into [most] ACP functionality.

Jesus Christ! Why even have a modification system, then?

Thanks for this list, though. We just aren't developing any more vB5 mods until these things are taken care of.

ForumsMods 03-03-2013 12:27 AM

Quote:

Originally Posted by Paul M
With two completely new systems (to replace plugins and template hooks [v1]), its obvious that we are going to find limitations to what can be done.

You can vote in the issues created in Tracker to get these "bugs" fixed faster.

Ben.Smith 04-24-2013 10:21 AM

Hi,
i am pretty new to vBulletin as we got a customer who insists on using vB 5 Connect....

Having a quick look at the vB Code (horrible!), i came to the same conclusion: There is no good way of modifing specific behaviors in vB without making changes to the core files thus losing the possibility to upgrade.

Sadly vB missed to implement some kind of event/hook system (sorry but these Template hooks just don't give enough flexibility for big changes).

I went to make use of the existing autoloader and modified both - index.php and api.php to always look (following name convention) if there is a custom implementation of the loaded Class.

Now I can easily override every Frontend Controller and API Class to integrate my own logic.

Its not the best way, but as far as i can see its the only way to go right now.

Anyone here tried something like this before?

CvP 04-28-2014 07:51 PM

Can you share/explain this in detail?

Paul M 04-28-2014 10:54 PM

You realise that post is a year old ?

CvP 04-28-2014 11:26 PM

Yes, but even this would help more than the non-existing vb5 documentation...

YankForum 08-14-2014 08:50 AM

and still it's not possible to modify core methods and classes?
a child class can not be helpful here while i need to modify parent methods withough changing core files directly!

Paul M 08-14-2014 10:53 AM

No changes have been made at all as far as extentiosn etc are concerned.
Other things seem to take priority, so I doubt anything will change anytime soon.


All times are GMT. The time now is 03:38 PM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01229 seconds
  • Memory Usage 1,736KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (1)bbcode_php_printable
  • (3)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (12)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete