I recently moved my main site to SiteGround, which has been pretty nice so far. One of the little issues I’ve had has been the same as several other hosts: not using the latest version of WP-CLI on shared hosting accounts. It’s not unusual, and often not a major problem, but I recently came across an issue that prevents me from using the version installed on the server (0.18.0) with the version of WordPress I’m running on the site (4.4 trunk). Every time I tried to use certain wp commands, I was greeted with a fun new error message:
Fatal error: Cannot redeclare class WP_Http in /home/morganes/public_html/wp-includes/class-http.php on line 21
WordPress 4.4 is undergoing some massive file changes, specifically with separating classes, functions, and implementation code into their own files and using the original file to load them all for backwards compatibility. One of those changes caused an error with WP-CLI trying to redeclare WP_Http the class when it loaded it via require instead of require_once. That’s been fixed in 0.20.0, so I asked my host to upgrade to it.
If you're running @WordPress 4.4-alpha, be sure to update @wpcli to 0.20.0. Otherwise you'll run into a PHP fatal error with WP_Http.
Since I have shared hosting, an upgrade to the script would involve upgrading it for all users. That’s something that’s done on a schedule, and I don’t know when that’ll happen. SiteGround’s systems engineering team hasn’t upgraded yet, so they suggested installing a local version of wp-cli on my account and using it. I followed the Alternative Install Methods guide but kept running into a problem with the output and strange characters. After much trial-and-error, I found out that the shared WP-CLI script uses a different version of PHP than the regular command line does. Making a couple of changes to my .bash_profile finally got the latest version working.
Here’s the final version that’s working for me with WP-CLI v0.20.1 and WordPress 4.4-alpha. I’ve decided to use wpcli as my command for testing, so I can keep SiteGround’s version of wp to know when they’ve updated.
# WP-CLI from user account
alias wpcli="$WP_CLI_PHP $HOME/.wp-cli/wp-cli.phar --path=$HOME/public_html/"
I just attended my 13th WordPress Users Group Meetup, my tenth (out of 11) in the past year. Tonight when I looked around the room, I saw another example of what I’ve come to believe about WordPress:
it’s not the software, it’s the people
Tonight’s meeting was a perfect cross-section of WordPress users. Here’s a sampling of the folks who came:
a woman who has never used WordPress and wasn’t even sure what it was
a Web developer who uses a variety of frameworks (including WP) depending on the job
the guy who used to have my job and is now a direct competitor in our niche market
an 8th grade English teacher who builds WordPress-based sites for ministries in her “spare” time (because teachers have so much “spare” time, right?)
an Automattic employee who works with the WordPress mobile apps (which I’m writing this on, by the way)
an attorney who doesn’t even use WordPress but wanted to check it out
What I didn’t see was just as important: no one-upsmanship, no disparagement, no “devs vs. designers” throwdown (although that one may be fun). It’s just a handful of folks who want to get together to share some pastries and knowledge.
Our little group is a reminder for me that while the scrumtrulescent, splendiferous software that makes up WordPress is built on open source code, it’s the openness of our community and the dedication of local volunteers that keeps it running.
I just released a new WordPress plugin to prevent typographic widows and orphans. Based on Shaun Inman’s original Widon’t plugin, this one has been updated to ensure it works with 3.6 and to take advantage of the new Settings API.
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: