DEV Community: StaxWP

Why you should NEVER use Nulled Wordpress plugins and themes and why is this still a trend

George Tudor — Sat, 29 Oct 2022 18:27:52 +0000

Let's be honest, piracy has always been a trend on the internet. Software, games, movies and music have always been distributed for free via CDs, DVDs, USB Sticks and lately torrent sites.

While this sounds awesome for the end consumer, businesses suffer because of this. We all got some unauthorized copies of different things back in the days... and it felt great, not gonna lie. But it all comes with a risk and that risk is called malware.

We, at Stax, develop Wordpress plugins & themes. Most of our plugins and themes are released as a freemium package, meaning there's a Free version and a Pro version. That's the main trend in the Wordpress community and we'd like to stick with that.

All of our Free plugins are really generous in terms of options and functionality. We try to offer as much free functionality as possible to help regular users with their daily needs. The Pro versions of some of our plugins contain a lot more functionality which helps users achieve even more.

Converting Free users into Pro users is sometimes hard, but not impossible. However, some users prefer to get the Pro version of different plugins from doggy sites that offer them for free or a lot cheaper than the main developer's price.

Why is this happening? Well, there are lots of reasons, but here's what my findings are:

Pricing

Some plugin developers tend to price their Pro version using multiple subscription tiers. The most common practices are a yearly subscription and a lifetime offer.

Unfortunately even a yearly subscription seems to be too much for an end user, specially if they need the plugin just for a short period of time or they are not sure if their business will succeed... so a big investment is not justified by these circumstances.

The price itself is also an issue for some potential customers. Really popular plugins or themes creators tend to price their products higher than their competitors just because their popular. This doesn't really mean their products are better than their competitors, but they have enough exposure to leverage this opportunity.

Trust issues

I think the more you know about the Wordpress ecosystem, the easier it will be to know what you want. However, uncertainties can occur on both sides.

Trust issues usually rise for 4 reasons:

The user don't really know if the tool they're going to purchase will get the job done.
The product doesn't have a Free version the user can try before purchasing.
The product doesn't have reviews.
The product's author has a bad reputation or no reputation at all.

Now let's talk about the elephant in the room, those so called "nulled" sites, which are distributing Pro versions of plugins and themes for free.

There's a general rule in life: "Nothing is free". If you think these Pro plugins are free, then you're wrong and naive. There's always a price your have to pay, but in this case isn't money, it's your security and privacy.

Here are the top 2 problems with Nulled plugins and themes and why you should NEVER trust them:

1. Malware

The most important issue is that 99% of the time they contain malicious code.

It's usually a shell script that compromises your entire server and offers it on a silver plate to the software distributor.

2. What you get is not actually what you want

Most of the times, the nulled software distributor claims to provide the latest version of the plugin or theme you are looking for. Well, in most of the cases all you will get is an old Pro version which probably is no longer compatible with the current Free version.
But... it can get worse. You might get just a malware and that's it.

Conclusion

Are nulled plugins and themes distributors a bad thing for the
Wordpress community? Definitely YES! Unfortunately, there's nothing we can do about it, except to raise awareness and show users what should they expect when they go on this road.

As long as end users will search for nulled software, these sites won't go away. If 10 are terminated today, 20 will appear out of thin air tomorrow.

So be responsible, do your homework and think twice before falling into this trap.

How to setup Wordpress coding standard rules in VS Code

George Tudor — Fri, 18 Feb 2022 08:41:12 +0000

I see a lot of code that's not following any standards. Especially in the Wordpress community.

I don't hate it because it does the job done, but if you try to debug it or understand it you're gonna have a bad time. Unreadable code is awful.

We, at StaxWP, always use Wordpress coding standards in our themes and plugins. It's easy to implement it, let me show you.

What coding standard does Wordpress follow?

Wordpress follows Pear coding standards but with some twists. There are some characteristics that are present only in Wordpress.

Here are some examples:



// Spatiate
$x = $foo[ $bar ]; // correct
$x = $foo[$bar]; // incorrect

// Yoda conditions
$x = 2 === $i; // correct
$x = $i === 2; // incorrect

So what do we do to fix these things automatically?

We use WordPress Coding Standards for PHP_CodeSniffer (WPCS) which uses Squizlabs' PHP codesniffer (phpcs) and beautifier & fixer (phpcbf) under the hood to scan and format the code.

You can install WPCS globally or inside a project. I like to use it globally inside Ubuntu WSL2, but this guide will work for any setup. First we need to clone the repository in some location. I've picked the home directory:



git clone git@github.com:WordPress/WordPress-Coding-Standards.git

Install the dependencies:



cd WordPress-Coding-Standards
composer install

Now we have phpcs and phpcbf installed in vendor/squizlabs/php_codesniffer/bin and we can use them in VS Code.

For VS Code we're using the PHP Sniffer & Beautifier extension. We just need to install it, add the paths to phpcs and phpcbf and tell it what coding standards to use.

After we've installed it, we go ahead and press Ctrl/Cmd + Shift + P inside VS Code and search for settings.json. There will be 4 different files with the same name:

Workspace Settings: referring to the current project's settings
Remote Settings: referring to the user's settings but inside WSL/Docker
Settings: referring to the user's settings on current machine
Default Settings: containing the default settings (we don't want to touch these)

Depending on your setup you will want to set these coding standards per user or per workspace. I suggest you set them per user and overwrite them per workspace whenever you have to.

So were going to open the user's settings and add the following lines:

"files.autoSave": "onWindowChange", "editor.linkedEditing": true, "editor.tabSize": 4, "editor.detectIndentation": false, "editor.formatOnSave": true, "window.title": "${activeEditorLong}${separator}${rootName}", "phpsab.standard": "WordPress", "phpsab.snifferEnable": true, // disable this if you don't need suggestions "phpsab.executablePathCBF": "{PATH}/WordPress-Coding-Standards/vendor/squizlabs/php_codesniffer/bin/phpcbf", "phpsab.executablePathCS": "{PATH}/WordPress-Coding-Standards/vendor/squizlabs/php_codesniffer/bin/phpcs", "phpsab.snifferShowSources": true

Make sure to replace {PATH} with the correct path to your WordPress-Coding-Standards folder. Also, if you are on Windows and you don't use WSL2, you will need to refer to phpcbf.bat and phpcs.bat.

Now we are pretty much set. Everytime we need some other coding standard we can overwrite it in our current workspace by adding phpsab.standard and specifying the standard.

Here's a short example of what will happen everytime you will have some badly formatted:

That's it! Enjoy.

Support & follow me