Using DMCA plugin from the WordPress Repo….

I found myself with a problem with the “DMCA Badge”^[3] plugin, and here’s my take on the support provided by DMCA^[2] itself. This is not an affirmative post but a blaming and shaming one for DMCA^[2]. Since they are not capable of maintaining their plugin and redirecting information internally without telling a user to resubmit the solution to their bloated plugin.

Plugin problems arise

When I upgraded to WordPress 6.5, the “DMCA badge”^[3] plugin started giving an error for all users to see, as I’m a developer for my site, I tried and successfully corrected the error. With that, I’ve tried to submit the fix, since DMCA^[2] did not fix their plugin when there was a problem.

The problem is the following:

WP_Translation_Controller::load_file(): Argument #2 ($textdomain) must be of type string, null given, called in ***/wp-includes/l10n.php on line 838
***/dmca-badge/libraries/sidecar/classes/

In this case, not on my website (since I’ve already corrected it), the error does not specify either the file or the function where it gave the error, but it got me curious, and then the rabbit hole began.

Searching for the problem on the plugin

After many tries and fails, since the problem was somewhere on the path “dmca-badge/libraries/sidecar/classes”, I found out where the problem was and tried to figure out what was happening.

I knew from the beginning that the problem was related to translations, but without a “code helper” like “error on initiation of the class XYZ” as many developers do, I was greeted with the generic error “WP_Translation_Controller::load_file()“.

A rookie developer can, at least, provide to the administration, specifically the role of “Administrator”, the error and how an admin can provide feedback and where to report errors, but it appears that DMCA^[2] does not have at least a rookie developer but instead, a “beginner” developer since all the files contain the same code for each function that is:

try {

//something…

}

catch (Exception $e)

{

echo ‘Exception Message: ‘ .$e->getMessage();

if ($e->getSeverity() === E_ERROR) {

echo(“E_ERROR triggered.\n”);

} else if ($e->getSeverity() === E_WARNING) {

echo(“E_WARNING triggered.\n”);

}

echo “<br> $error_path”;

}

catch (ErrorException $er)

{

echo ‘ErrorException Message: ‘ .$er->getMessage();

echo “<br> $error_path”;

}

catch ( Throwable $th){

echo ‘ErrorException Message: ‘ .$th->getMessage();

echo “<br> $error_path”;

}

And now, try guessing where the error is triggered? not a clue? in the “catch (ErrorException $er)” part.

So, in the directory, there are 10 PHP files, all with that logic. the files are:

class-admin-page.php (1973 lines of code)
class-admin-tab.php (178 lines of code)
class-field.php (452 lines of code)
class-form-settings.php (141 lines of code)
class-form.php (1380 lines of code)
class-plugin-base.php (3962 lines of code)
class-plugin-settings.php (632 lines of code)
class-settings-base.php (570 lines of code)
class-shortcode.php (177 lines of code)
class-singleton-base.php (438 lines of code)

I’ve already put the file that contains the error in bold. Imagine my surprise when I found out that the error was in line 1985 and that it was due to improper initialization of the var “$this-plugin_slug” shown below ^[4]:

load_plugin_textdomain( $this->plugin_slug, false, ‘/’ . basename( dirname( $this->plugin_file ) ) . ‘/languages’ );

So there was me in a quest to improve this and correct the error.

The slug is provided by the call “basename( dirname( $this->plugin_file ) )” so there is a repeating slug and an improper slug added.

Since I wanted to specify to the developer that the problem was the plugin slug, I wrote the following code:

/**

* @var string $slug

*/

$slug = (string) basename( dirname( $this->plugin_file ) );

/**

* @var bool $deprecated

*/

$deprecated = (bool) false;

/**

* @var string $relative_path

*/

$relative_path = (string) ‘/’ . $slug . ‘/languages’;

$args = array(

$slug,

$deprecated,

$relative_path

);

call_user_func_array(“load_plugin_textdomain”,$args);

So why am I changing the mode the “load_plugin_textdomain” is called?

Since I needed to know what wasn’t parsed to the load_plugin_textdomain function and since I knew from the beginning that the first argument is the slug of the plugin, the test I made before submitting to this website the correction was adding a var_dump call to the arguments and specifying each argument type.

So, after making changes, the code looked like this:

/**

* @var string $slug

*/

$slug = (string) $this->plugin_slug;

/**

* @var bool $deprecated

*/

$deprecated = (bool) false;

/**

* @var string $relative_path

*/

$relative_path = (string) ‘/’ . basename( dirname( $this->plugin_file ) ) . ‘/languages’;

$args = array(

$slug,

$deprecated,

$relative_path

);

var_dump($args);

call_user_func_array(“load_plugin_textdomain”,$args);

Surely the developer did test the “$this->plugin_slug”, right?

Wrong!

Surely the developer knows that calling the following code “basename( dirname( $this->plugin_file ) )” will return the plugin slug right?

Wrong!

So, instead of deleting all the work that returned:

array(

(string 0) “”,

(bool) false,

(string 21) “/dmca-badge/languages”

)

I’ve thought of the following:

Since i get the slug from “basename( dirname( $this->plugin_file ) )” there is no need to have redundant code…

Due to that, I’ve submitted the solution above-mentioned to the developer address (that is on the WordPress plugin page): support@dmca.com.

Here is a print screen of the page on the WordPress Plugin Repository, regarding the plugin “DMCA BADGE“^[3]:

Image telling where was the email to send problems with the plugin

Response from the supposed developers:

You Thank you for contacting us. Our infrastructure and support processes both technically and with client work is built around case system management. Which also includes communication and documentation. For this reason we do request that you send your question through our system where one of our team members can review your account and respond to you: https://www.dmca.com/questions.aspx Kind Regards DMCA.com Support — Response from the supposed support…

Getting angry

Imagine my reaction after receiving this email, where they say that I have to add a ticket for them to fix the problem. I’ve sent the code, and responded to users the fix on the WordPress plugin forum to 2 users that use this so-called plugin, I cannot alter the code in “WordPress trac”, and instead of responding something like:

Thanks for correcting our code, we’ll sent this to the development team for them to apply the fix.

I get a response that is vague at most and tells me to retell them about the fix when they are not updating their things on the WordPress Repository for more than 10 freaking months? Are they joking with me?

A Paragraph Specifically for DMCA Developers

If you are one of the developers of this, very bloated, buggy, and badly coded, plugin reading this, at least, update this behemoth.

There is no need for that much code in this thing, a few files could do the job. Really. A few files with much less code could do the job. At most, in terms of PHP, using 10,000 lines for your plugin is, in the worst-case scenario, the required for displaying a freaking badge on the user’s website.

Ending the post

I’ve learned from this experience that even an entity like DMCA is capable of ignoring its user base to the point of only wanting money for its plans/tiers. If they are not capable of spending a couple of minutes reviewing their code for a minor update of WordPress, then don’t offer services that depend on that plugin.

Yes, the update from 6.4 to 6.5 is a minor update, NOT a patch update.

If you want to know more about semantic versioning, visit the site semver.org ^[1].