Home » WebDev

Category: WebDev

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.