wordpress

4 Things You should do to Prevent any Hack

Posted on by Mario

5-things-you-should-do-to-prevent-any-hacks

It seems like hackers always find a way to attack any sites, if your website is one of them, don’t be upset, re-upload it immediately and do these 4 things right after you find your site is hacked in order to prevent any hack attempt in the future before calling any web developer expertise to solve your problem.

  1. Understand what just happened

When your site has been hacked, there are number of possibilities that may happen regarding to this, first it can be to poor maintenance or due to bad plugins. If you have no idea, if your websites have been hacked or not, you can take a look several hints that can give you signs that you are being hacked:

  • Google has blacklisted your website;
  • Google search result pages show ”this site may be hacked”;
  • Your host has disabled your site;
  • Customers notify you via their local AntiVirus applications;
  • Your website is not behaving correctly or generating odd errors.

Bear in mind that knowing what happens to your website is half the battle since hackers try to hack your website all the time.

  1. Brace Up Your WordPress Security

There are a lot of things you can do, but at least address the following:

  • Generate New Security Keys for WordPress

Step 1 is to copy/paste these codes in your wp-config.php:

define(‘AUTH_KEY’,         ‘>f8WY(G1ED*-uk)mPxG*!6a~^J2toVWSIFOshT${gn|oT t|v8aba<Fh;pFP`yid’);

define(‘SECURE_AUTH_KEY’,  ‘<iR+Ar.`VQ!3HYa#R+AI*MC2Sc,${6v_.L#$t4;)%eZ=@|.b>b:qy|@X]Vb3W|RH’);

define(‘LOGGED_IN_KEY’,    ‘1E>><mq?hvpmS{3D#KF1|x#.rc6sCQHZTZ}*;*Z2t6T*f_z#jGlbzSf@DvLgckKU’);

define(‘NONCE_KEY’,        ‘OXcWKI/9xDf@$yMB27+o/L&bnAROa%Ve4|Ir]6qa+y8p.`}>`I1b7)dmaDi{$?[Z’);

define(‘AUTH_SALT’,        ‘Mb<5yV36&|SS#!gC#^jw*8|)hL-EP@M(mPuAe+;18D|Ju3+Jh239)tRwX4HD([7o’);

define(‘SECURE_AUTH_SALT’, ‘E*1|=#nsgx_Q{:GKa|sJ|Q!>14W&)LEccK-[[ K[=sQM%<D|*UDhq>qOzY5.rw=`’);

define(‘LOGGED_IN_SALT’,   ‘DE[?b$ZN/A25@0_lLnMD>+_$jeEqEFo=>t?-qa{GY4D-2PZD[`C2l.j2Zi(N)~dd’);

define(‘NONCE_SALT’,       ‘bWnj/%_FEz]zF*j9njk^FY?uwDkQU^|c-Tu!Vm3S_U[#c2kaTb+F.vcu=[Jx4wn+’);

Save the file and the first step is done.

  • Reset Your User Passwords

In some cases, hackers will try to attack your sites brutally by guessing your username and password, so please don’t use ‘admin’ as your username and ‘12345’ as your password. In fact, it is important to change your password after a hack and secure it with a complex structure, such as combine upper/lowercase, use special characters and numbers.

  • Reinstall the core

Another important recommendation is to remove and reinstall the WordPress core manually. Instead of updating/reinstalling feature via your dashboard, you can use your favorite FTP/SFTP client and manually replace the files. Usually the attackers like to embed their files deep in your file structures, and a very common is within the core directories (i.e., /wp-admin/ and /wp-includes/).

  • Reinstall your plugins

It may sound too drastic, but this is the only way that you can do to make sure no malicious code remains on your website, this act means a fresh reinstall and hope all the additions and insertions of the hack disappear.

  1. Restore a BackUp after the Hack

Solid backups are necessary to restore your website quickly after a hack. It might require you a few updates, but in this way, you can keep your site up and running.

  1. Keep Your Website Up-to-Date

Older version of WordPres is vulnerable from hacker’s target this is why you need to stay away from plugins without updates in the last two years. You can figure out the version of your WordPress in readme.html file or sometimes even right in your source code.

The point is to keep your plugins and WordPress up to date, this advice applies for activated and deactivated plugins since these are just as vulnerable. Only by this way, you can make sure to update all of your software after a hack.

The Easy Way to Mass Find & Replace WordPress Databases

Posted on by Mario

The Easy Way to Mass Find & Replace WordPress Databases

Web developers who have an experience with changing WordPress url address would know that after migrating the database, URLs inside of it will still refer to the old site. However, WordPress is widely known as a web platform that has a ton of plugins and therefore there are many tools that can assist you to import database easily. But, a tricky method is necessary for requiring the shortcut of changing every URL instance inside the database.

As it is described in the picture below that the old URL in the wp_options table, set as the value of the siteurl and home options, and it’s probably also embedded throughout several other rows and tables in the database. If you find this kind of old URLs may eventually prevent your site from running properly, then you need to change to the new URL, such as below:

yourweb1

In the image above, you will find that the site acme.dev will simply lead to a blank page. Below is given a technique to change all these URLs in the database.

Leveraging WP-CLI

Leveraging WP-CLI is not the only way to change the URLs in the database, you can run an SQL query to replace it, but I find that leveraging WP-CLI is a handier alternative compare to SQL query which is a workable solution, yet at the same time, is not convenient to do. Assuming you have installed WP-CLI and have the wp command accessible as the alias, navigate to the directory where your WordPress site files reside.

Then, run the following command:

wp search-replace ‘http://acme.com’ ‘http://acme.dev

The first parameter, ‘http://acme.com’, is the old entry to be replaced with the second one, ‘http://acme.dev’.

yourweb2

Not only the post_content column and wp_options table but also all the tables within the database will be searched by the command line. Then, it will replace every instance of the entry passed through the parameters of the command, like it is explained by the above screenshot that a total of 225 have been made through a simple line of command.

Moreover, we can use the wp search-replace command, not only for replacing URLs, but also any piece of value stored in the database. The operation can also be limited into a certain table by passing the table name as the fourth parameter, as follows:

wp search-replace ‘.jpg’ ‘.webp’ wp_posts

Bear in mind that taking this action means you have to install the WP-CLI first and it will replace the image extension from .jpg to .webp.

The Complete Guide to Proper JavaScript Usage with WordPress

Posted on by Mario

The complete guide to proper Javascript Usage With WordPress

WordPress has become one of the most popular blogging platforms and content management systems worldwide, therefore, in web development, JavaScript is necessary to be learnt about and as a web developer, you need to learn a bit deeper about JavaScript, like how to enqueue JavaScript files inside our pages and how to pass translatable data to the JavaScript code. Check this out!

  • The Right Way to Use JavaScript with WordPress

There are two main problems while using JavaScript in WordPress Projects, duplicate code on the same page and problems with translation. But don’t worry we have the solutions for both of the problems, for the first problem you can simply “registering  and “enquequeing” the JS files with the two core functions of WordPress: wp_register_script() and wp_enqueue_script(). The second problem’s solution is easier than the first problem: The core wp_localize_script()function allows you to pass translatable data into your JS code.

  • Registering JavaScript Files

The first step is to “register” them before you can “enqueque” the JavaScript files. And that’s done simply using a function called wp_register_script():

<?php wp_register_script( $name, $url, $dependencies, $version, $load_in_footer ); ?>

Some notes on the parameters:

  • Name (required, string): You can choose any name that you want for the name of the script, providing that’s not used by another script.
  • URl (required, string): The URL of the script.
  • Dependencies (optional, array): The name(s) of other scripts that our script depends on. For example, if your script depends on jQuery , it will need to be loaded after jQuery. In this case, you should use array( ‘jquery’ ) for this parameter.
  • Version (optional, string): its version number for your script. There are three options are provided, you can choose between providing a string, setting the parameter to or leaving it empty. If you set it to string, that’s going to be added to the output code like my-script.js?ver=1.2. If you leave the parameter empty, the version of your WordPress installation will be added as the version number. If you set it to null , nothing will be added.
  • Load in Footer (optional, Boolean): When you enqueue this registered script, it will be loaded in the <head> But if you set this parameter to true , it will be loaded right before the closing <body> tag.

Moreover, scripts which are already registered by the core or other plugins with the wp_deregister_script()function can also be “deregistered”. It only accepts a ‘name’ parameter, which you provide the name of the script to be “deregistered”.

  • Enqueueing JavaScript Files

You can register a script but that doesn’t mean that it’s going to be loaded automatically. After registering your scripts, you should “enqueue” them with the wp_enqueue_script()function:

<?php wp_enqueue_script( $name, $url, $dependencies, $version, $load_in_footer ); ?>

Some notes on the parameters:

  • Name (required, string): The name of the script.
  • URL (optional, string): The URL of the script. As you can see, you can just provide the name and you’re good to go because if you already registered the script, this time the URL parameter is optional. But if you didn’t register your script, you must provide a URL for this parameter.
  • Dependencies (optional, string): The version number of script.
  • Load in footer (optional, Boolean): The script will be loaded right before <body>

You can also “dequeue” scripts with the wp_dequeue_script() function.  Moreover, it only accepts a ‘name’parameter, similar to the wp_deregister_script()function.

Hooks to Enqueue Your Scripts

Apply the hooks below as the right way to enqueue your scripts:

  • Wp_enqueue_scripts-This one enqueues scripts in the front end of your website.
  • login_enqueue_scripts –This one enqueues scripts in your login screen.
  • Admin_enqueue – This one enqueues scripts in the back end of your website.
1

2

3

4

5

6

 <?php

function my_scripts_loader() {

wp_enqueue_script( ‘my-js’, ‘filename.js’, false );

}

add_action( ‘wp_enqueue_scripts’, ‘my_scripts_loader’ );

?>

You musn’t use the hooks named, due to compatibility issues:

admin_print_scripts or admin_print_styles.

Passing Translatable Data Inside JavaScript

Since so many people  doesn’t know the neat little function called wp_localize_script()uJavascript is always a problem with WordPress when it comes to localization:

01

02

03

04

05

06

07

08

09

10

11

12

13

 <?php

$l10n_data = array(

‘nextItem’ => __( ‘Next’, ‘my-script’ ),

‘prevItem’ => __( ‘Previous’, ‘my-script’ ),

‘imageTitle’ => __( ‘Image %d of %d’, ‘my-script’ )

);

 

wp_localize_script(

‘name-of-the-script’, // (required) the name of the script, ‘my-script’ for example

‘nameOfTheObject’, // (required) the name of the script, ‘my-script’ for example

$l10n_data // (required) the data to be passed, which can be translatable with the __() function

);

?>

You can pass the localized variable in your script after registering, enqueueing and localizing the script by using the name of the object and names of the data, like alert( nameOfTheObject.prevItem );