Removing 100 product limit on Woocommerce Google Feed Manager

Update April 10th, 2017: The plugin developer contacted me about this post. Out of respect for the way they handled it (extremely classy),  I wanted to put a link to the paid version of their plugin. So, if you actually want support on the unlimited feed, and don’t want to do any hacky tricks, go support their hard work via the link below.

Purchase Woocommerce product feed manager

Original Article

I came across this info somewhat by accident today while working on an XML Feed generator for a WooCommerce installation. I’ll often review the code of a couple plugins with similar functions to what I’m developing. While looking through Woocommerce Google Feed Manager I guess I found a gremlin.



I’ll put this right at the top in case this is all you came for. To remove the 100 product limit from the free installation of Woocommerce Google Feed Manager , download and unzip the plugin.

Navigate to /wp-product-feed-manager/includes/application/class-feed-processor.php

As of writing this the plugin is in version 1.1.0, and for this version the line your looking for is line:114

if ( get_option( 'wppfm_lic_status' ) !== 'valid' && $this->_product_counter > $grmln ) { break; }

You’ll want to change this if statement to not break the loop, so just remove the break; (pirate comment’s are optional)

if ( get_option( 'wppfm_lic_status' ) !== 'valid' && $this->_product_counter > $grmln ){/*Avast, mateys!*/ }

Save the file, re-zip your plugin, and upload it to your WordPress installation.

If you have over 100 products in your WooCommerce Store then go ahead and generate your Product Feed once more,

Screenshot from 2016-08-11 13:55:36


The Long Winded Explanation…

If you want to know what the above steps actually do, then this will go into a little more detail. I say a little because I really didn’t go through the plugin very much, I made this discovery, took a couple of screen shots and then moved on … I was busy doing real work stuff 🙁

Initially, I just wanted to see how the application structure looked, and how the feed was being generated. I looked at the file structure and opened /includes/application/class-feed-processor.php without looking at anything else first. I noticed the $grmln  variable declaration which lead immediately to the discovery of the if statement mentioned above.

But lets walk through this like we’re trying to hack the plugin, rather than miraculously discovering a variable.

First, take a look at the main plugin file wp-product-feed-manager.php
and scroll to line: 115 where there’s a method define_constants()

It’s not uncommon that constants are all that’s holding back paid features in free versions of plugins. Definitely far from always, but not uncommonly the case.

Anyway, in the define_constants() method we see starting at line:160
// Store the end file lmtr
if ( !defined( 'WPPFM_FEED_P_LMTR' ) )
define( 'WPPFM_FEED_P_LMTR', 18 );

This sparks interest in those who’d be seeking to perhaps….change the limit of the feed.  So let’s see where this WPPFM_FEED_P_LMTR is called.

Screenshot from 2016-08-11 15:19:47
PhpStorm output for ‘Find Usages of WPPFM_FEED_P_LMTR’


The usage of this variable seems to be limited one occurrence here,

It defines a variable on line:69,  and  there’s is a little cryptic arithmetic involved,
$grmln = 9 + ( 5 * WPPFM_FEED_P_LMTR );

Remember when the WPPFM_FEED_P_LMTR constant was set it was 18, so $grmln = 99.

Where is $grmln used?

Screenshot from 2016-08-11 15:24:17
PhpStorm output for ‘Find Usages of $grmln’

On line:114 you’ll see the conditional statement that implements the $grmln variable, which contains a break to the loop when the statement is true.

if ( get_option( 'wppfm_lic_status' ) !== 'valid' && $this->_product_counter > $grmln ) { break; }

Well that’s a problem, because the conditions to make this statement true are such, “if the user doesn’t have a license status that’s valid”, and “if the post count is over 99”.

All you really need to do is remove the break;, and then as one would expect, the loop no longer breaks when the unlicensed user product limitation is reached. You could likely also remove this limit by bumping WPPFM_FEED_P_LMTR to be equal to an absurdly high number or setting $grmln equal to count($data)….maybe we could even define wppfm_lic_status ourselves to be valid and just cruise on past this block as licensed users. Whatever…I didn’t explore these options or play around much in that regard, so other’s will have more information for me I’m sure. For those of you that wanted to know more behind how the tl;dr version of this post accomplished removing the limitation, now you do.


Developers work long and hard on these plugins, and if you’re going to use features which extend beyond the free versions of plugins, it’s best you just buy them. Sometimes I’ll publish interesting ways of extending functionality to the free version, but this is NO WHERE CLOSE to the benefits of actually obtaining the paid version. Updates will break these little hacks, and they may change functionality here and there in unexpected ways. Not to mention it’s always nice to get product support from the developer, which a license will get you, and hacking will not 🙂

Droplets of Honey & The Modern Honeypot Network

Easy Setup

I’ve been meaning to play with honeypots for quite some time, and if I’d given it just a little more research, I’d have started much sooner. This is because shortly after deciding upon glastopf as the first on my list of honey pots  to try out, I came across mhn, an open source project by Threat Stream.

The Modern Honeypot Network (mhn) makes not only launching honeypots insanely easy, but it serves as a nice way of monitoring multiple honeypots as well. Digital Ocean Droplets  seemed like a cheap and safe way of getting started, and I quickly found this post by Lenny Zeltser which provides pretty good directions to anyone wanting to do this themselves.

My initial plan to create a single glastpof installation evolved into two more honeypots, one being dionea, and the other Wordpot.

Results So Far

After only 2 days of attacks there has certainly been a lot recorded, but I’ve not had the time to properly look into any of them yet. The Most prominent port for probes seems to be 5060, looking for phone system vulnerabilities I assume. Dionea has yet to capture any binaries, and Wordpot has been probed only 4 times.

I did do port scans on a few of the attacking IP Addresses and have seen a few older versions of Windows (2003, XP) with open VNC ports…

Open VNC Connection on Windows Server 2003



With more time will come more data, and then the real fun begins.

The REST API included  in the MHN Framework makes sending the data to other applications simple. You can view the data for my honeypots over the Last 24 hours here.

For more information on the Modern Honey Network see Threat Stream’s blog post.


UPDATE 10/4/2016

I’ve stopped running my droplets recently. Other projects have taken up the bulk of my time and I no longer have the time to dedicate to monitoring them. The plugin I was using to connect this site and the Modern Honey Network Server can be found on my Github here

OWASP WordPress Vulnerability Scanner

WordPress makes up some large percentage of the web. As I’m writing this, web development firms all over the world are churning out WordPress sites for their clients. Some of these installs are vanilla and basic, yet some come with exceedingly complicated plugin/theme combinations. WordPress’ ease of use is a double edged sword. The positive side being a developer may complete a feature rich, member’s only website in one day. The negative being, a multitude of plugins and code snippets written by other developers are included in these projects (other wise they wouldn’t be completed within a day). A good developer will make good choices as to what plugins to use, a novice developer may not be able to tell, and things can become dangerous.

Vulnerabilities to WordPress itself are often handleable via automatic updates. If a client has brought an outdated site to your firm, often best practice is to back up the site in it’s current configuration, update it, and turn updates on from there on out. Plugins and themes can be harder to manage as far as security is concerned, given the nature of developers working on these projects for free, having their own lives, and maybe leaving these projects behind all together.

OWASP WordPress Vulnerability Scanner Project

The Vulnerability Scanner Project is a black box testing script for WordPress installations. A full description can be found on the projects OWASP Wiki.

The scanner is that of a php script checking a multitude of things that you’d otherwise have to check manually. It does this by reading various bits of the sites source to determine core version, theme information, and plugin information which it references with’s wordpress vulnerability database. Because this is a black box testing method, it alerts you to things that any visitor to your site may potentially discover. This differs from plugins such as Wordfence, which provide you with insider information (white box). I must disclaim by saying, a script such as this is a valuable tool for a developer to check client’s sites, or their own sites quickly for obvious problems, but keep in mind it’s far from a comprehensive security audit.

Source Code, Installation info, and information about contributing is provided via the WordPress Vulnerability Scanner Project’s GitHub.

Example Time

If you’re a debian user such as myself, you can get the dependencies for this with,
sudo apt-get install php5 php5-cli php5-curl php5-json git

Create a directory to store the wp-scanner code and navigate into it. Then clone the repo,

git clone

I went ahead to the WordPress Release Archives and downloaded version 4.1.6, which has known issues (just about every old version has issues). For this example, the site is installed on my local machine’s apache server in a directory titled /epm, and there are no other plugins or themes installed on the test site.

Usage of the WordPress Vulnerability Scanner is fairly simple, and for a list of all options just give the -h flag. The example below scans the url “localhost/epm” with the default settings as defined by the -d flag, and references its findings with the as defined by –wpvulndb.

php ./app.php -u localhost/epm -d --wpvulndb

The output for this is such,

|  __    __              _                           |
| / / /\ \ \___  _ __ __| |_ __  _ __ ___  ___ ___   |
| \ \/  \/ / _ \| '__/ _` | '_ \| '__/ _ \/ __/ __|  |
|  \  /\  / (_) | | | (_| | |_) | | |  __/\__ \__ \  |
|   \/  \/ \___/|_|  \__,_| .__/|_|  \___||___/___/  |
|                         |_|                        |
|                      Vulnerability Scanner v3.0.0  |
[+] Target: http://localhost/epm
[+] Start Time: 06-08-2015 02:03AM
[+] WordPress Version 4.1.6, using Meta Generator method

[+] Finding version vulnerability

[!] WordPress <= 4.2.3 - wp_untrash_post_comments SQL Injection 
[+] Fixed in version 3.8.10
[+] Reference:

[!] WordPress <= 4.2.3 - Timing Side Channel Attack
[+] Fixed in version 4.2.4
[+] Reference:

[!] WordPress <= 4.2.3 - Widgets Title Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:

[!] WordPress <= 4.2.3 - Nav Menu Title Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:

[!] WordPress <= 4.2.3 - Legacy Theme Preview Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:

[+] WordPress Readme file at http://localhost/epm/readme.html
[+] XML-RPC Interface available under http://localhost/epm/xmlrpc.php
[+] Full Path Disclosure (FPD) available at : http://localhost/epm/wp-includes/rss-functions.php
[+] Target is using twentyfifteen theme

[+] Finding theme vulnerability

[!] Twenty Fifteen Theme <= 1.1 - DOM Cross-Site Scripting (XSS)
[+] Fixed in version 1.2
[+] Reference:

[+] Looking for visible plugins on homepage
[-] No plugin was found

[+] Finish Scan at 06-08-2015 02:03AM
[+] Total time taken is: 1 seconds


If this were to be a live site, there would be some obvious reasons to be worried.

Removing the 512MB size limit on All-in-One WP Migration Plugin

A WordPress development workflow can be difficult to optimize, especially when working in a team environment. You wont have trouble finding a few well written articles online concerning version control setups and project structures. Setting up a new project is smooth when you’re using a Git repository of some flavor for your theme content, and Database Sync or a similar plugin to sync your local and live databases.

What about the case in which you inherit an existing WordPress site?

It’s not uncommon to need to pull all of a site’s plugins, settings, and media content to a local development environment at least initially. This is typically part of our “on boarding” process at work.

Simply syncing themes and databases as you typically would in your development workflow is not enough in this instance. With a plugin known as All-in-One WP Migration, you’re able to export an entire WordPress instance to a single file with an extension .wpress. You’re then able to turn right back around and import that file to another WordPress installation to create a clone.

Here is what the steps look like to export a production site to a file.

WordPress All-in-One WP plugin Migration Step 1 All-in-One WP Step 2 wpmigration3

At this point, depending upon the size of the backed up file, a blank installation of WordPress may be all that’s necessary to clone the production site.


If the size of your .wpress file exceeds 512MB, you will be prompted to purchase the Unlimited Extension of All-in-One WP Migration.  If you’re inheriting a site that’s been in production for a while, it’s likely that the backup file is over this small size limit (see a fix for this below).



Hacking the plugin seemed like a reasonable thing to try before making the $59 dollar purchase of the Unlimited Extension (which comes with lifetime updates, and unlimited support).

Go ahead and open up /wp-content/plugins/all-in-one-wp-migration/constants.php

Lines 199:201 define the file upload size limit, there’s a nice comment there indicating such. If you’d like to control+f  “size”, it should take you right to it.

// =================
// = Max File Size =
// =================
define( 'AI1WM_MAX_FILE_SIZE', 536870912 );

You’ll see the max size is defined in Bytes. In order to increase the upload size limit to 4GB, simply multiply the number seen here by 8.

// =================
// = Max File Size =
// =================
define( 'AI1WM_MAX_FILE_SIZE', 4294967296 );

We’ve been getting lazier and doing this, which works the same as above.

// =================
// = Max File Size =
// =================
define( 'AI1WM_MAX_FILE_SIZE', 536870912 * 8 );

Save the file and navigate back to the “import” function for the All-In-One Migration Plugin. The file upload limit now reads 4GB.


The plugin will no longer reject your large file uploads.




Note that this plugin does have regular updates, and each update will reset your file upload limit. Because I use this plugin to import existing sites to my local development environment, and not as part of my regular workflow, it’s not much of a problem.


* Copyright (C) 2014 ServMask Inc.
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <>.