Blog

Replacing WordPress Cron With A Real Cron Job

In many situations, the WP-Cron may not working well or work at all. By default WordPress is setup to call wp-cron.php only when someone visits your site.

A better way to use the cron job that is available on your hosting server. In your cpanel, look for your cron job icon, click on it and select Add New Cron Job, then add the following line.

Using wget or curl since some host may have curl install instead of wget
wget -q -O - http://myurl.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

or php cli
/usr/bin/php /path/to/wp-cron.php

If you have access to ssh, simply type

crontab -e

This will open a file for you where you will be able to add the line above.

Useful Bash Script for Malware Removal

If you have access to your wordpress server via ssh, there some bash command that you can run to check if your files are infected with malware. This can be very helpful if you host a whole bund of sites on the same server.

Using Obfuscalp.

Obfuscalp is an open source php tool to finds and removes obfuscated suspicious/malicious code planted inside PHP and other scripts.
git clone https://github.com/Orbixx/Obfuscalp.git
cd Obfuscalp
php find.php /path/to/a/bunch/of/php/sites > infected.txt
...
Processed 3950000 files, found 30
Processed 3960000 files, found 30
Processed 3970000 files, found 30

php remove.php infected.txt
...
Processing file 28 of 30 (%93.33)
Processing file 29 of 30 (%96.66)
Processing file 30 of 30 (%100)

Find and delete any php files in upload folder
findwp-content/uploads/ -name "*.php" -type f -delete

remove text and html files
find . -name "*.txt" -type f -delete
find . -name "*.html" -type f -delete

look for .js.php extension files
find . -name "*.js.php" -type f

look for files that are updated in the last 60mins
find -iname "*.php" -type f -amin -60 # access time

Look for commonly injected scripts

find . -name "*.php" -type f -exec grep -q "function setCookie(a,b,c)" {} \; -print
find . -name "*.php" -type f -exec grep -q "@$GLOBALS[$GLOBALS['l8f127f'][89].$GLOBALS['l8f127f'][28].$GLOBALS['l8f127f'][22]" {} \; -print
find . -name "*.php" -type f -exec grep -q "\x47L\x4fBA\x4c\x53" {} \; -print
find . -name "*.php" -type f -exec grep -q "$sab=$_COOKIE;\x0d\x0a$jiu=$sab[qsll]" {} \; -print

Once you have clean all the files and backup, secure the files and directory with the correct permission.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;rm

These are just some of the scripts that I used, I will be updating once I got some new sits to clean up.

Fix 404 errors, Not Found, and Server Errors on WordPress/Woocommerce Site

According to wikipedia “The 404 or Not Found error message is a Hypertext Transfer Protocol (HTTP) standard response code, in computer network communications, to indicate that the client was able to communicate with a given server, but the server could not find what was requested.”

What happen is that the server could not find the file that are requested by the server. There are a few causes for these and these can be easily fixed.

There are common few fixes like refreshing browser, clear cache and cookie or amending .htaccess file.

For woocommerce site, I have found the cause in 99% of the case to be cause by Permalinks. Just by matching the Url in the browser and the setting of your Permalinks under WordPress–Settings>>>Permalinks, should fix the error.

Customising Woocommerce Report

Creating a simple plugin to generate a woocommerce report that suits your need. All woocommerce sites are different, the way they sell are different. Many plugins available are able to generate reports and customise them. Still I get a lot of request on customising reports for woocommerce.

I use the WC_Admin_Report class from woocommerce to accomplish this. With WC_Admin_Report, you organise all your required fields and condition in an array and pass it over. Write the results in a CSV, comma delimited file, using fputcsv and you are done. Throw in some nice jQuery and you get a really slick reporting system.

Using WP-CLI to check your wordpress core integrity

A very useful trick to check your wordpress core integrity with wp-cli.
wp core verify-checksums – Verify WordPress files against WordPress.org’s checksums.

# Verify checksums
$ wp core verify-checksums
Success: WordPress install verifies against checksums.

# Verify checksums for given WordPress version
$ wp core verify-checksums –version=4.0
Success: WordPress install verifies against checksums.

# Verify checksums for given locale
$ wp core verify-checksums –locale=en_US
Success: WordPress install verifies against checksums.

# Verify checksums for given locale
$ wp core verify-checksums --locale=ja
Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File doesn't verify against checksum: readme.html
Warning: File doesn't verify against checksum: wp-config-sample.php
Error: WordPress install doesn't verify against checksums.
GLOBAL PARAMETERS
--path= Path to the WordPress files.
--ssh=[@][:][]
Perform operation against a remote server over SSH.
--http=
Perform operation against a remote WordPress install over HTTP.
--url=
Pretend request came from given URL. In multisite, this argument is how the target site is specified.
--user=
Set the WordPress user.
--skip-plugins[=]
Skip loading all or some plugins. Note: mu-plugins are still loaded.
--skip-themes[=]
Skip loading all or some themes.
--skip-packages
Skip loading all installed packages.
--require= Load PHP file before running the command (may be used more than once).
--[no-]color
Whether to colorize the output.
--debug[=]
Show all PHP errors; add verbosity to WP-CLI bootstrap.
--prompt
Prompt the user to enter values for all command arguments.
--quiet
Suppress informational messages.

Learn more here wp-cli doc

WordPress Virus/Malware removal

Most of us who owns wordpress site will, at certain point of time, experience a hack. I will not cover the basics of such hack or basic common techniques used to remove them.

One of the technique I been using recently that would well, is to enable the debug mode.

The following code, inserted in your wp-config.php file, will log all errors, notices, and warnings to a file called debug.log in the wp-content directory. It will also hide the errors so they do not interrupt page generation.


// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

By simply enabling the debug mode, you be able to catch an error ‘headers already sent’, which also points to the file that the code are injected.

Warning: Cannot modify header information - headers already sent by (output started at /some/file.php:12) in /some/file.php on line 23

Since most code are injected on top of your files, you be able to catch the error sent out just by enabling the debug mode.