Christopher Kunz has shared about a resource he came across that offers complete PHP encoding for a much lower price than some of the other services - phpshield.com. It seems a little too good to be true, though:

However, the phpShield.com home page did not offer the slightest clue who actually is behind that product. [...] It's common practice to whitelabel your solutions and sell them under different brands with different feature sets to different target audiences. However, we always clearly state who is behind the whitelabelled solution.

A little more digging shows an interesting relationship between the company that sells SourceGuardian and the company behind this PHPShield (Inovica). He sees the deception counting against the company and has just "struck one off the list" from his search for encoding methods.

Davey Shafik has done a mini-review comparing the Zend Guard software with a similar offering from IonCube, IonCube Encoder to help protect your PHP applications.

For the last several years, we have been successfully using the IonCube PHP encoder. It works well, providing us with as secure a solution as we could wish for, for our code. [...] Due to the amount of head pounding involved in finding this issue [where IonCube was removing a valid logic branch], I started to consider using Zend Guard instead, figuring that Zend has far more resources and more experience in this arena, we might see less issues.

He details their upgrade process including comments on the included GUI and how it "just works" (once it's set up)

In dealing with a little JSON encoding and objects in a project of his recently, Cal Evans bumped against a problem when he was encoding an object and moving it back and forth between the back and front ends.

The problem is simple, JSON encode a PHP object and send it back to the front end. Sounds simple and the last 100 times I wrote this code it was simple. This time, I was too smart for my own good. Here's the scenario.

He illustrates his problem - the "dropping" of properties somewhere along the way - with a sample class that encodes the object and sends it along. He missed one key bit of information, though. His protected array of properties wasn't getting passed back out correctly and we're in the resulting JSON message. A quick hack of a getProperties() function call made this problem a thing of the past.

The PHP Web Services blog has a helpful hint on getting a custom SOAP request all ready to go:

How do you get this [custom] XML to be output by the SoapClient?

Using the SoapVar method and a few newly created objects, making a custom structure is simple. It's just a matter of encoding the object and setting it with the base() method in the PHP SOAP extension. Check out the blog post for an example of both the custom XML and the code to produce it.

On the ProDevTips site, Henrik has pointed out a handy application that can make HTML encoding characters outside the norm in PHP simple.

The standard htmlentities() function will encode special characters so that they display OK in the browser. However, sometimes you might want to encode different languages to entities too. I just found a script that will do that in the form of an html encode application.

He includes an example showing how to encode a string of non-english characters out to an easy-to-display HTMLified string.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.