Announcement

Collapse
No announcement yet.

Is it possible to get the userID of the current vB5 user, without coding a full-fledged vB5 plugin/extension/product?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Wayne Luke View Post
    There are example products included in the vBulletin download package under do_not_upload/development. I believe there is a package skeleton available at vBulletin.org. You can also look at the /core/packages directory for examples. For your specific purpose, you will probably want to extend vB_Api_Bbcode at /vb/api/bbcode.php and/or the bbcode library class at /core/vb/library/bbcode.php.
    I've started trying to extend these classes in a product now, but something isn't working, because my extended code is never reached/executed at all.

    Is it even possible to extend classes that are not located in filed inside the /core/vb/api directory? Would these declarations still be on the form "productid_Api_Filename", or would it then be "productid_Library_Filename", or similar? Attempting to use "_Library_" results in the PHP error message "PHP Error: Fatal error: Broken Extension Class: myproductid_bbcode in ...\vb\api\extensions.php on line 312" though...

    My attempted extension declarations are as follows (I'm trying them one at a time, in a file called "api/bbcode.php" in my product package directory):

    Code:
    class myproductid_Api_Bbcode extends vB_Api_Bbcode
    {
       ...
    }
    Code:
    class myproductid_Api_Bbcode extends vB_Library_BbCode
    {
       ...
    }
    But none of them seemingly work. Even if I enter invalid PHP code, such as "whatever();" on a line in the methods I try to extend, nothing happens, not even an error, which indicates that these methods are never executed at all?

    The strange thing though is that if I write the extended method as follows (note the "string" part in the parameter declaration):

    Code:
    class myproductid_Api_Bbcode extends vB_Api_Bbcode
    {
       public function parseWysiwygHtmlToBbcode(string $text)
       {
          ...
       }
    }
    I then get a warning message as follows displayed at the top of the page in the browser when I load a forum thread:

    Warning: Declaration of myproductid_Api_Bbcode::ParseWysiwygHtmlToBbcode(string $text) should be compatible with vB_Api_Bbcode::ParseWysiwygHtmlToBbcode($text) in ...\packages\myproductid\api\bbcode.php on line 78
    That is, contrary to if I write as follows, when no such warning will be displayed:

    Code:
    class myproductid_Api_Bbcode extends vB_Api_Bbcode
    {
       public function parseWysiwygHtmlToBbcode($text)
       {
          ...
       }
    }
    So, this extension code is at least observed by the system at some level it seems, although not being executed for some reason?

    It's driving med insane that there isn't any decent tutorials for extension/"product" development for vBulletin 5, so that everything will need to be done fumbling in the dark like this.

    Comment


    • #17
      If you want things to be more consistent, you should probably look at altering the text on save/update rather than display.
      Translations provided by Google.

      Wayne Luke
      The Rabid Badger - a vBulletin Cloud customization and demonstration site.
      vBulletin 5 Documentation - Updated every Friday. Report issues here.
      vBulletin 5 API - Full / Mobile
      I am not currently available for vB Messenger Chats.

      Comment


      • #18
        Originally posted by Wayne Luke View Post
        If you want things to be more consistent, you should probably look at altering the text on save/update rather than display.
        As you can understand, that's not even theoretically possible for the functionality that I've been describing in this thead (displaying the user ID of the currently viewing user).

        If you have decided to implement this kind of complex extension system like you have in vBulletin 5 (which in itself is a good thing!), and also put a lot of effort into making an addon offering with mobile apps to view the forums (which in itself is also a very good thing!), you really should put some effort into the following two items too though, which unfortunately is extremely lacking for vBulletin right now:

        1.
        Documentation, examples and tutorials for actually using the extension/product system! There is an extreme lack of this right now, and the examples/tutorials available for the kind of extensions where classes are extended (i.e. the non-hook ones) are more or less non-existent right now, both on your site and on the entirety of Google, which practically means that more or less no-one has been able to get it working well, which seems like an extreme waste of resources from your side, i.e. to just ignore this last mile that could otherwise result in massive adoption and use of the new extension system in vBulletin 5!

        2.
        Now that you have made a new architecture in vBulletin 5, where you brag about it being "independent of which way you view the content" and all, the hooks available to extension developers MUST of course too be adapted (completed) to this architecture too! Otherwise you might at least be honest in the sales material for the Mobile Suite, and write "will not work for any site that makes use of the extension/product system of vBulletin".

        I will add a suggestion for such hooks in the tracker, but I'm afraid it will be too late for me when they are added, if ever.

        PS.
        To be honest, I cannot even imagine how to hooks are constructed in order not to work for both the web browser view and mobile app view of vBulletin forums, as I describe here, since, according to all material I have seen, both these scenarios make use of the same back-end API to fetch the data, and since the web browser view does this by means of AJAX, there are reasonably no places after that that any PHP hook code can be executed in the first place!? But still, the hook described in my other thread (hookFrontendBeforeOutput) obviously only works in the web browser view, how come is this?

        Comment


        • #19
          The Interface of the Mobile Suite resides on the device. It isn't retrieved from the server. It is a "thin client". All that is retrieved are JSON strings that are interpreted by the App on the device to display data. This is specifically obtained by using the code in the /core/vb/api directory. Which is documented here: http://vb5support.com/resources/mapi. All you would be able to modify is the data within the JSON string, not the actual structure of these strings. Doing so will probably cause the Mobile Apps to crash.

          This is different from the Web Browser version which must retrieve the Interface with ever page load. All the HTML and CSS. This is a much larger system using HTML, Javascript, CSS and the PHP backend. It is all the other code that is downloaded.

          Stating you need documentation isn't helpful. I have been asking people what kind of documentation they want since 2012. I don't get specifics or any answers to the question that can result in workable documentation. I have documented the both the API and the Mobile API (the two aren't synonymous) to give people information on them. However, you will need to know how to write advanced PHP code and read the files that ship with vBulletin to truly create professional products. I have gone above and beyond what is provided by Technical Support in your query. Technically, we're not suppose to answer any questions like this and shuffle you off to vBulletin.org where all modification discussion is required to occur.
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud customization and demonstration site.
          vBulletin 5 Documentation - Updated every Friday. Report issues here.
          vBulletin 5 API - Full / Mobile
          I am not currently available for vB Messenger Chats.

          Comment


          • #20
            It's worth noting the initial vBulletin 5 design eliminated hooks altogether. They were brought back on a limited basis after customers more or less threw a fit over having to code properly for API-based extensions rather than being able to use poorly coded hacks (or even decently coded) hacks. What Wayne Luke says above is 100% true and correct and if there had been an easy or even moderately easy solution someone would have posted it on your vBulletin.org question thread. There's simply no easy way to do what you're wanting to do and the information is already easily available by simply hovering over the user avatar or visiting the user profile. How many times does a user need to see their UserID to have it memorized? Enough to make all of this worth it? Possibly. I can;t speak to the necessity of a function for your forums. But you're jumping through hoops of fire to get there.

            Comment


            • #21
              First of all, just to be clear, it's not your support that I find lacking Wayne, on the contrary it is most often quite excellent!

              It's rather the extension developer offerings and their documentation in vBulletin 5 that I'm currently disappointed with, and this after having spent tons of ours both googling and experimenting myself with getting it working. And again, as mentioned previously, I am an experience developer...

              Originally posted by Wayne Luke View Post
              The Interface of the Mobile Suite resides on the device. It isn't retrieved from the server. It is a "thin client". All that is retrieved are JSON strings that are interpreted by the App on the device to display data. This is specifically obtained by using the code in the /core/vb/api directory. Which is documented here: http://vb5support.com/resources/mapi.
              Sure, and this would indeed be a very good design, if only extensions (most preferably, via hooks equivalent to hookFrontendBeforeOutput) could hook in on the server side, before the JSON content (e.g. the contents of posts etc) has been sent away to the mobile apps via API calls made from these, i.e., most preferably at a point in the code that is common between the web browser view and the mobile app view, more or less right after the post contents in question have been fetched from the database on the server side (which they of course need to be irrespectively of subsequently being viewed in a web browser or a mobile app).

              Originally posted by Wayne Luke View Post
              All you would be able to modify is the data within the JSON string, not the actual structure of these strings. Doing so will probably cause the Mobile Apps to crash.
              I'm not sure what you mean by this, but trust me, since it's vBulletin PHP code that is handling the server-side parts that are serving the content being served to the mobile apps via their API calls, there would be no problems whatsoever to offer hooks where this content (e.g. post content) could be allowed to be modified by the extension code in exactly the same way that can be done for web browser-viewable content via the hookFrontendBeforeOutput hook?


              Originally posted by Wayne Luke View Post
              This is different from the Web Browser version which must retrieve the Interface with ever page load. All the HTML and CSS. This is a much larger system using HTML, Javascript, CSS and the PHP backend. It is all the other code that is downloaded.
              Sure, and for this reason, the kind of hooks I'm suggesting would in many ways be even cleaner and simpler than hooking the entire HTML/CSS/data output like the hookFrontendBeforeOutput hook! Imagine e.g. a hook called hookPostContentsBeforeProcessing, which would give the extension developer the chance to modify the contents of posts just after they have been fetched from the database, before being sent to either the web browser view or the mobile apps via their API. It would be extremely simple for you to offer such a hook, and it would in turn offer both simple and efficient consistency for extension developers wanting to modify post contents on the fly, no matter where these contents are subsequently meant to be displayed.

              Originally posted by Wayne Luke View Post
              Stating you need documentation isn't helpful. I have been asking people what kind of documentation they want since 2012. I don't get specifics or any answers to the question that can result in workable documentation.
              In that case, I'm very sorry, and I'm hereby offering you some very specific suggestions for this:

              1.
              A number of complete and working examples of vBulletin 5 extensions, which all use different kinds of techniques (e.g. hooks vs class extension) for hooking a number of commonly desired points that extension developers want to be able to control, for example post contents, profile page contents, header contents, userbit contents, and BB code contents.

              There is one single example of class extension in the do_not_upload/development/samplepackages directory that you mentioned previously, and it mixes up hooks and a single class extension, which in turn is both quite obscure, and to make matters even worse, is then loaded and called explicitly with some special-case code from the other hook code of the extension itself, rather than being loaded automatically by vBulletin (i.e. like a "hook" or other modification of standard behavior would normally be, which I'm quite sure is what 90% of real-world extension use-cases are about). I was unable to get the information needed from it to be able to successfully implement any other class extension-style plugin/product, as described previously in this thread (and again, I'm an experienced developer!).

              The same goes for the Product Development Skeleton over at vbulletin.org. It extends the single class "vB_Api_Extensions", which I cannot figure out what it's for to begin with, since its documentation page completely lacks any kind of description for it, but rather only lists its methods etc. And also, it's not either an example of modifying the standard behavior of vBulletin, but rather just adding some new stand-alone module to it.

              The only other substantial example/tutorial for creation of vBulletin extensions/products that can be found is the blog post by Joe. It does a good job on showing the "administrative parts" of adding a product in the AdminCP, but then summarizes the whole development / class extension stuff simply with:

              The reasons why we are doing what we are doing here is out of the scope of this document- you will be able to find more info on the reasons as more info on vBulletin 5 modification is released.
              As far as I know, no more "info on vBulletin 5 modification" was ever released since then?

              Originally posted by Wayne Luke View Post
              I have documented the both the API and the Mobile API (the two aren't synonymous) to give people information on them. However, you will need to know how to write advanced PHP code and read the files that ship with vBulletin to truly create professional products.
              This is quite a big design problem in itself I think, i.e. the requirement from extension developers to first reverse engineer and completely familiarize themselves with the entire vBulletin code base before they can accomplish anything of value!? This, contrary to simply offer the poor bastards some well-defined hook-points to do their work, without having to become full-fledged vBulletin core developers themselves first?!

              Originally posted by Wayne Luke View Post
              I have gone above and beyond what is provided by Technical Support in your query. Technically, we're not suppose to answer any questions like this and shuffle you off to vBulletin.org where all modification discussion is required to occur.
              I'm very grateful for all support I'm getting from you Wayne!

              I would also happily be "shuffled off to" vBulletin.org if there were only someone answering posts there at all, but unfortunately, I've been unable to get useful answers to more or less any single question I have asked there. That forum seems to have quite a severe lack or active experienced users, and perhaps most of all, salaried such that actually have the time to answer anything more than very simple questions, even if they indeed in many cases both could and want to I'm sure.

              I think you would need a development support forum yourself here on vbulletin.com, with salaried staff such as yourself, which would have one or more experienced developers answering questions within well-defined bounds, e.g. no questions like "I want an extension that does X, could you send me the code for that?", but absolutely answering questions like "I have tried to get a hook/class extension working as described in the documentation X, and here is my code for it, but my class extended method code never executes though, what could the problem be?".

              Again, all I want is to be able to hook-in to create a BB code that does some custom PHP work on the server side for me (just like the BB code in previous versions of vBulletin, which could execute custom PHP code to generate its output), and other BB codes obviously work in the mobile apps, so this is indeed not any kind of theoretical impossibility it would seem? You even mentioned yourself some classes to extend previously in this thread Wayne, and all I'm asking is some short hint on how to actually extend these in a plugin/product, since my own code, put together using all the knowledge that could be gathered from the existing examples I describe above, is apparently not being executed at all as would be expected.

              Thanks again for your support!
              Last edited by vbSuperfan; Mon 26th Aug '19, 4:10pm.

              Comment


              • #22
                Hooks are limiting. They are a very specific location within a method in the code. They can't be used anywhere except that one line where they are called. They are implemented for the Web Interface and client.

                You can request a very specific hook down to the line number of the method and file where you want it located. If the use case is seen as satisfactory, it will be reviewed and assigned to a version for implementation. Most hooks are easy to implement. If the hook is denied, then there may be explanation on how to implement what you want in a proper fashion.

                The developers don't regularly visit this forum. They don't visit vBulletin.org at all. Personally, I would prefer them spending their time on resolving issues as we don't have a large development team. When we had a large development team, it lead to a lot of problems that the current team spends a decent portion of their time trying to correct today.
                Translations provided by Google.

                Wayne Luke
                The Rabid Badger - a vBulletin Cloud customization and demonstration site.
                vBulletin 5 Documentation - Updated every Friday. Report issues here.
                vBulletin 5 API - Full / Mobile
                I am not currently available for vB Messenger Chats.

                Comment


                • #23
                  Originally posted by Wayne Luke View Post
                  Hooks are limiting. They are a very specific location within a method in the code. They can't be used anywhere except that one line where they are called. They are implemented for the Web Interface and client.

                  You can request a very specific hook down to the line number of the method and file where you want it located. If the use case is seen as satisfactory, it will be reviewed and assigned to a version for implementation. Most hooks are easy to implement. If the hook is denied, then there may be explanation on how to implement what you want in a proper fashion.

                  The developers don't regularly visit this forum. They don't visit vBulletin.org at all. Personally, I would prefer them spending their time on resolving issues as we don't have a large development team. When we had a large development team, it lead to a lot of problems that the current team spends a decent portion of their time trying to correct today.
                  Discussions about the ability to manage a large developer team or not aside, support and product development are completely separate things, and if you put resources into offering extension abilities for you product, providing support for it is also both reasonable and recommendable, that's all I'm saying.

                  I have now requested a hook for filtering post contents, common for all content, no matter if it is being viewed through the mobile apps or a web browser. Let's see what happens.
                  Last edited by vbSuperfan; Mon 26th Aug '19, 4:08pm.

                  Comment


                  • #24
                    Originally posted by In Omnibus View Post
                    It's worth noting the initial vBulletin 5 design eliminated hooks altogether. They were brought back on a limited basis after customers more or less threw a fit over having to code properly for API-based extensions rather than being able to use poorly coded hacks (or even decently coded) hacks.
                    I think that this condescending tone against hooks is quite unnecessary and unfair. Simply overriding class methods is actually in many cases less powerful than a well-placed hook, depending on how the class methods in question have been implemented. If the functionality you're wanting to "hook" is baked-in in the middle of such a class method's code, you have a big problem, since you can only add code either before or after the entire overridden method executes when overriding/extending methods like this.

                    In addition, as mentioned previously, it also necessitates all extension developers to become experts on large parts of the entire vBulletin code base before being able to know what to extend/override to begin with, which constitutes a huge time investment that many will not have.

                    The best thing would no-doubt rather have been to keep all the old hooks in place, and then add the more generic class extension ability on top of it. Both methods have their advantages and their disadvantages, and they can never fully replace each other. Neither does either one automatically have to constitute more "poorly coded hacks" than the other.


                    Originally posted by In Omnibus View Post
                    What Wayne Luke says above is 100% true and correct and if there had been an easy or even moderately easy solution someone would have posted it on your vBulletin.org question thread. There's simply no easy way to do what you're wanting to do
                    What is the definition of "easy" here? I'm a good coder, so that won't be a problem, if I could just get some pointers regarding which classes I should hook/extend (since I am unfortunately unable to invest the time needed to learn the entire vBulletin code base by heart at this time), and exactly how vBulletin requires me to hook/extend these (since there are very few examples and very insufficient documentation available regarding this, and the little code and explanations that I have been able to extract from those few existing examples don't seem to produce working overrides after all for some reason).


                    Originally posted by In Omnibus View Post
                    ...and the information is already easily available by simply hovering over the user avatar or visiting the user profile. How many times does a user need to see their UserID to have it memorized? Enough to make all of this worth it? Possibly. I can;t speak to the necessity of a function for your forums. But you're jumping through hoops of fire to get there.
                    It's fully understandable that you cannot foresee the necessity of this. Allow me to explain this a little bit then, in order to eliminate your suspicion that I'm stupid and/or doing unnecessary things:

                    Since the mobile apps do not include the vBulletin cookies with iframe requests to the same server/domain that the forum is hosted at (as a normal web browser does when viewing the same threads), I'm unable to resolve which vBulletin user that is loading the iframe content when a user views a thread from the mobile apps (until my improvement request regarding this is hopefully implemented, at least). Since I need to know this (in order the perform customization and access control checks for the contents displayed in these iframes inside the posts), my plan B is to explicitly send the user ID of the current user as an HTTP parameter to the page being loaded inside the iframe (or actually, in order to avoid any foreseeable unnecessarily distracting security-related comments, it will be AES encrypted with a secret static key shared only with the second script that will be displayed in the iframe, in order to avoid the possibility of someone being able to predict this parameter value for other user IDs than their own, thus being able to impersonate other users in regards to the content displayed inside the iframe). Thus, I'm not really meaning to display it to the user, but rather, nesting my custom BB code into the parameter section of a second BB code that will in turn insert the iframe into the post. Displaying the user ID to the user was just an over-simplified example used to explain what I wanted my custom BB code to output.

                    I hope that this explanation can be considered satisfactory in the way of eliminating the most severe suspicions of stupidity and unnecessity on my side, allowing us to rather discuss the central issue instead.
                    Last edited by vbSuperfan; Mon 26th Aug '19, 4:06pm.

                    Comment

                    Related Topics

                    Collapse

                    Working...
                    X