Can’t Activate iMember360 Plugin in WordPress

Ran into a problem this morning where I couldn’t activate the iMember360 (Infusionsoft for WP) plugin on a local development install. Instead, I got a rather unhelpful error message: “Plugin could not be activated because it triggered a fatal error.” Okay, thanks for that.

Gollum
We hates encrypted plugins, we do! (Gollum photo credit: Emmi.Kristiina)

I’m running all my WordPress development sites on DesktopServer by ServerPress. The PHP is a bit dated (5.3.1 as of v3.5.8), but it’s a good stack and simple to set up. The only problem I’ve ever faced with it is the iMember360 plugin, because of its use of file encryption. I’ll go on a rant about that ugliness in another post, but suffice it to say for now that it sucks and we hates it my precioussss. :-

A peek at the code tells me that before it can run, it requires that the Zend Guard Loader or ionCube Loader be present and active on the server. Since neither one of those is active by default in DesktopServer, you’ll need to download and install your preferred decoder. I used ionCube for this setup.

  1. Download the loader files and extract them to the extensions folder in your DesktopServer install. Mine is at /Applications/XAMPP/xamppfiles/lib/php/php-5.3.1/extensions/no-debug-non-zts-20090626. I also downloaded the loader wizard and extracted the folder to /Applications/XAMPP/xamppfiles/htdocs.
  2. Add the following line to your php.ini file (mine is at /Applications/XAMPP/xamppfiles/etc/php.ini:
    ; Enable ioncube
    zend_extension="/Applications/XAMPP/xamppfiles/lib/php/php-5.3.1/extensions/no-debug-non-zts-20090626/ioncube_loader_dar_5.3.so"
  3. Open your browser to http://127.0.0.1/ioncube/loader-wizard.php and follow the directions there to make sure it’s working. You may need to restart Apache from inside DesktopServer.
  4. Activate the plugin and get back to work!

Speeding Up My WordPress Workflow Using Git

I’ve started working with Git as part of my Web development workflow, and am just getting the hang of some of the tools. I’m still running into problems, but it’s mainly where I haven’t taken the time to read Pro Git and learn what it is I’m trying to do.

Here’s a quick overview:

  • make changes in code
  • test in local development server
  • commit changes to git repository
    • git add .
    • git commit -m “Explanation of changes.”
    • git push
  • move updated files to external dev server
  • test on external dev/staging server to verify changes
  • move to production site (on same server as dev/staging)
  • verify changes on production. smile at work accomplished

I’ve also tried working with git flow for feature and release management, but haven’t quite got the hang of it yet to make sure I’m doing it right. Once I know more about what it’s doing, I’ll write about how I’m integrating it with my own workflow.

Publishing a jQuery Plugin

I’ve written a few plugins for jQuery and WordPress over the past few years, but mostly for specific projects or my own personal use.

The first time I released a plugin (Hashgrid for WordPress) for others to use, I ran into the challenge of maintenance hosting: I didn’t have time to maintain it, and my host ended free hosting and I lost the files.

This was in the olden, pre-Github days.

Continue reading “Publishing a jQuery Plugin”

Fixing Protocol Errors in WordPress Plugins

I recently started a new job as a full-time WordPress developer managing several websites and the myriad of custom themes, child themes, and plugins. This is a lesson learned from an issue I had with one plugin in particular.

Using Chrome on OS X, I get security warnings that a script wouldn’t load on a particular page. When I looked into it, I found it was because in wp-admin, my site url is set to http, but that page (and several others) is served from https. Since there’s a mix of protocols, good browsers will block scripts from running across SSL/non-SSL.

The plugin was using get_options('siteurl') to create the path string used to load scripts through wp_register_scripts. Switching to site_url(), which returns a string with the protocol that the page is being rendered on, lets me now safely load the scripts on any page in the site.

Here’s how it ended up looking:

[sourcecode language=”php”]
$old_root_url = get_options( ‘siteurl’ );
$root_url = site_url();

$path_flash = "$root_url/wp-content/plugins/$pluginName/js/swfobject.js";
[/sourcecode]

Hope that helps someone!