Home » php

Tag: php

How to run vBulletin 4.x on PHP 7.3

Upgrading vBulletin 4.x to run on Php 7.3 it is not easy, but it is possible. 

Unfortunately, there no one-button-click fix that can do this update for you. You have to be a PHP developer yourself or hire one. I have already done this for a friend of mine, so I know from experience that it is possible. I can say that it is worth it, especially for the performance boost that you get with PHP 7.3.

The technique I used to update the forum was to create a mirror on a test server. On this test server, I have changed the version to PHP 7.3, and I have “debugged” the forum until it was working, and it was secure again. 

To make your work easier, you need to enable some configuration options. You need to be able to flip PHP versions on your server quickly. I used a .htaccess option for that. And it would be best if you also turned on all the debug options in PHP like displaying or errors and warnings and logging them. 

I have also focused initially on the most important pages: the home page, the forums, and categories page reading a discussion, creating a discussion, and posting a reply. 

Working on this, you will quickly discover that there are only a few kinds of issues that you need to fix. And as you fix them, you begin to see them and fix them faster and faster. Those are unquoted strings, querying undefined global constants, the “/e” deprecated modifier for “preg_replace” and the old style of defining a constructor by using the class name and there some cases where “sizeof” is used on a variable that is not an array

Obviously, these are all a result of the deprecated features from the old versions of PHP. 

A particular challenge with updating the code is the template system. This code is stored in the database, and it is executed using the “eval” function. Evaluated code makes locating the problem and fixing it more difficult. For this case, I have created a helper debug function that I could use to print you the template name and the template code that would show a problem. I would then update the template using the Style Manager available in the vBulletin back end. 

Removing the “/e” modifier in “preg_replace” took a bit of testing a playing around. But you can use “preg_replace_callback” to get the same result. You have to pay attention to what arguments to pass an in which order. Again, once you fix one of the deprecated calls, you will be able to fix the rest. 

vBulletin is a major piece of software with a lot of plugins available. The size and complexity of it are what makes is so difficult to create a simple patch tool for the entire forum that will take care of all the problems. And probably why the original developers did not create such a tool. In my particular case, I have focused on the most used features, so the forum continues to be usable for my friend and his community and also remains secure. Working like this will make the scope of the update more manageable and will give you more time to fix other less used features later on. 

Some tips

Working with AJAX requests can be tricky because it is not apparent where the problem is. For those scenarios, make use of the Web Developer tools available in your browser to inspect the response of the AJAX request, where you will be able to see the problem more clearly. The quick reply feature is the one that you will find being broken by warning outputs.

Another tip I have for you is to keep the new code backward compatible with the old version of PHP. This approach will allow you to incrementally patch the LIVE forum as you work and make the transition seamless for your community.

The final tip is to address the temptation to disable the display of errors as a way to “fix it.” That is not fixing it; it is just hiding it and kicking the problems down the road. I strongly recommend that on your test server, you have full debug on and work until you get no more warnings or notices. Then your code is ready for the future. 

Why not just upgrade to vBulletin 5.x? 

When I was considering upgrading to 5.x, the new code was unstable and buggy. It was not ready for a production environment. In my mind, the choice was clear: stay with 4.x – a time tested and proven solution that works. 

If 5.x is now stable, there are still more things to consider: how easy it is to migrate your community to the new version? Are you able to port all of your customizations? The signup process? What will your community think about updating the software and changing something that they are very familiar with? Some communities prefer the “new thing” and would gladly embrace and be curious about vBulletin 5.x while other communities would rather stay with what they know and with what works. The later communities would greatly benefit from a seamless upgrade of the old code to work with PHP 7.3.

In short: what is important for you and your budget will determine what to do next: upgrade the code, update to 5.x or move to a different forum software altogether. 

If you plan to do this kind of migration yourself and you get stuck, feel free to drop a comment below. I might have some insight as I have spent a couple of years working with and customizing vBulletin 4.x.

SSO – Single Sign-On – One Ring to Rule them all!

I am sure you have noticed most of the software services today that require you have an account allow you to “Login with Google” or “Login with Facebook.”

That is very convenient for your potential users and customers as Facebook and Google are so ubiquitous. 

The process above is a form of Single Sign-On. The user logs in only once into Google and then uses that login to authenticate themselves into various other software services that accept Google as an “identity provider.” 

The term “identity provider” is what Google and Facebook do when they allow you to use their services to authenticate your users. 

I was reluctant to use an external identity provider before, because I had assumed that it would mean that you do not “own” your user base, but instead Google does, and they could cut access on a whim. But that is not the case. If you request and are granted access to the user email, you can still get in touch with them, even if Google or Facebook will refuse to do business with you anymore, for whatever reason. 

So it makes sense to add such a feature to your service because it will make it much easier to adopt. 

For larger companies that manage multiple applications and services, it is possible, and it makes sense to implement their own Identity Providers to create the Single Sign-On capability.

Potential Pitfalls

A big challenge that I found with using Identity Providers is “session management,” which means keeping track of the “logged in user.” For example, if the user logs out of Google and logs in with a different account, your application needs to be able to spot this and create a new session for the new account. Otherwise, you risk exposing private data to the wrong person.

The Technical Side

Implementing Identity Providers and consumers it is relatively easy now because they are standard, so you can find ready-made libraries that will make the connection a breeze. 

The libraries I have worked with that I can recommend are:

For Php Composer:

– The PHPLeague / OAuth2-Server 

– The PHPLeague / OAuth2-Client 

WordPress Client Plugin:

– OpenID Connect Generic Client (this required some modification as it was not implementing all the requirements out of the box.)