Fatal error: Cannot redeclare _recaptcha_qsencode() (previously declared in /home6/rocketg1/public_html/gravityhelp/bbpress/my-plugins/recaptcha-bbpress/recaptchalib.php:47) in /home6/rocketg1/public_html/gravityhelp/bbpress/my-plugins/nospamuser/recaptchalib.php on line 55

Also sent two emails via their contact us page and have not heard anything back so I thought i’d give them a nudge here.

Currently Gravity Forms is primarily for front end forms. However, the more advanced it becomes the more usable it will be for back end forms. Reading your reply, you actually gave me a good idea for a future feature that would make back end forms a possibility.

If you have any other questions, etc. Don’t hesitate to ask. Thanks!

What I was describing was a theme I purchased that every time the admin page was loaded a callback was made to the theme’s providers server, which went up n down all the time, resulting in the inability to edit the admin…. yeah some crazy stuff goes on out there.

Getting back to gravityforms:
One thing that is not clear to me is this…. Do the forms only work for the enduser or am I able to create forms for data input on the backend… think flutter/magic-fields/pods

I personally don’t really have a use for enduser forms at the moment, but do have the need to create custom forms for my ‘site admins’ to use in order to create custom post content.. once again think flutter/magic-fields/pods

Example:
A site admin wants to create a ‘sermon’ post, so he needs input boxes for series/date/embed code/description/file uploads/etc
On the backend, each of those boxes uses a shortcode that I apply to a custom category template…

hope that makes sense…
(flutter/magic-fields/pods all seem to have their own issues in a wpmu environment, so I’m still hunting for the perfect solution)

sidenote so I don’t sound like an idiot: I meant xss not css injection in earlier post LOL, typing to fast

btw… love the edit comment plugin

The ONLY thing that is encrypted is the license key when it is stored in the database. None of the PHP is encrypted. Why is the license key encrypted? Because users requested we encrypt it so that their users and clients couldn’t easily swipe it by looking at the plugin settings page. Originally we didn’t encrypt it and it was added to the most recent version at the request of our users.

The code isn’t encrypted, the license key is just hashed in the database.

As for “callbacks”, what do you think EVERY plugin you download from the WordPress repository does? It calls back to the WordPress repository every so many hours looking for updates. It’s how automatic upgrades work. Automatic upgrades are impossible without a callback.

Why does Gravity Forms callback to our server and not the repository? Because it isn’t hosted in the WordPress repository so it has to ping our server looking for updates. If an update is available it gives you the option of automatic upgrade just like any other WordPress plugin.

So do you actually remove all the plugin repository update callbacks from every plugin you download? Seems like overkill to me. Not to mention renders the convenience of automatic upgrades useless as they don’t work without a callback.

When I run into that, the first order of business is always to decrypt everything, remove all callbacks and then determine if the code is solid enough for my use. –Lesson was learned from the theme that was encrypted when I purchased it. The dev’s were positive that it was secure, and only after ‘opening’ the code up did I find tons of css injection points and function vunerabilities. (No it was not a warez theme, but one I purchased directly).

I’m not saying that your code is bad, haven’t purchased it, I’m just making a point against your ‘model’ is all. It does nothing for protecting your plugin, it just causes me extra headaches by having to spend the time to decrypt and null it is all…

The license key then comes into play when WordPress checks for plugin updates. Automatic upgrades are only available to users who purchased the plugin. When WordPress cron job runs to check for plugin updates, it pings our update server to check if an update is available and passes your hashed license key as part of the request. If the key is valid and an upgrade is available, automatic upgrade takes place just like plugins from the repository.

The license key is also tied to our support system. It helps identify you as a customer. When you register on the support site it knows if you are a customer because your email is tied to your license key. So it then unlocks areas of the site that only customers have access to.

You enter your license key once, most likely the first time you activate the plugin. Not being able to reach our update server does not prevent the plugin or forms from working. It just prevents automatic upgrades from taking place if one is available.

A valid license key also automatically removes the “Buy Gravity Forms” message that appears in the admin side of the plugin when no license key is present.

As for the demo not fully showing what the plugin can do, unfortunately its very difficult to provide an online demo of the plugin that gives users full access without…. giving users full access. We did what we could given the security issues. If we made it wide open, a small percentage of users would end up purposely causing problems with the demo WordPress install and it’s just not worth the headache. That is why it is locked down.

What will be interesting to watch, however, is the way in which people innovate around GF’s more advanced functionality, taking WordPress to new places. For those sorts of uses, the $31 or so (after 20% discount) is easily worth it. I think the key for GF’s success will be in enabling that advanced functionality and opening up those possibilities. I’m looking forward to seeing what 1.2 will bring to the table.