Home » php

Tag: php

Community Software: FLARUM

My latest insight is that you grow faster, and it’s more fun (and challenging) when you have a community!

Because of that insight, I am consciously looking at how other people are building their communities, and, being the software nerd that I am, my attention goes to online communities. 

A new player around the block is making some noise when it comes to community software. And that is Flarum.

Here is the promise:

“Forums made simple. Modern, fast, and free!”

I have spent a couple of days taking this forum for a spin and testing out this promise. The short version is that I am impressed. 

Let’s break this down in a post that will be somewhat technical. 

Forums Made Simple

“Forums made simple” – I believe they fulfill this promise. The team behind Flarum chose to focus on what makes a forum a forum: the ability for users to create discussions and respond to each other. And that works beautifully well. However, to have great software, you can’t stop there. Otherwise, anyone who can follow a Larcast could roll out their forum in Laravel. The team made the forum simple and provided a scaffold and a framework so you can then make it as complicated as you need! 

Modern

“Modern” – This promise is also kept. There are two sides to this “modern” feature. 

First is the end-user: do they perceive it as modern? And I would give them a “yes” just by looking at the mobile experience. I don’t want to say that it is beautiful because that is too subjective. Instead, I would say the user experience is great: it works, and it works as you would expect it to work. Of course, any old software can hire a designer and create a “modern theme/look” for their forum, but that is only one part of it.

The other part of “modern” is the internal workings of the forum. And you would need to be a developer to appreciate the beauty of Flarum truly. The internals might be something that the end-users or community managers might not care about. Still, it will be important for the person in charge of maintaining the software on the server. 

To highlight a couple of things:

  • Using `composer` to manage the upgrades and the extensions – brilliant! I have not seen this done before in a forum context, but it is such a clean way to reuse code. It is different from what WordPress is doing, where every plugin has to install its dependencies, and you end up with loads of duplicate code and potential conflict that is sometimes very hard to spot and fix. While using composer makes me happy, I am also concerned with the possible problems that may show up in the future and that we cannot possibly see right now. 
  • Making this a Single Page Application. The front end is now a JavaScript client that consumes the API that the forum exposes. This pattern opens up a ton of flexibility on how this platform can be used – including completely replacing the front end if you are brave enough. The only issue that I see is potentially some SEO problems that plague all SPAs. 

Fast

 “Fast” – another kept promise. The lighting fast page loads were the very first thing I noticed about this software. It feels so snappy! Aven the search function feels fast. The high-performance is another result of the internals, and so it’s not something that older software can pull off just by “modernizing their look and feel.”

Free

“Free” – this is technically free… with a big “BUT.” 

To install Flarum, you need to run commands in your shell. And if you have no idea what that is, that is where the “Free” problem starts!

The power and performance of Flarum come at a cost. At the time of writing, you need to be pretty nerdy to install it and feel comfortable about it. Sure, you can copy/paste the commands in the tutorial, but if you don’t understand what you are doing, any tiny problem can be a game stopper for you. So even though the forum is free to install and use, you might have to pay for an installation service (that the Flarum team might provide in the future), and you also need to buy hosting where you can use the shell and the PHP composer software. 

All of this makes me think that Flarum might be best for companies that can hire such a developer and purchase a server with the required specs. 

And speaking of companies, this leads me into another potential trap of “Free,” and that is: you don’t want to build a community using software that will not be there for you in the long run. And if nobody is paying to help the software grow and have the bugs fixed, how long will Flarum be around? For a company, this is a risk that needs to be evaluated, and it can make a managed/established solution look much better in the long run, especially because it is not free.

I see the team behind Flarum making steps towards launching a managed solution, which will provide a stream of income and invaluable feedback on making the software better. And they may also establish a service of paid support that can provide additional incentive to keep this project going. 

Until there are some clear signs that Flarum is here to say, I believe it would be risky to build your community around it if you want to play a long-term game. But if you need to launch a project quickly that requires a community around it, you should give Flarum a try! 

The Competition

Flarum reminds me a lot about Vanilla Forums, and I believe that if they play their cards right, they could become their main competitor. 

You can get all of Flarum for free (if you have tech chops to install and manage it), while Vanilla OSS is very limited compared to the cloud option.

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.)