Premium WordPress Themes and Support

 

I was asked to move a website to a new location, where the owner of the site for whatever reason had no admin rights to the backsite. All we had to go with were 2 files, the MySQL database dump file, and the files of the site in a zip file.

Off topic here but, for migrating sites, I use the plugin called “Duplicator” , but sometimes this does not work well, if you have very large files, or the size of the site is too big, and your hosting is configured in a way that the execution time is not big enough, so you run out of time before completing the task, or the php version is old, or the zip component is not installed on a server, etc… In some of these cases when the Duplicator cannot be used, at least for backup purposes, it seems that the plugin “UpdraftPlus Backup and Restoration” is able to operate. So I will be investing in their $30 Add-on to migrate sites, with the hope that all the limitations which forced the Duplicator not to work, this plugin will do it’s intended job. I will also be buying the InfiniteWP’s cloning add-on for $99, to ensure that I also have a more professional grade tools to play with. Migrating  sites  manually is an option too, but with plugins it’s much easier, and less prone to operator errors during the process.

  1. When Migrated the site to my local server manually, and used phpMyAdmin to change the administrator’s password to gain access to the backsite I discovered 2 security issues right away, that are easy to fix, and extremely stupid and lazy if neglected, or setup that way to begin with.The first issue was that the administrators username was “Admin”. That is/was the default admin username of a fresh WordPress installation. Most brute force attacks on sites, use that username to try to gain access, because the site owner did not delete it. If you have a username “Admin” in your site, first create a new username  with admin rights, and simply delete the user “Admin”. This site was apparently built and maintained by professionals, which made me scratch my head even more!
  2. The second issue I discovered that all the tables in the database had the WordPress default table prefix “wp_”. If you manually install WordPress, during the setup process, you are given a chance in changing this default prefix – SO CHANGE IT. If for whatever reason, your website has the default prefix, it’s an easy fix too. Btw, if you use your hosting’s 1 click auto install routine to install   WordPress, I almost guarantee you that your tables will have this “wp_” prefix. Having this prefix, is making too easy for potential hackers to blindly target your database tables. To manually fix it, you first change the table prefixes in the database, and reflect the prefix change in the wp-config.php file. If you want to automate things, and change the prefixes any time you want within 3 seconds from the backsite, then use the “Change DB Prefix” plugin.

Stop making things too easy for the hackers!

 

 

Leave a Reply