vB5 Hooks only working when accessing by web browser, but not with Mobile Suite apps?

[vbSuperfan]

I just started developing a minimal vBulletin "product" for modifying some specific strings in posts on the fly, dynamically when they are being viewed.

Everything went really smooth at first, I found the hookFrontendBeforeOutput hook and successfully used it for this purpose.

BUT, when testing my product on my production forum, which also has Mobile Suite mobile apps connected to it, my disappointment was great when I found that the hookFrontendBeforeOutput hook was not called at all when viewing the site through the mobile apps, and thus these replacements didn't work there.

Also, I cannot seem to find any kind of equivalent hooks for use with the Mobile Suite apps (or more generally, such hooks that will execute on the API level, rather than the web browser frontend level)?

Is this true, that there are no such hooks that will work when viewing the forum through the Mobile Suite mobile apps?

In that case, such hooks should really be implemented as soon as possible, or the whole point of the Mobile Suite mobile apps are greatly reduced, since the content they display is not equivalent with the content displayed when accessing the forums by web browser, if any content changing hooks have been applied!

Wasn't the whole point of the new vB5 architecture, with the back-end API and all, to eliminate all such differences depending on the method of access to the forums?

[Wayne Luke]

That is correct. The Mobile Suite does not process hooks or even know about them. It only accesses the API functions within /core/vb/api. The mobile suite does not use the templates or phrases available in the AdminCP. The Mobile Suite is not developed to be extendable. The mobile suite provides two benefits...

1. The suite provides a presence in App stores.
2. It enables Push Notifications.

Using vBulletin 5 in a mobile web browser will provide the end user with an experience close to that on the desktop.

[vbSuperfan]

That is correct. The Mobile Suite does not process hooks or even know about them. It only accesses the API functions within /core/vb/api.

Ok, but shouldn't the code of these API functions be possible to extend with the extolled new vBulletin 5 class extension functionality then? Wasn't that the entire point of this new architecture, that extension developers would be able to extend any method in the entire code base (at the price of having to reverse engineer and familirize themselves with this entire codebase first)?

Are you saying that this would be possible or impossible? A straight answer would be much appreciated.

The mobile suite does not use the templates or phrases available in the AdminCP. The Mobile Suite is not developed to be extendable. The mobile suite provides two benefits...

1. The suite provides a presence in App stores.
2. It enables Push Notifications.

Sure, what I really don't understand though is why on earth these benefits would have to come together with the HUGE drawback of not being able to target the PHP code on the server side that handles the API requests from these mobile apps with the same kind of extendability as all other server-side PHP code in vBulletin 5 benefits from?

My goal or intention is absolutely not to extend the code of the Mobile Suite apps themselves, but rather just the same old PHP back-end code that has been possible to extend/hook forever, which the mobile apps just happen to be calling with their API calls in order to fetch their data from the database on the server-side!?

If there would for some reason be some artificial and seemingly completely unjustified limitation prohibiting such PHP class extension for exactly the parts of the server-side PHP code that handle the delivery of the content data to the mobile apps (contrary to all other server-side PHP code), may I in that case ask why?

Using vBulletin 5 in a mobile web browser will provide the end user with an experience close to that on the desktop.

Sure, but since the above-mentioned push notifications efficiently usher the user into the app's own GUI for viewing threads though, they will never be using the mobile web browser to view any threads from their mobile device either way, making this unfortunately irrelevant.