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.
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.
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.
Add the following line to your php.ini file (mine is at /Applications/XAMPP/xamppfiles/etc/php.ini:
I hear the battle cry of website owners every time WordPress releases an update: “The update broke my site/theme/plugins/heart!” Usually I ignore the wimperings with the knowledge that “good” developers test their stuff with the pre-release versions so there aren’t any surprises.
Well the surprise is on me, now 🙁 The WordPress 3.6 update broke my sites.
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.
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.
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.
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.