by ·0 Comments

This is a bit different from my usual WordPress/PHP posts, but I still wanted to share as a general development exercise and also to hopefully let other people know what I discovered about working with Child’s Play.

Childs Play Logo

I am friends with the couple who runs the Game On Marathon, a 100-hour video gaming marathon which raises money every year for the Child’s Play charity. As part of the festivities when the event is happening, they needed the ability to trigger different giveaways based on when we hit certain milestones in the fundraising effort. There is a C++ script which handles these giveaways, but it needs to be told what dollar amount the event is at and that was game on marathoncurrently being done by hand. Child’s Play has a website widget which displays the info, but there didn’t seem to be a way of easily getting their hands on the donation total at different points in time for the program so they asked if I may be able to help.

At first I tried to scrape the website via remote POST, but that was a bust. Since the Child’s Play widget is driven by a .js script include, none of the generated markup was available in the DOM when you hit the page from a remote script. While looking through the js source, however, I found reference to a JSON API endpoint which looked promising. I had initially tried googling for such a thing, but came up empty, so my guess is that this is an API they possibly only mean to use internally / by their own tools.

Continue reading

by ·0 Comments

Recently a self-hosted client asked us to do some basic security audits on their website. We went through the usual review, and as part of our remediation process we installed a few plugins to help harden their installation.

Unfortunately one of those plugins began throwing PHP Warnings on the client’s login screen. They seemed innocent enough, but we didn’t want the client to see these messages and start asking why they were there. Typically, these should not appear on your site as long as you have define('WP_DEBUG', false); set in your wp-config.php but in this case they were still appearing.

Not having access to the hosting environment itself, we knew we couldn’t update the PHP settings manually. Fortunately, some quick Googling led us to this blog post which solved our problems. By updating our wp-config.php we solved the issue and successfully suppressed the warnings (which really, you probably should be doing in a production environment anyway to prevent information disclosure).

The ini_set() functions, in order, tell PHP to 1) log all errors, 2) not display those errors on screen, and 3) ensures that all errors/warnings are logged.

The three define() functions tell WordPress to 1) not run in Debug mode, 2) log the errors to log file for review later which is stored inside your /wp-content directory, and 3) ensures that any errors or warnings that are triggered are not displayed on screen. For more information on the debugging tools available inside WordPress, check out the codex.

This worked for our client’s hosting environment, but YMMV. Good luck!

by ·0 Comments

UpdatesAfter spending so much time trying to get this to work myself, I felt that I had to write this post to help clarify much of the mystery behind Automatic Background Updates in WordPress for others. Hopefully it helps someone else out there.

This post, Part 1, will cover the basics of having your plugin automatically detect a new version when your plugin is not hosted within the wordpress.org repository. In Part 2, I will discuss the methods you can use to have WordPress actually upgrade your plugin for you now that it has detected that there is a new version to be installed.

Continue reading