GaryManners

Thanks but this seems ineffective.
I have a 3-column gallery on one page where nothing seems to change.
And I have an 8-column gallery where I got it to work, with calc(11.5%), but it breaks on phone and tablet view.
The 3-column also breaks on phone and tablet view.
3-column: http://owls.wpstudent.net/gallery-of-maine-owls/
8-column: http://owls.wpstudent.net

Any alternative fix would be appreciated.

Thank for you well thought out letter.
I do not believe that I am spamming or blackening with one star. I am merely stating the obvious in a public feedback forum about an open source product, which is exactly the way this community grows and gets better.
I do like many of the things your plugin does and because you took the time to respond I bumped up my rating to two stars.

I still disagree that the distorted images is a “limitation”. If you want to offer limitation on your plugin you’d simply turn off certain features. You can still show that they exist and features that can be bought. It’s very enticing to see that other possibilities are available should someone buy the pro version. This is how most developers handle freemuim plugins. And the fact that you offered me a fix just because I complained about it shows me that your business model is slightly out of whack. Just think of the business you are loosing when people try out your plugin, sees how it distorts the images and then move on the the next one.

I hope you can see I mean no malice, just interested in you plugin being a better user experience.

Let’s just say that this is a bad business model. You are basically giving someone something that’s broken and telling them that you won’t fix it until they pay you.
If you don’t want to provide a function that works properly than you need to disable it in the free version and let folks know that it is available in the paid version. People are less likely to want to buy your pro version if they see the shoddy way you made the free version.

I made an attempt to go back to square one and use the debugging code snippet that Jeremy mentioned at the beginning.

define('WP_DEBUG', true);

if ( WP_DEBUG ) {

        @error_reporting( E_ALL );
        @ini_set( 'log_errors', true );
        @ini_set( 'log_errors_max_len', '0' );

        define( 'WP_DEBUG_LOG', true );
        define('WP_DEBUG_DISPLAY', false);
        define( 'CONCATENATE_SCRIPTS', false );
        define( 'SAVEQUERIES', true );

}

I then attempted to connect to my site from WordPress.com and checked the debug.log = nothing. I then, from the Jetpack side, disconnected and reconnected to WordPress.com: debug.log = nothing.

It makes me wonder on the effectiveness of this debugging code snippet.
Is there a more robust debugging tool I can use to track the requests, etc.
I looked at the raw log data which I have access to via cPanel but it simply registers that there were requests from WordPress.com and no other details.

@jeremy
GreenGeeks wants to know the WAN IP from which the requests are coming from. I’m at a loss on that.

@jeremy
Thanks. I forwarded your request to green Geeks but they don’t understand what you want.
Is there another way to rephrase this;

Could you ask Green Geeks to send you the full XML-RPC requests that triggered the rule, and forward me that information?