Home » WebDev

Category: WebDev

The Power of Using APIs

Many years ago, I had set up my very first website. It was a Sudoku generator based on a selected difficulty level.

To promote the website, I wanted to have a newsletter so I could email my subscribers a daily puzzle to print out.

At the time, I was using AWeber as my newsletter service.

I was very annoyed with the fact that to capture the email of my visitors I would have to send them to a new AWeber page where they would fill out a form, and then instruct them to go to their email to click the confirmation link, and that would get then to a confirmation page on AWeber, and then finally back to my website.

Those were way too many clicks to get yourself a printable sudoku puzzle!

What I wanted, was a way to plug into the AWeber service, and communicate with them, on my visitors’ behalf, while the visitors were staying on my website. What I wanted was an API, which is short for Application Programming Interface.

They did not offer that at the time, so I decided to simulate one by using a “fake browser” to make it “as if” the user has opened their page instead of my mine.

I was very proud of my solution, and it worked very well for about ten days until my account was banned for violation of terms of service.

Today they do offer an API, so I don’t have to resort to “shady tactics” to keep the users on my page.

I use this little story to make it evident why APIs are so powerful. I am all about automation and integration and the APIs make all this possible in a way that is reliable and makes sense and does not violate any agreements 🙂

I don’t think it makes sense to create an online service in today’s world and not to develop an API for it. Interconnectivity and interoperability increase the rate of adoption of your service. And you open it up to be used in ways that you may not even have imagined before and if you connect it, for example, to a platform like Zappier.

In conclusion, I feel that all software development is moving towards building APIs that will talk to each other. Even the front-end of websites will be a templating API making requests to a back end API.

This change will bring about dramatic shifts it what software developers do and will open the doors for non-developers to be even more expressive and sophisticated in their creations. Add AI to this mix, and we can only guess at the limits 🙂

Event-Based Programming

After you work long enough on software projects, it will become self-evident why complexity is your enemy. Pieces of code that are highly dependent on each other will result in a maintenance nightmare. You cannot change or upgrade anything without risking to break the different parts that are tightly connected to it. 

The solution I have found that works best is “Event-Based Programming.” I did not invent it; it has been around for a long time. I discovered that adopting this pattern has made maintenance much more straightforward. 

In a nutshell, your program is no longer a collection of functions that call each other in an ever-increasing web of complexity. Instead, you have components that talk to each other by raising or listening to events. 

This breakdown allows you to change each event generator or event listener individually, and as long as the event format does not change, you don’t risk a break down in communication. 

An event generator will say: “Hey, something interesting has happened, and here are the details.” And it does not care what happens with that announcement. It could be that nobody cares, or it could be that many will take action on that event. 

An event listener, on the other hand, does not care how an event was generated. As long as something interesting happens, it will act on it. 

This decoupling makes debugging super easy too! Because you can test components independently by merely looking at the kind of “chatter” they generate. 

If you’re reluctant to adopt “events” in your codebase, now it’s time to make the jump.

Using WordPress as a Prototyping tool

Creating a prototype for your product or service is an excellent idea. It allows you to do some research before you commit to a specific solution. You can test various layouts, various interactions, and you also have something to show to your investors or your target audience to check with them if this is something they would spend money to buy. And the cheaper the prototyping, the more tests you can do, and the more information you will have when you want to build the real product or service. 

A prototype has only very basic functionality, and it is used to get an idea of what the user interaction will be like and what possible challenges may show up in future development. Because it is so simplistic, you can choose any technology you want to create your prototype. It does not have to be the same tech you will use for the real product. And this is important because you can choose something free, or something that you know how to operate.

In this article, we will focus on WordPress. Why? Because it is free, it is a common platform, it has a rich plugin environment, and the new block editor makes it ideal for quickly creating complex layouts. 

All you need to do to get a free WordPress site is to head to WordPress.com, create an account, and start a new website using their free plan, and now you are ready to begin prototyping. 

Go to your website’s dashboard and create new pages using the block editor. It is almost like using lego pieces to build something. 

You can create multiple layouts for the same test page; you can create links between pages, simulating a user interaction, you can test how it will look like on a mobile screen, play around with various font faces and sizes and so on. 

As a bonus, you can activate the comments feature and use that to document feedback on the pages you are putting together. 

Using the Free plan on WordPress has some significant drawbacks:

  •  you cannot use custom CSS to finetune your design
  •  you cannot install plugins 

Depending on the complexity of the prototype, you may not need either one of them, but if those are important to you, then you can install WordPress on a shared hosting plan and unlock the full power of the platform. 

Closing Notes

I know that WordPress is not a prototyping tool. For more advanced use-cases, you will find it limiting. In those situations, you are better off investing in some dedicated tools like WebFlow, or Sketch, or Figma.

But as a playground, when you want to get a feel for how your idea will look like, and you want to have something to show to your investors or your audience, give WordPress a try.

Finally, all prototypes should be discarded when you go build the real thing. There is a big temptation to use the prototype for the live product, but please don’t. When you need to make something that is production-ready, start from scratch and do it right.

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.

CakePHP and WordPress

I’m not too fond of WordPress and yet…

Most of the websites I have built are using WordPress.

The reason I am using it is simple: The final customer enjoys the ease of use that WordPress provides. It empowers them to maintain the content of the website and (to an extent) manage the website themselves.

WordPress is excellent for what it was built for: a blogging platform. As soon as you begin to “add on” to it and make it into a complex web-application, things break down in terms of performance, stability, and security. It pains me to see how every plugin is downloading its own set of libraries and code, creating an app, with-in an app, with-in an app.

This problem shows up because each plugin developer has to make sure that all the code they need is there, and they don’t know if you have it from other plugins. So the code base gets fatter and fatter with duplicate code, and the website gets slower and slower.

Maybe in the future, the core of WordPress will be re-written from scratch to address these issues and to have a shared library folder or use some dependency manager (like composer).

In contrast, for the more complex web applications, I have been using CakePHP. The reason: I love Cake, and I like PHP!

Joking aside, CakePHP is a framework that allows rapid application development using modern design and technologies. Because it is a framework and not a full app (like WordPress), there is much flexibility on how you want to do things, what libraries you want to use, how do you want to integrate it with the rest of the world, and so on. This approach makes for much cleaner logic and code and better performance.

The downside is two-fold:

First, the customer needs a tech person to maintain a CakePHP app. There are no simple “update everything” buttons.

Second, for better or worse, you lose the considerable plugin ecosystem that WordPress has to offer. And some plugins are super useful, like Yoast SEO.

The Best of Both Worlds

(no, this is not about the Star Trek episode)

What I have ended up doing in some cases is to have a CakePHP app developed alongside the WordPress app for the clients that agree to have me as their tech person. This setup allows them to use WordPress for more frequent and simple tasks and enables me to deploy the power of CakePHP to manage automation, monitoring, and reporting for their business. Win-win!

Case Study

For a big WordPress site where things needed not to break down, and that specific metrics are met every month, I have developed a custom CakePHP app to monitor the WordPress site. It would generate charts and analytics for sales, visits, engagement, and other metrics. It would issue alerts when needed and generate reports daily, and monthly that would make it easier to diagnose any potential problems.

Yes, everything could have been written in WordPress as a plugin, but that would have meant making a fat code base even fatter, and it would have linked the two very tightly. Having a separate application allows me to update them separately, and if one stops working, it does not upset the other. A side benefit that I got, later on, was that the same app could link into other WordPress (or Joomla!) powered website for aggregate data reporting.

If you have the skill or the resources to hire the skill, it may be worth considering creating your custom development in CakePHP instead of WordPress.

If you’re interested in the technical details, leave a comment, so I know to write about it.