One of the areas of WordPress that, in my opinion, is not covered by a lot of quality plugins, is developer-oriented – debugging. There are maybe two good plugins available right now, and I have recently decided to change that. My new free plugin for WordPress, called DebugPress has been recently released.
Way back in 2011, I have created my first debugging plugin. It was fairly limited, but, it helped me a lot in learning how WordPress work, and I used that debugger for a while. It was part of the GD Press Tools Pro plugin. In 2015, I started working on GD Press Tools Pro 5.0, and I decided to completely rewrite the debugger.
And, when the plugin was released, it had a new Debugger that is the basis for the development going forward and will shape to what it is today. The debugger was part of the Pro version only, and it has grown a lot since 2015, and unfortunately, only a limited number of WordPress users had the chance to use it.
Very often, I get questions about the development process I use, and very often, that involves the tools I use, and one of the most important tools is Debugger, especially with WordPress and PHP. So, while I always recommend my plugin and debugger, that is not that simple, because the plugin was not free.
Last year I decided to create a new and free plugin that will have full Debugger included. The problem was the integration of the Debugger inside the GD Press Tools Pro, and it was not simple code migration to the new plugin. While I was thinking about what to do, other things were more important, and time flew by. But, finally, a few weeks ago, I had some free time available, so I started the work on the new plugin.
Surprisingly, the work took only 4 days. I had to transfer a bit more code than I anticipated, and I had to remove some features that required other GD Press Tools Pro features. But, I also decided to improve various things and add some new features as well.
I was a bit lucky to get the ‘debug.press‘ domain name, and the plugin was officially named DebugPress. The plugin is free, available on WordPress.org and it is on GitHub, so anyone can contribute.
I have been working in web development for a while now, and in the last 12 years, all my work has been around WordPress. With that said, having an all-round, easy to use development web server is essential to keep things organized, to test the code and not waste time on settings new environments, and reinventing the wheel with each project.
XAMPP and WAMP
Before I talk about Laragon, I would like to first go through my development web server history. First, I always used Windows-based computers for all my development work. When I was starting, the only viable solutions for Windows development was to set everything manually or to use XAMPP or WAMP server software. For a while, I used WAMP, but for the most part, XAMPP was my preferred environment. And I had different versions of XAMPP installed until recently, each one with varying versions of PHP.
But, some three years ago, I discovered the new and great Local (by Flywheel). Local was slick looking, with support for SSL, mail catching, changing PHP versions, and much more. It was using virtualization for each website, it was made for WordPress first of all, and it used VirtualBox and Docker to isolate each site and handle all the cool stuff. It was buggy, it had issues, but it made development changes that were painful with XAMPP, a breeze. So, I started migrating my development websites to Local, and last year, 80% of my development work was done via Local, and the rest was still on XAMPP.
But, late last year, Flywheel introduced Local 5 to replace older Local 3. Local 5 no longer used Docker or VirtualBox, making it hard to run some other web server at the same time, it lost some essential stuff (it had no support for Apache, only Nginx). Over time, they built on it, and now Local 5.6 can (sort of) use both Apache and Nginx (it never worked for me) as well as different MySQL versions.
And I did attempt to switch to it (Local 3.3 was not able to run PHP 7.4 or newer, it was virtually abandoned), and used it for few websites. Each new Local 5 version did fix few things but broke something else, and most important, it was not able to run alongside Local 3 due to the conflict with Windows HOSTS file, and the Local developers never fixed that despite promising a fix for months. Finally, the last few changes added Apache support. Still, switch to Apache was permanently destroying the site in Local (data was safe – but the location could not run anymore), throwing errors, and these errors were there for months now, no fix in sight.
So, I had enough. For the last 3-4 months, I wasted a lot of time trying to set it up, and there were days when I lost more than half a day reinstalling Local, setting it up, testing, and still ending up with the unusable systems.
Now, I spent a lot of time researching the alternatives. I needed a system that will allow switch between PHP versions, using Apache and Nginx, and maybe having support for different MySQL versions. After testing various things, I ended up with Laragon.
Laragon is not easy to use as Local, but once you set it up, it is working as you expect it to. Most operations are done via the context menu for the application sitting in the taskbar notifications area.
There are so many features included to make setup and use of the web server easier, related to Apache, MySQL, PHP, creation of new apps, various tools, and more. Laragon includes PHPMyAdmin and HeidiSQL for database management; it has Node.js built-in, support for SSL out of the box, and much more.
One thing that came as a huge surprise in running Laragon, was its raw speed. When compared to XAMPP and Local, Laragon is faster, much faster. The website running on XAMPP (similar PHP, MySQL, and Apache versions) had an average page load speed of 1.1 seconds, the same website under Laragon was loading in 0.4 seconds. With Local 3.3, the average page load was 2.1 seconds, with Local 5.6 it was 2.8 seconds, and the same websites in Laragon were about 0.3 seconds. That is a massive difference.
Well, Laragon too has some issues, but I was able to resolve everything quickly. One thing that proved highly problematic is to run MySQL and MariaDB and switch between them. So far, I was not able to make MariaDB work in the same way as MySQL, so I left only MySQL 8 running on Laragon (no password issue was not possible to reconcile between the two). I have MariaDB running outside of Laragon if I need to run some tests with it.
In the past week, I have migrated all my development websites from XAMPP and Local into Laragon. I reclaimed a lot of disc scape used by Local – same content database and files under Laragon used 25 GB, and under Local was close to 50 GB (because database data was duplicated with Local, and Local 3 also used Docker image running each site webserver). I also noticed a lot more RAM is now free, CPU usage is down.
For the first time in the last 12 years, my main development laptop no longer has XAMPP installed. So far, Laragon is great, once set up, it just works, and makes testing with different PHP versions easy, and I plan to start testing all my plugins with PHP 8 due to be released by the end of this year.
What local webserver you use for development, and what are your experiences with Laragon or any other web server out there? Let me know in the comments.
As a primarily WordPress developer, all the code I wrote for my plugins was following old standards WordPress used (and for the most part, it still does), and that is working without namespacing of the PHP code.
WordPress only recently dropped support for PHP 5.2, and PHP 5.2 had no support for namespacing. Because of that, WordPress code has all of its classes in the global PHP namespace and considering how large the WordPress codebase is, reorganizing the code will take quite some time.
For a while now, I planned to convert all my plugins, and better organize all the code to use namespacing, improving the plugin structure, take care of the optimized loading with the use of autoloader for the code, taking care of the possible conflicts, and making future development and debugging much easier. But, I have a lot of plugins on Dev4Press and making a change that big will take a lot of time, and it has to be done in stages.
Shared Code Library
All Dev4Press plugins use the same Dev4Press Library that includes a lot of base classes, functions, CSS and JS for the interface. Because of that library, all Dev4Press plugins share the same interface and don’t need to have so much code dedicated to the interface and other things.
And, this library is the best candidate to start the namespace conversion process. Once the conversion of the shared library is done, the work can be done on individual plugins.
So far, the progress on the shared library namespace conversion is about 50% done. The new version of the library will be available next week, and it will have a new structure of all library files, better organization of functions and a huge number of classes renamed and moved into namespace folder structure with the autoloader included.
The plan is to finish the conversion of the library by the end of the year.
Autoloader for the shared library
Here is the source for the autoload function used in the shared library.
The function gets the full class name that also includes the namespace for the class. That means, that we can split every part of the namespace and use it as a directory. Because of that, the directory structure reflects the namespace structure (check the image above, it has the directory strucutre on the left).
So, if the namespace is DEV4PRESS\SERVICES\API, the autoload function will load requested class from a file in the path dev4press/services/api.
Advantage of Autoloader use
Autoloader doesn’t have to be used with namespace classes, it can load any class. But, using namespaces and the directory strucutre that mimics the namespace organization, makes the use of autoloader very logical step and makes the autoloader very simple. Also, PHP runs autoloaders only if the class is not found. That means that you don’t need to wrap classes in the class_exists() function check, and that is what I used in the shared library for all classes, because all plugins include the shared library, and all plugins load same files, so it is important to avoid loading class that already exists.
Autoloading solves all these issues, and with the use of namespaces, down the road, depending on changes, you can introduce versions for the same class by using additional namespace in the structure to indicate the version of the class.
I was avoiding the use of autoloader function in my code because I prefer using it with namespaced classes, and I postponed autoloader use until the code get’s properly namespaced.
This is not going to happen quickly, but the goal is to start converting plugins to namespace structure from next month, and I hope I will be able to do it by the end of next year. When I get to work on the new major update for the plugin from next month, at least parts of the plugin will be namespaced.
Let me know if you use namespaces in WordPress related projects, and what experiences can you share if you converted your projects to namespaces.
I don’t make changes to my development setup very often, but this year was very important in terms of massive changes that included both hardware and software changes.
The first major change this year was replacing my main development laptop with the new. For the past 10 years, I only use Lenovo laptops, and since 2015, I was using Lenovo Yoga Pro 2 laptop. But, that laptop had few issues, including very bad keyboard (Lenovo laptops are known for great keyboards, but early Yoga models, were not as good).
So, in February this year, I replaced Yoga with L480 powered by Intel Core i5 8520u CPU. Since then I made few upgrades, and now this laptop has 16GB DDR4 RAM and 2 NVMe drives with total of 512GB space.
I recently replaced my phone, and now I am using Samsung Galaxy A50, with 128GB drive, 4GB RAM, triple camera setup and AMOLED display.
Other important programs I use include two programs from CloudBerry (or MSP360 as they are called now): Cloud Explorer and Desktop Backup. Since I use Amazon AWS for various things, management can be an issue via AWS native web interface, and I prefer the way Cloud Explorer interacts with Amazon S3 and CloudFront. And, Desktop Backup is simply an amazing tool for making backups locally or remotely to various cloud-based storage.
For design purposes, images related work, I use two great programs by Serif: Affinity Photo and Affinity Designer. They are an amazing alternative to Adobe programs, and I use them for over a year now, and I never wished to have Photoshop or Illustrator back.
Another new app I am using for the last 6 months Notion. It is a great app for scheduling, organization of time, taking notes. I will write more about it soon. As for browsers, Chrome is still my main development browser, but I have Firefox, Vivaldi, Edge and Opera on hand for testing.
For all local development, I use two different environments. One is XAMPP in two different versions, running different PHP versions, and I also use Local by Flywheel a lot this year, with at least 80% of work done on the environments run by Local.
So, that’s it for now. Let me know if you want to know more about specific applications, and let me know if you use any of these, and what alternatives you can suggest for me to try out.
For years, I used the NetBeans for all my WordPress related development, but due to the various issues, I gave up on NetBeans earlier this year. Since March I have been using PHPStorm, and after a few months, I can say that PHPStorm will remain my main IDE for PHP/WordPress development for the foreseeable future.
PHPStorm is developed by the JetBrains and it is one among many different IDE’s and development tools they make for various programming languages and work on all major platforms (Windows, Linux and macOS).
Working with projects
For me, this was a bit confusing at first, because, right now I have 10 projects created with PHPStorm, covering different types of websites made for the development of various plugins, and sharing settings would make sense for many of the projects. But, most settings can be exported and imported back to make things easier, and some settings can be global (that too can be confusing, especially since some global settings were not working for me in some cases).
For my particular development setups (some websites are working under XAMPP, some under Local by Flywheel), PHPStorm has been handling projects exceptionally well so far, and with recent 2019.2 update, that has been improved a lot with better WordPress support.
It has full Git (and other versioning systems) support, and you can do anything Git related directly from the plugin interface. I still use TortoiseGit, but PHPStorm has been really great with the Git support right in the IDE.
WordPress development can be tricky, considering that a lot of things depend on the filters and actions, and PHPStorm handles that very well (for the most part). Setting the project as WordPress project will ensure that PHPStorm caches WordPress functions and classes, it can even adjust coding code style and other things too.
Support for actions and filters are very good, but some things are not obvious when you start using it. When you start typing add_action or add_filter, PHPStorm will provide autocomplete for the action/filter names. And, the line with add_action or add_filter will include invocation location arrow to quickly bring you to the place that hook is run. Resolving callbacks work fine for methods and functions.
There are no Find Usages for filter/actions, and instead, you need to use Find dialogue. That is the only issue I have with that, and it is a minor issue, to begin with, everything else WordPress related has been great.
CSS/JS Build process
PHPStorm has own File Watcher system that can monitor changes in any file and perform actions based on the File Watcher rules. These can be simple rules, and they can be quite complicated based on the regular expressions to get the files.
File Watchers can be a pain to configure at first, but, the PHPStorm documentation and support were very helpful, and it works great now.
And, since I am not a big fan of having full Node.js build system that has complex build files and things like that, I really like the way PHPStorm handles that. It is all defined on the project level settings, and you don’t need any extra files inside your project for transforming SCSS to CSS, run minification or something else. You still need Node.js installed, but I really hate managing packages and all other nonsense Node brings, PHPStorm conveniently hides all that, and does things in the background with a much easier way to configure things.
Linting and hinting can be done using files, and PHPStorm detects those, and it can also have all these rules set in the project settings, and avoid having these extra files in projects too.
How much resources does it use?
PHPStorm creates cache files for each project and these files can take a lot of space (currently over 5GB of cache used for my projects), compared to NetBeans, it is a huge increase. But, because of such a large cache and the way it works with it, a lot of operations are almost instantaneous. I am yet to notice issues with scanning large projects, managing duplicated code and things like that. This cache makes PHPStorm very fast.
My current main development laptop is Lenovo Thinkpad L480 with i5 8250u CPU (4 cores and 8 threads) and 16GB dual-channel DDR4 RAM, with 256GB SSD.
Single project running in one PHPStorm instance can take 300MB to 800MB of RAM. If you run more instances, RAM usage rises, but not by match. With 5 big projects running at the same time (5 instances), RAM usage was around 2GB. In the same time, CPU usage is very low, and only if there is some background scan running, it can start using more CPU time.
Overall, PHPStorm is significantly faster than NetBeans, uses less resources, and for the last 5 months, I never needed to kill PHPStorm process due to the background scanner issues or anything else really.
And the price
Yes, PHPStorm is not free, it has a subscription-based license and you have to pay each month, or once a year. But, the price is fair for what PHPStorm brings to the table. In my case, it has made a lot of things easier, and even with the learning curve that any new software has, my productivity has increased by at least 30% since I have started using it.
They have quick release cycles, with 3 or 4 major updates each year, and each update so far has brought some really nice updates, including support for upcoming PHP 7.4.
Should you use it?
Well, I can recommend to everyone working with PHP and WordPress to try PHPStorm. it has 30 days trial that is fully functional, and that is plenty of time to assess the worth of PHPStorm. Even if you are satisfied with your current IDE, give PHPStorm a try.
Let me know what you think about PHPStorm if you have some interesting experiences with it, or suggestions on how to use it, some tips or even the issues you had with it.